marcusoft.net - sharing is learning


function share(knowledge){ return share(++knowledge) }

Thank you Rob


I’ve just downloaded and started to read the Imposters Handbook., by Rob Conery. It’s a book about all those things that you don’t want to reveal that you don’t know. I most of them I should know since I have read Computer Science. But I don’t. It’s a great (in all senses of the word ≈500 pages!) read and promise to deliver even better things ahead. Go get yours now!

As I started to read it I heard a familiar voice in my head. Rob Conerys. And I just realised how much I’ve learned from him.

Read on ...

Delayed responses with AWS Lambda and Claudia (Pingu part II)


Before the summer I showed you how to build a Slack bot using Claudia - it’s a very simple ping command that you could run from a Slack-client. However that implementation had a flaw; if the command takes more than 3 seconds to complete it fails.

This has to do with a restriction in Slack that doesn’t allow requests to take more than 3 seconds. In my mind created a super complex and beautiful solution including me handing a message of to a queue and that I then polled and called back to… I ran out of time figuring out.

Which turned out to be a great thing, since the Claudia team not only created a new beautiful site https://claudiajs.com/ but also wrote a tutorial on this exact topic

In this post I will re-implement pingu using a delayed response as in that tutorial.

Read on ...

Some reflections after seeing mob programming in action


Since the first time I heard the term mob programming it has intrigued me. I love things that challenges me and me perceptions.

The idea behind mob programming is deceptively simple and yet powerful: have all the team member (3-5 seems most common) working together on one keyboard, one computer and one feature at the time. Or as Woody more eloquently puts it:

All the brilliant people in the same room working at the same problem at the same time

What struck me is that this simple idea solves many problems that I often see teams struggle with.

I’ve written before but never been full time member in a mob. However just before the summer I saw two excellent examples in action, and I have number of friends that have been full time members of a mob for more than a year. My interest with this has led me to interview them often and deeply.

In this post I wanted to share some things that I’ve seen. Mind you this is only from the 5-6 mobs that I’ve been in contact with thoroughly. Other examples and variants are probably found. This is just my observation.

Read on ...

The Bungsu Story - some progress


About six months ago I got home from the adventure of our life time in Indonesia. At the time I was actually feeling very underwhelmed and that we’ve failed in our work there.

But the more I think about it and the more I speak and write about our experiences there, and especially the mind blowing transformation we led in Rumah Sakit Bungsu - the more I realize that this is an once in a life time thing that have happened.

I’m writing a book about that journey. with my good friends at Oikosofy. But I have also given a few presentations on the topic.

This post is just an update about the progress of the work around the “Salvation Army hospital that rose again” that I’m calling it.

Read on ...

Backlog and features


A couple of weeks ago I tweeted:

In this post I will explain what I meant. And also give a suggestion on how to do something better. I know it’s better - I’ve tested it many times. Just this last hour to be exact :)

Read on ...

Building a Slack command with Claudia bot builder


I’ve written a few posts on Claudia now and as often I jumped almost too early on the boat - it turns out that there’s significant improvements to both Claudia herself and the entire ecosystem around the main tool.

The main tool Claudia:

automates and simplifies deployment workflows and error prone tasks, so you can focus on important problems and not have to worry about AWS service workflows

In this post I wanted to check out a new tool around Claudia that helps you to build bots for use in chats - specifically for this post in Slack.

AWS Lambda is really cool but it leaves one of those: Oh wow… now what am I going to use this for? feeling. It’s just code that scale infinity without you having to worry about it. It’s a very open playing field.

Read on ...

Jidoka - an old Toyota practice makes an guest appearance


When I started to learn about lean I naturally heard a lot of Toyota stories - it’s pretty inevitable since the whole thinking comes from there. One thing that I learned about was translated as autonomation. I was pretty sure it was a mistranslation.

But the other week when one of my team members said:

What’s the big deal of many things going on? If I’m blocked on a few items I can equally well just start a few more.

(Not his exact words but still those lines of reasoning)

At that point I saw the time to implement some jidoka (as automation is called in Japanese) in our project

Read on ...

A scary thought experiment


Just a short post on a little thought experiment I’ve been testing out.

I am right now in a big company trying to apply agile and lean practices for software development. We struggle because we meet the current organization that is not built to move in the way we want it to.

[Please fill out the rest of the story from your own experience while I yaaawn]

[…]

[…]

… and now everyone wonders why things take so long and we are not getting more through the system.

[I’ve been through this many times]

Read on ...

Solving the underpants gnomes pitfall


I have a problem; I often have a hard time connecting our vision and overarching goals to the items that we are actually working on. I want to be able to pick up anything we do and understand why we are doing this now and how it will take us closer to our goal.

I’ve blogged about this before and in my time in Indonesia I even thought I had a great way of uncovering what those high-flying goals really means, by simply asking this question:

What can we measure to see progress to that goal?

But it turns out, understandably once I think about it, that question is too hard. The gap between the vision and the work is quite simply too big.

To me often the connection between vision and our work reminds me a lot of the business of the underpants gnomes in South Park:

It’s like

  1. Vision: “we’re gonna rock the world”,

  2. …,

  3. …,

  4. sticky on my board: “Make the button blue”.

I don’t like it. There’s no connection. Or worse we try to make up the vision/goal, the why, from the work that we do. But I have an idea. We are trying it now at my current client. I wanted to share it with you.

Read on ...

Some thoughts after Lean Kanban North America 2016


I’m writing this post in a small crappy hotel room that will be my home for a few days. It’s quite the change after being station at the nice, beach-side hotel where Lean Kanban North America 2016 was held.

I was very honoured to take part in this event - first time for me at Lean Kanban Inc. conference (I think… ) and it was really something special.

I wanted to jot down a few thoughts and comments.

Read on ...

Requirements are not problem/opportunity descriptions


A few weeks back a team mate, developer and agile dude extraordinare, said something profound:

I’m used to people coming to me with problems they need solved. Not solutions.

It was in a backlog grooming meeting and we were discussing if the item was ready for the development team to start to work on or not. It was. Well and ready. But the people writing the requirements felt that it was not worked through enough.

At the time I just giggled a little about this but it got me thinking and herein lies the heart in how the work with a backlog changes when you start to “do agile” or work in shorter releases.

Read on ...

Developer failure


I got a request by a nice man call Brandon Garlock to share some failure of mine. My contribution will be part of a:

collection of stories about experienced and established developers (such as yourself) and the failures, setbacks and hurdles they overcame over the course of their careers. It will serve as an educational guide, motivation and reference for burgeoning programmers as they learn their craft.

You can read more about the project at http://www.iamascrewup.com/

That sounds both fun, worthy and useful. And I’m very honored to be part of the story. Any experienced developer will tell you that the greatest learning came from overcoming, maybe not always doing, great hurdles.

I asked Brandon if I could share my story on this blog, as that how I mostly write stuff, and he kindly agreed.

Read on ...

Flow or value - what is it, Marcus?!


This post could be summaried as you summaries an argument among kids; and then he said, so I replied, and then she went, and I’m like SAY WAAAHHAT?! but also hmmmmm… and then I went back home and asked a few friends and then I went Aaaaaah!

And then I learned something deeper of what I until that point only was a belief.

The last week I was in a lively and good discussion, again, about user stories and value. I think user stories often is misused as just another tool to write requirements in.

Also we discussed that flow is something that we really should strive for, but to what extent? Over value?!

As often, for me at least, it took a few days to think this through. That and some excellent help from some friends and tweeps.

Read on ...

Our fear of forgetting important things


The last couple of weeks an old “friend” has made it’s appearance; fear. This time it is a special kind of fear that I’ve seen many times in organisations that started their agile journey: the fear of forgetting important things.

In this post I wanted to rant talk a little bit about that just as a concept and then give a few pointers and indicators on what you can do to get rid of that fear.

Read on ...

Some simple changes for flow that made a world of a difference


When I started my current gig about 3 months ago the tension around releasing was tremendously high. Also we had failed the last couple of releases resulting in even worse relationships with our customer and messy rollback handling and procedures.

We have now done three very simple changes in our process and technology that made a big difference for us and for the relationship with our customer; ditch iterations, shorten release cycles and feature toggling.

In this post I wanted to tell you a little bit around how we did those and the benefits it had for us.

Read on ...

Claudia 1.2 - some updates that made me want to write a post


I downloaded a new markdown editor called Typora that looks amazing. Now I just wanted to try it out, and needed something to write about.

Also I’ve noticed that Claudia has come out with some new releases and that AWS Lamdba now supports Node 4.3.2 - which is awesome.

This post gave an opportunity to fix both itches above in one go. So this is an updated “Get started with Claudia JS for AWS Lambda”-post.

Read on ...

Flow manager - is that me?


At my current client I don’t have a role name. Or rather I do but that’s not what I do, nor what I am there to do. It struck me that I have had this problem before. Many times.

Here’s some way it manifests itself:

I’m not “development manager” that some people call me. I have no formal authority, no staff and no budget. And I have responsibilities that stretches over the development team.

I’m not scrum master that is the fall-back term for anything that is around agile and doesn’t fit the normal organizational scheme. However none of our teams work with scrum and i’ve not worked with scrum for at least 6 years. I’m also pro-flow-based processes rather than iteration-based.

I’m not a agile coach since that’s a term that I barely myself understand what it means. I don’t want to be a coach to make people more agile - I want to make the system work better to flow idea faster to production.

So I tweeted:

Let me describe what I mean.

Read on ...

Frequent releases and no urge to finish


Yesterday we had a couple of very interesting discussions in the team, that got me thinking on being clearer around the purpose of kanban.

In this team we have made a lot of changes lately to try to improve our lead times and throughput. One simple thing that we changed and that made a significant improvement was to simply release more frequently. When I first arrived here the releases were done every 6 weeks. Going to every 4 was just a simple change, and increasing frequency to ever 2 weeks was a very natural next step that no one objected to either.

But then a question came…

Read on ...

What are you optimized for then?


I was in a couple of very interesting discussions yesterday, through the mean of a SAFe course. Just sitting in the room with your peers and stakeholders, off-site, discussing how to work more effectively is really powerful - it turns out.

“Who knew?”, he exclaimed with some irony in his voice but still some hope and joy.

Ok, in our discussion I, again, ran into the point where I simply don’t understand the reason for organization your company in a certain way.

I just have to write this down, and see if it becomes clearer for me. You can read it too if you want.

Read on ...

Thoughts after a SAFe course


I’ve been on a SAFe course. I was very interested, because like many people I’ve heard much about this, had opinions on it but haven’t experienced it first hand.

The context of the training was that it was given for my client. Not as “let’s get started with SAFe” but rather to align and give us all a common understanding on nomenclature and concepts.

I wanted to share a few thoughts in this post. If you were looking (or hoping) for a SAFe-bashing by a Kanbanista… Sorry - I’m not that guy. I’m also in way too good mood to bash anything right now.

Read on ...