One-piece flow is inefficient for software development
I have been fascinated by one-piece flow and small batches for a long time, this is of-course due to my weird obsession with Lean Manufacturing. One afternoon when it was almost home time I asked a few of my colleagues to participate in a game that would “prove” that one-piece flow is an optimal strategy for delivering software. What this experiment has taught me was not what I had expected.
The Experiment
Experiment had to be quick and easy to follow, after all everyone wanted to go home. The following rules were established:
- There will be two teams of same size
- There will be two backlogs of stories with acceptance criteria; one backlog was broken down to tiny discrete stories, “build a chair”, “build a table” and “build a plant”. Second backlog had larger stories with more scope “build a park scene with chair, table and a plant”. There were many different scenes in there that teams had to create.
- Each team member was constrained as he/she could only work on structures top, middle or bottom part and not the whole. This constraint reflects skill/specialism in real life.
Hypothesis was that smaller scope stories backlog would outpace larger scope stories. Theory was that larger stories create more conversation, errors and by having many stories on the go at the same time would slow down overall delivery.
Team A (large scope stories)
To my surprise the completely opposite was true. Team with larger stories knew what they were doing overall as they had spent time discussing overall story, theme and ideas on how a park scene with chair, table and a plant will be set up. This has reduced task time, as they have worked as a team to figure out the best approach. This has reduced future disruptions as they knew who was doing what and why they were doing it. As plenty of work got released into the system there was no need for anyone to wait for any work. Team overall felt calm, self-organised and positive.
Team B (small scope stories)
This team was given one piece of small work to develop at the time such as chair. They did not know the overall theme of the work, that is that they are building a park scene. They only understood the scene as they were finishing it, so they have tried to make it better by reworking it, this created wait time and disruption. As it was a one-piece flow, many members just stood around waiting for work, thus increasing wait time. This team also needed a lot more orchestration as they did not know the context of the work and the overall team seemed more stressed.
Conclusion and Implications
I don’t know why I was surprised. Large story team has outpaced the one-piece flow team by 26% average and delivered much better quality work!
First insight is that batch sizes need to be big enough for teams to understand what they are doing. This way they can get engaged with the work, provide an opinion, self-organise so that everyone is utilised, know what work is coming in when, and provide assistance to other team members where appropriate. If you follow INVEST and ensure that stories are actually valuable and that they deliver discrete piece of usable functionality then you are mostly there.
Second insight is that work planning and team communication reduces cycle time and reduces lead time. This is important as knowledge work is all about ideas exchange and not just typing on the keyboard.
Third insight refers us back to the article “Lean manufacturing cannot be applied literally to software engineering” where it was stated that “in craft production the work itself can be a constraint. This is because you can choose what you do, how you do it and who does it”.
If you decide to repeat the above experiment in your own organisation, please do share your results.
