When was Lars happy?

Posted by Marcus Hammarberg on September 10, 2019
Stats

One thing that I love in coaching and consulting is when things stick. My way to try to get there is to tell stories (psst - there’s a book on that) to try to emphasize or bring out certain points.

What I find very rewarding is to hear people relate these stories to each other later on, when (they thought) I was not listening.

Just the other day I walked passed two people and I heard:

Yeah, exactly. Remember: when was Lars happy?

This is one story that I’ve told many times and I wanted to share it here too. It was a powerful lesson on true value, customer focus and lead vs flow time for me.

The story

I have a good friend called Lars. He is a brilliant programmer, data engineer, agile aficionado and he keeps my argumentation sharp with his analytic abilities.

At one point we were working in the same group and he told me that he had ordered a new car. A Volvo. The remarkable thing was that he ordered it online, like you would a pizza or a computer. Selecting colors and interior details and then, basically hit a big “Build It!”-button at the end.

Now, two or three days later, he was super-excited because he just got an email telling him (he flipped his phone open and showed me):

Your car is built and is waiting here in the parking lot in Torslanda Gothenburg.

We were amazed! Building a car from order to finished in 2 days! Our minds were blown into small pieces of software developers awe of hardware wizardry of speed and prediction.

About a week and a half later I bumped into Lars again and asked him how the new car was? His answer:

I don’t know. I’ll get it next week.

The question

That is the story. Now for the question:

When was Lars happy?

The lesson

Lars was (became) happy when he could drive the car. The fact that it took two (or three) days to build was interesting but of no real value to Lars, until he could drive it.

Imagine getting a car without wheels delivered to your house. Same feeling. Thanks - that was a nice car. When can I use it?

Lars needs to go places and transport things. So he bought a car. When the car is in the parking lot, or when it arrives without wheels - he cannot drive it. When he can drive it he will be happy. Until that point, he might be informed, amazed with the speed of a production system, but his need is not met.

I think we miss this point a lot in measuring the performance of a process. I have a mentor in Woody Zuill that has a wonderful point on “definition of done”

Used by users

Another definition of done I’ve seen that rubs me the right way and sits well with this story is this one from Mike Burrows

Done (adj) /dʌn/ Someone’s need was met.

That we have completed the feature, deployed it or even released it for users to use doesn’t mean done. It’s mean almost done. The users need are not met - because they are not using it.

And hey - even then we are not done, but that is another blog post

We often measure how long we are working on a feature, but that is just “putting Lars’s car in the parking lot”. We need to ensure that users are using it. From “Could you please” until “Thanks a lot - this feature has helped me a lot”.

Very often when I start to measure process performance I introduce people to lead time, which is the time taken for the entire process (“Could you please” to “Thank you”). I have yet to suggest that to a team before they start to complain about that part of the process is out of their control.

Fun un-scientific fact, most of the times that I’ve tracked, software development work spend in “Backlog”. That is we create work LONG before we start to work on it. 60-70% (but 90% of the lead time is not uncommon either) of the time is spent waiting before we even start.

That’s why Flow Time has arisen on the agile/lean scene. And that makes sense: Flow time is the time taken from we start the job until it’s done - “Elapsed time for all activities”. I’m gonna interpret that benevolent to “from we started to work on it until users use it in production”. Although I fear it’s often “until we deployed it” or sadly still “until the ops people get their hands on it”.

So flow time is part of the lead time. The flow time for Lars car was 2 days. The lead time was 2,5 weeks and 2 days.

When was Lars happy?

There’s nothing wrong in measuring that flow time of course, but we should recognize that it is not done.

If you are doing development work (rather than manufacturing) there’s another disturbing fact about lead time and flow time. It’s mostly true in manufacturing too, but let’s consider an idea for a new feature in a software system:

Got the idea - (Lead time starts) - No value to end-user Added to backlog - No value to end-user Groomed it - No value to end-user Decided to include it in the sprint - (Flow time starts) - No value to end-user Coded it - No value to end-user Documented it -No value to end-user Tested it -No value to end-user Deployed it - No value to end-user Released it to end-users - Maybe or hopefully value to end-user If you don’t believe me, think about that time when an end-user called in and thanked you for the awesome documentation. Or code. Or testing. Or was impressed with your kanban board layout.

No exactly - that has never, and will never happen. Because that is not the meeting the need. We do that because it will assist the flow of work, but it is not giving value to the end-user.

That is also why we are constantly looking to improve and find a faster flow so that we faster can give value to the end-user and learn faster.

Conclusion

When was Lars happy?

When he could drive the car.

I think it is a useful starting point for any discussion about improving the flow of value in any process. Measuring our the time our work takes (flow time) is great but the perspective of need met could be lost. That time is from “Could you please” until “Thank you very much” (Lead time).

We should at least consider that perspective too. Maybe our biggest bottleneck is not building Lars’s car 30 seconds faster.


If you liked this post ... here's more for you:


Published by Marcus Hammarberg on Last updated