We can thank Mary Poppendieck for popularizing Lean in software development. The concept itself comes from industrial design and manufacturing at the Toyoda Automatic Loom Works in post-war Japan. It’s through industrial process management that Mary Poppendieck became immersed in the principles and practice.
She built one of 3M's first Just-in-Time production systems. In 1998, she was put in charge of a waterfall software project and saw the same approach could improve outcomes. In 2003, she published Lean Software Development: An Agile Toolkit with her husband, Tom. In it, she lays out seven Lean principles:
Principle #1: Eliminate waste
無駄 (“muda”) is a Japanese word meaning futility, waste, or pointlessness. If you are doing something that does not create value, it is a waste of yourself. In Lean, waste is defined as “anything that does not create value for the customer.”
According to the Lean Enterprise Research Centre (LERC), 60% of a typical manufacturing process is waste. Learning to see waste is key, as it is not always obvious to the uninformed observer. Once you learn to see waste, use that skill to uncover the biggest sources of waste and eliminate them. But don’t stop there. Continuously repeat the cycle to maintain efficiency over time.
The Toyota Production System identified seven forms of 無駄, which Mary Poppendiek mapped to equivalent forms of waste in software development.
TPS Manufacturing
Lean Software
Overproduction
Extra Features
Waiting
(Waiting)
Transporting
Task Switching (20% overhead)
Inappropriate Processing
Inappropriate Processes
Unnecessary Inventory
Partially Completed Work
Unnecessary / Excess Motion
Lack of Collocation (Handoffs)
Defects
(Defects)
A value stream is where you chain together the core processes from input into your system to the final outcome that creates value for your business. In eliminating waste from a value stream, you create the most predictable and efficient flow of work to optimize value for both your customers and for your company. So, how do you measure waste in the value stream? Consider four key metrics:
- Created versus finished. In a given period, how many tasks were created and how many of those were completed? Any work or resources not delivering the value it is intended to deliver is possible waste.
- Work in progress (WIP). How many tasks are started, but not finished, at any given time? Having too much work open at the same time results in waste.
- Lead time. What is the total time it takes for a task to go from the start of the value stream to the end of the value stream? Changes in lead time can indicate bottlenecks, which lead to waste, or new areas of waste. Note that a long lead time is, in and of itself, waste.
- Cycle time. What is the amount of time people actively spend working on the task, not including wait time? In an ideal system, the lead time for a single task is the sum of the cycle times. The larger the difference between cycle and total time, the more time the task sits, waiting to be worked on–which is waste.
Principle #2: Amplify Learning
One of Mary Poppendieck’s fundamental insights is that software development is not a manufacturing task. It is a problem-solving task. When industrial designers are trying to address complex problems–which is what software is–they work in an iterative process, making tight loops from scenario examination, requirements elucidation, high-level solution segmentation, and low-level design of difficult elements, then going back up to the big picture and diving back down to the details, adjusting design through these continuous loops.
Agile and Lean practices support the same complex problem solving through iterative loops that allow for adjustment of features, vision, and learnings as software teams move through Iterations, Team Commitment, Frequent Delivery to a highly available Customer, Negotiable Scope, Information Radiators, Refactoring, and Continuous Improvement (Retrospection)
Set-based design (SBD) is used in industrial product design but also applies to software development. SBD is the practice of keeping design options flexible for as long as possible during the development process. For example, in Japanese firms working on new product development, they would first define the constraints of the design–but only those constraints that were essential. Then, multiple teams would be assigned to the problem, to design a solution that achieved the goal within the defined constraints.
Critically, upon comparing final designs, no single design was assumed to be the “winner.” Instead, winning elements of each design that advanced the understanding of the problem would be chosen, added to the constraints of the design, and another round of multi-team design launched. Ultimately, this iterative process yields one final solution that reflects the thinking of all the different teams, rather than the work of only one team. This more organic, collaborative approach to healthy competition breeds better culture and leads to better results.
Principle #3: Decide as late as possible.
The last responsible moment is the point where failing to make a decision closes off valuable options. Using a parallel design approach and designing to allow for change supports greater collaboration. Don't over design your solution–leave things open until you have better information.
Principle #4: Deliver as fast as possible.
Delivering as fast as possible is not about aggression. It's not a land grab, it's farming. Delivering as fast as possible complements deciding as late as possible–the faster you can deliver, the longer you can delay decisions. The two go arm-in-arm in 看板 (“kanban”), a pull queue concept fundamental in Lean and Agile.
斑 (“mura”) mean unevenness or irregularity. 斑 or variation in a value stream is not good. If variability exists earlier in the value chain, it will be increasingly amplified as you go down the chain–small delays early in a process become larger delays further down the process. Conversely, overperformance in an earlier part of the system hurts performance by increasing work in progress further downstream. The goal is to reduce cycle time of the entire process. This requires slack so that you have resources to keep continuous flow.
無理 (“muri”) means impossible or unreasonable. This is the opposite of maintaining slack. A team performing at peak speed is unable to take time to organize and think creatively about the problem. They trade off essential, but not immediately necessary, tasks in order to maintain output, but that reduces overall quality. Any system performing at high utilization is unable to accommodate variability and can lead to backlogs and delayed delivery of larger scopes, which subverts lean principles.
Principle #5. Empower the team.
Mary Poppendieck advises, “Nurture the system and the people who produce the results rather than push a system to meet targets beyond its capability.” There are aspects of that in terms of how you organize.
Leadership needs to provide a clear and compelling purpose. Management needs to translate that into action. And cross-functional teams need to have access to the customer team and set commitments, while management runs interference for them. Part of this includes keeping skeptics outside the team.
改善 (“kaizen”) means change for the better. The fundamental action of an innovative company is knowledge creation and sharing. 改善 is a philosophy, not a meeting. It is about empowering the team to make things better. The scrum concept is “Stop the line,” or If I see a defect in the process, I am empowered to stop the process, and then we will all stop and reflect on how to improve the process.
Principle #6: Build integrity.
Part of the 改善 process is continually trying to improve the process. Great products have two qualities: conceptual integrity and perceived integrity. Conceptual integrity is the architectural integrity, or how much things make sense. Perceived integrity is the totality of the product, or how the customer experiences the product. To achieve these qualities requires quality and testing.
Principle #7: See the system as a whole.
Remember: Over-optimizing any piece of the system will actually lead to the entire system performing worse overall. Take a step back, look at the entire company as a system and model its dynamics, including how decisions are made and how information flows, to identify and remedy any unintended consequences.
This brings me to 守破離 (“shuhari”) or Deliberate Practice
Agile is an adaptive process, but you cannot adapt the process until you achieve mastery of it, understanding the process intrinsically and conceptually. When discussing lean concepts, both internally and with clients, I like to emphasize 守破離, which is the Japanese style of learning a craft or technique.
守 (Shu) When you first approach a practice, you need to embrace the kata (the way or method of doing the thing you need to do). Mirror the practices ego-lessly and repetitively. Do this longer than you think necessary -- exhaust your patience and keep going. At some point, you'll achieve a surprising (10x?) improvement in performance.
破 (Ha) Only then can you optimize the kata. Experience has taught you what good looks like. You'll know when and how to alter a practice to achieve an immediate goal, validate that the change worked, and still keep the team or process on track towards its long term outcome.
離 (Ri) Finally, you can discard the kata. Work from instinct and improvisation. I suspect I will only achieve this in a narrow piece of what I do. I have had a few opportunities to work with the same people on a consistent set of compelling challenges for long enough (years) to achieve high performance. But, over time, I've changed roles, industries, and the problems I need to solve. In response, I find myself embracing new kata. In fact, the kata I most aspire to master is the way of learning itself.
Ken Judy
