Continuous small steps are the key to continuous improvement and the persistence on this differentiates successful and sustainable teams from others.
The fundamental to continuous improvement is the concept of flow and small batches. In the talk, Continuous Delivery Sounds Great but it Won’t Work Here Jez Humble talks about the difference between how GM factory works and how Toyota works.
I would recommend you listen to him just for about 5 minutes, to understand the concepts:
- Built Quality-in
- Small Batches
- Continuous Improvement and Reflection
At GM’s production line, if the worker couldn’t finish the work in the stipulated time [indicated by the lines in the production line], say fixing the engine or fixing the doors, he presses the Andon switch to indicate the same and the supervisor comes to help the worker in fixing it. In case the supervisor was not able to fix it within the stipulated time, Andon is pressed again and the entire production line stops. The entire team is now focused on fixing the production line and then moves back to their respective work.
This helps to make sure that defective products are not shipped from the production line [Built Quality-In], and the focus on the each and every item [Single piece flow] ensures that every item moves smoothly to the completion than getting stuck in between. One more important thing is, every time the Andon switch is pressed, the team reflects on what can be improved so that similar issue doesn’t happen again.
As Jez mentions in the talk, it is not enough to have a system what is more important is to listen to these systems. All the following are required to make it a useful:
- A system to broadcast the current situation of the production line
- A culture to listen to the systems i.e. any time the system shows yellow or red, the team reacts to it accordingly
- A culture of reflecting on the situation to improve it further
Without 2&3, the first item doesn’t add much value.
The practice which helps us to create a system for Andon is Continuous Integration. With Build Pipeline extended to this, we can leverage it for having a flow to our production systems. But again the key is listening to the system i.e. when the pipeline is broken, fix it quickly and reflect on what can be improved.
IMO, the key to achieving continuous flow is small batches. Like in Toyota production line the system focuses to ship out each and every car with high quality, we need to make sure that each item [say the Features or Stories that the team works on], goes out with high quality so that we don’t have surprises in production. If we are deploying in small chunks than big chunks, it:
- Reduces the risk of failure
- Improves Control and visibility
- Helps for better feedback
What is difficult is to define what is small? In the book, The Principles of Product Development Flow, Donald G. Reinertsen talks about the formulae to calculate the batch size. That will be very much relevant for big teams or enterprises. But for many of us who are working with small or medium teams, I think we can rely on the guideline “that fits in your head”, as Dan North’s says Microservices: The software that fits in your head.
Something small enough if deployed helps us to get feedback —it has to be valuable for our customers for us to get feedback. I’ve been touching upon Small Batches in various posts, but am yet to give any practical examples. I will for sure covering it in the coming posts. But here are a few references about Small Batches you can read.
Update: This and other related topics will be in the upcoming DevOps Cookbook. DevOps problems are fundamentally flow…dev2ops.org