The first time I heard that it would be possible to deliver more if we do fewer things simultaneously, I was skeptical. It makes no sense, I thought.
If you have time now, try to do it: write the sequence A B C D E F G H three times, each one in a different line. Repeat it once, but in your second try, write firstly all letters A, after it letters B, and so on. If you measured both tests, it is probably that the first one finished faster than the second one. In my case, two seconds less.
I know: the delivery time is just 7% less. But imagine what could happen when developing complicated features in digital products, for example. Or try to do the same challenge writing multiples of 3, 6, and 7 in each line up to the tenth value. I did too: 21% less (59 and 75 seconds).
But we also have another important point: in the first trial, I delivered the scope divided into three parts, perhaps in nine seconds each. Some value was provided soon, and I was able to collect feedback and improve my second delivery (second line). If you deliver all lines together (writing all letters A, after letters B, etc.), your feedback will be slower, the risks are more significant, and the delivery time (lead time) will be higher.
Similar concepts were explored since the middle of the last century. Taiichi Ohno, considered the father of the Toyota Production System, wrote about an upper limit to work in progress as one of the kanban properties in his work to improve manufacturing efficiency. John Little (MIT, 1961) developed Little’s Law to explain the relationship between the average number of items in a queuing system with two other variables. Both are good examples.
In the last few years, in software development, I have experienced understanding better the relation between what we do at the same time with the time to deliver those things and the delivery volume. David Anderson reported an interesting case in his book called Kanban (2011). In the case study presented, he affirms that there is a linear cause and effect relationship between the amount of work in progress and the average lead time.
How are we trying?
At Nubank, we are continually improving our methods and work practices. We got an impressive result in the example below from a software engineering team:
In the first graph, the green line shows the moving average of lead time (for workdays), considering the last five user stories completed. The grey line is just a projection. Red points are demands ongoing.
The second graph shows the number of demands completed per week (with colors separating by issue type). That is our throughput.
Lead time and throughput are two significant variables to measure in software development. As we can observe in the example, the moving average is more stable from the middle of the first graph to the right. In the same range on the second graph, the quantity of deliveries is larger. How did we get to decrease the time needed to deliver our demands (lead time) and to increase the number of items completed per week (throughput)?
We did two “simple” things:
- We started to manage better our work in progress (items ongoing). We had 4 of the upper limit of demands in the step “Ready for Development” and 6 in all other steps before “Done” on our kanban (steps “In Development,” “Code Review,” and so on). Using a simple board, we limited a starting part of the flow to prevent our demands from becoming obsolete, and development steps to avoid doing many things simultaneously, stimulating the team members to help each other. Probably those actions helped to stabilize the moving average of lead time;
- We decreased the size of the demands. Minor things are easier to understand and refine, perhaps faster to deliver, with a high potential to provide value for our customers more quickly and collect feedback faster about the delivery or new features. That could explain the throughput increase. But we are delivering smaller things, and not programming faster; it’s important to say.
Why did we do that?
Perhaps it’s a good idea to manage your workflow better if you need to have some predictability. For example, you can better align expectations about delivery dates if you have a more stable and predictable workflow.
We also did it to improve our workflow visibility to check for possible bottlenecks and improve our agile methods using data based on our work behavior. You also can do it to eliminate the feeling of slow delivery, I think.
Finally, as I wrote previously, these practices can help you get feedback faster, the risks can be easier to manage, and the delivery time will be shorter (we hope).
If we start to do something, anything else we do at the same time probably may compete with that first thing. Beware: we don’t need necessarily to do just one thing at a time, because sometimes we can start a second or a third demand while we wait something indirect happens in the first one (for example, data migration of four hours in your DataBase, or a review from a coworker in your pull request).
However, when that first indirect thing finishes, you will have two or three things to do simultaneously, and each demand will compete with each other. It may increase the lead time, decrease the throughput… okay. You already know the story.
Remember Lean’s philosophy: Stop starting and start finishing.