Lean Software Development
Lean Thinking was first introduced by Toyota in the 40s and then adapted to the Software Development world in 2003 — today I will enter you all in this methodology to understand his huge impact.
Introduction
Hello, developers! 🚀
Today we talk about one of my favorite stories: Lean Thinking was born in the 40s in Toyota in the attempt of the Japanese company to become a leader in the automotive world business. This attempt will be successful and will build the legend of the Toyota Production System and its inventor Taiichi Ohno.
Ohno realized that the main issue of Toyota was that they were used to a PUSH mass production approach because this was the successful approach they were used to when creating military means. The Japanese car market didn’t have the same size and requirements, of course, so he brought the idea to shift to a PULL production approach, driven by customer demand.
The Toyota Production System has become legendary and it’s still evolving and in use today, its main goal is to reduce waste over the entire flow of work, and its main characteristics are:
- The right process to produce the right results: a pull system to avoid overproduction and balance workload, building a culture of stopping to fix problems and getting quality from the start
- Add value to the organization by developing your people and partners: grow leaders who can then teach others, develop exceptional people and teams, and help your partners and suppliers improve
- Continuously solving root problems drives organizational learning: go and see for yourself to understand the situation, make decisions by consensus considering all the options, and build a learning organization
What this means is that it is a system for thorough waste elimination. Here, waste refers to anything which does not advance the process, everything that does not increase added value. Many people settle for eliminating the waste that everyone recognizes as waste. But much remains that simply has not yet been recognized as waste or that people are willing to tolerate. [Wikipedia]
From manufacturing to software
In a progressive process, Lean Thinking was taken as inspiration and transposed from the manufacturing to the software world, because smart people started to notice that there is much that the software world can learn from Lean manufacturing — a good (invented) story about this is the book “The Phoenix Project”.
In 2003, Mary and Tom Poppendieck wrote the book “Lean Software Development”, where they formalized the idea of Lean applied to Software, describing the 7 principles they based it on:
- Eliminate Waste
- Amplify Learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- See the whole
In a similar way to XP, since principles are pretty high-level, they went deeper with each of those to give some more low-level and practical description of what they meant.
Eliminate Waste
Eliminating waste is the most fundamental lean principles.
Software development has multiple types of waste, and the first step is to understand how to recognize them:
- unreleased work
- obsolete or unused features
- defects and bugs
- context switch
- waiting time
- handoffs
- unnecessary processes or documentation
- management activities
Eliminating waste is definitely the place to start, and the main activity to achieve this target is to measure the lead time: you should map the high-level process from the idea to giving value to the customer, and then measure the time of this process including both work and wait time; this is the lead time, and once you are measuring it your objective is to pick the biggest opportunities to increase flow and reduce the lead time (theory of constraints) and implement it — then measure again to confirm the improvement, and move on with the next bottleneck.
Amplify Learning
Generate the most knowledge at the least cost possible.
Software Development is most often a learning process, so we should embrace that it involves trial and error and handle it by consequence, for example:
- make sure feedback loops are in place and at the highest speed possible
- keep synchronization high: integrate code changes in small batches and make it fast to build and test the system (CI)
- work in (short) iterations delivering the highest priority item first and then get feedback
- Talk about constraints instead of solutions, and allow the obvious solution to emerge by getting feedback on multiple options
[ … continue … ]
Until next time, happy coding! 🤓👩💻👨💻
🙏 Thank you for reading this shortened version of this article. You can enjoy the full version on my blog here.
