Most people working in professional IT-driven companies, have heard about Agile, most people in professional companies have heard about Lean. Those who are interested in the subject, have found out that these two very popular phrases are actually closely related. So what is the relation between lean and agile? I'll try to briefly answer this question and will start with a little history.
Contrary to popular belief, the origins of Lean aren't in Japan, but derive from the Ford company in America and the work of the American statistician W. Edwards Deming. The following excerpt states the heart of his philosophy:
by adopting appropriate principles of management, organizations can increase quality and simultaneously reduce costs (by reducing waste, rework, staff attrition and litigation while increasing customer loyalty). The key is to practice continual improvement and think of manufacturing as a system, not as bits and pieces.
Eliminating waste and continuous improvement are very famous elements in Lean Thinking and are applied in Agile methodologies. Edwards also made the widely-used PDCA-cycle famous (Plan-Do-Check-Act). Two of the fundamental pilars of Scrum are Inspect & Adapt and one can easily see the close relation to PDCA's Check & Act.
The work of Deming formed the base of the Toyota Production System, invented by Taiichi Ohno. Ohno says that everything he knows he first learned at Ford. Then all he did was go back to Japan and remove waste (The Machine That Changed the World). The main objectives of the TPS are to design out overburden (muri) and inconsistency (mura), and to eliminate waste (muda) through the process of continuous improvement — kaizen. The principles & practices of the Toyota Production System are the base of what we now know as "Lean Manufacturing", used in many industries. The core principles and techniques used in TPS, are at the heart of many Agile techniques (techniques that allow you to respond and adapt to change, and take advantage of opportunities while controlling risks).
For example, they form the foundation of Scrum. Scrum for software was directly modeled after "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka published in the Harvard Business Review in 1986. This is the article in which the contrast is made between a traditional sequential or “relay race” approach and a holistic or “rugby” approach. Hence the name Scrum was derived. Takeuchi teaches Scrum in his classes at Harvard Business School. To him, Scrum is only indirectly related to software development. It is directly related to leadership and running the top companies in the world. It's about cross-functional teams working intensely together generating continuous improvement. As Jeff Sutherland, co-inventor of Scrum states: "The “lean techniques” touted by Western observers are side effects of what Takeuchi and Nonaka see as the root cause of performance. And the root cause is Scrum, which is teams engaged in continuous improvement." and: "The lean techniques can all be seen in a good Scrum if you look for them. I was the Chief Engineer for the first Scrum team, hired to deliver a new product in six months that would replace all legacy products. We implemented the ScrumMaster who worked on the line just as Taiicho Ohno set up at Toyota to improve on what he saw at Ford. One of our biggest customers was Ford Motor Company. The speed of the software market means the Chief Engineer needs a product owner to keep up. The product owner is embedded in the team and drives all priorities based on going to the market and then going to the gemba. Poka yoke is embedded in all Scrums that I am responsible for through a systematic prioritization of automated testing to make deployment fail safe. _If you do not see these things in a Scrum, the people have not studied Takeuchi and Nonaka and have not implemented it properly." _
The phrase Lean Software Development originated in a book by the same name, written by Mary Poppendieck and Tom Poppendieck. Lean development can be summarized by seven principles, very close in concept to TPS principles:
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- See the whole
Kanban is a method for developing software products and processes with an emphasis on just-in-time delivery while not overloading the software developers. It emphasizes that developers pull work from a queue, and the process, from definition of a task to its delivery to the customer, is displayed for participants to see. The Kanban method as developed by David Anderson, is rooted in these basic principles: Start with what you do now The Kanban method does not prescribe a specific set of roles or process steps. There is no such thing as the Kanban software development process or the Kanban project management method. The Kanban method starts with the roles and processes you have and stimulates continuous, incremental and evolutionary changes to your system. Agree to pursue incremental, evolutionary change The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. Sweeping changes may seem more effective but more often than not fail due to resistance and fear in the organization. The Kanban method encourages continuous small incremental and evolutionary changes to your current system. Respect the current process, roles, responsibilities & titles It is likely that the organization currently has some elements that work acceptably and are worth preserving. We must also seek to drive out fear in order to facilitate future change. By agreeing to respect current roles, responsibilities and job titles we eliminate initial fears. This should enable us to gain broader support for our Kanban initiative. Perhaps presenting Kanban against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities and perhaps the wholesale removal of certain positions will help individuals to realize the benefits. Leadership at all levels Acts of leadership at all levels in the organisation from individual contributors to senior management should be encouraged.
As one can see, Agile Methodologies, Scrum, Lean Software Development, Kanban etc. all have very strong ties and often overlap each other. They all have in common that they are highly influenced by and are based on The Toyota Production System. I often see development teams going "through the motions" of specific agile techniques or frameworks, without actually realizing the fundamentals that are at the core of these frameworks. True Agile /Lean software development simply does not exist without the principles behind TPS like continuous improvement (Hansei / Kaizen), eliminating waste (Muda) and empowered teams. Original article