The discussion of applying lean principles to software development has largely focused on identifying and eliminating waste (in Japanese: muda). Lean Thinking equally aims to remove overburden (Japanese: muri) and unnecessary variation (Japanese: mura). Muda, muri and mura are called "the three M's." Together they form a dissonant triad. All three M's must be eliminated to create a sustainable lean process. This article discusses the relationship between the three M's and argues that the elimination of overburden should be the first step for software development organizations in order to create a lean process.
Waste
Waste, in lean thinking, is defined as: all activities that do not add value from a customer perspective and that can be removed. Examples are overproduction and over-processing, work-in-process or inventory, defects, hand-over and task switching, waiting and unused employee creativity.
Value-creating activities enhance the product from a customer perspective. A good question to ask is: "Would I be happy to pay for this activity as the customer?" If the answer is yes, it is likely to be a value-creating activity. Examples are discovering and understanding customer needs and writing code. Additionally, activities such as prototyping that create the relevant knowledge to develop the software system are also valuable as the late Allen C. Ward points out. Any activities that do not create value and cannot be eliminated under the current conditions are called "non-value added" activities. Examples are configuration management and project planning activities.
The Agile Manifesto acknowledges the importance of focusing on value-creating activities in software development when it states that working software is more important than comprehensive documentation. By eliminating waste we are able to create better products, faster.
Overburden
So what's wrong with focusing, first and foremost, on seeing and eliminating waste? Even though most traditional development organizations carry out few activities that truly add value, the right approach is often to attack a different disease first: overburden. As long as people work crazy hours, and as long as projects and teams are overwhelmed by the amount of work, the removal of waste alone is ineffective. Waste is likely to creep back in unless we limit the amount of work to the capacity and capabilities of the organization. Let's assume you try to eliminate defects but the project still suffers from overburden. Chances are that quality problems reappear since the project members still feel pressured and are overworked. In fact, overburden is a major source of waste such as work-in-process, waiting and delays, task-switching and defects.
Limiting demand to capacity and capabilities is exactly what Scrum and Extreme Programming do. By empowering the team to select a realistic amount of work for a given iteration, overburden is stopped and systematically avoided. A sustainable pace is achieved. Additionally, Scrum and XP create a pull process and a steady cadence where the team essentially pulls requirements from the product backlog and transforms them into product increments on a regular basis.
One of the benefits of a pull process is that in addition to avoiding overburden, it also makes waste and other problems visible. With excessive inventory buffers gone, problems now surface quickly. Scrum recognizes the importance of recognizing and removing problems and impediments. Its daily Scrum meeting serves to systematically identify problems.
Variation
A pull process with a steady cadence creates visibility of unnecessary variation, such as differences in the size and granularity of requirements put forward to the team in the iteration planning meeting, or the use of different build scripts. Other examples of unnecessary variation are using different development tools, applying development practices such as test-first and refactoring inconsistently, as well as not following coding standards. Variation creates waste such as defective software, over-processing and rework. Standards and norms eliminate variation.
Not all variation in software development is bad, though! For instance, formulating requirements at different levels of detail in the product backlog can avoid overproduction, over-processing and rework. Creating prototypes to explore different technology and design options is a form of necessary variation that creates the relevant knowledge to make the right architecture and technology decisions. Notice that is more economical to invest in organized experimentation early on rather than to bet on one grand but possibly unproven design idea only to partly rewrite the software system later on.
Summary
To establish a lean process, the traditional development system must be fundamentally changed and the right process must be established. For software development organizations this is best achieved by applying a pull process with a steady cadence as created by Scrum and XP. This is a form of radical improvement also called kaikaku in Japanese. Once the new way of working has been established, waste and variation must be systematically eliminated. The process is hence incrementally and continuously improved, which is also known as continuous improvement or kaizen in Japanese. Reflexion and continuous improvement is facilitated by regular retrospectives. In sum, establish the right process first by removing overburden. Then empower and encourage the teams to eliminate waste and unnecessary variation relentlessly.
Literature
- Jeffrey K Liker: The Toyota Way. McGraw-Hill. 2003.
- James M. Morgan, Jeffrey K. Liker: The Toyota Product Development System: Integrating People, Process and Technology. Productivity Press. 2006.
- Mary and Tom Poppendieck: Implementing Lean Software Development: From Concept to Cash. Addison-Wesley. 2006.
- Donald G. Reinertsen: Managing the Design Factory. A Product Developer's Toolkit. Free Press. 1997.
- Allen C. Ward: Lean Product and Process Development. Lean Enterprise Institute. 2007.
- James P. Womack, Daniel T. Jones: Lean Thinking. Touchstone Books. 1996.
About the Author
Roman Pichler of Pichler Consulting Limited, -works as an independent consultant, trainer and coach. Roman's clients value his rich and diverse experience ranging from helping start-ups as well as large global companies to apply Lean Thinking and Scrum. He is the author of the book "Scrum - Agiles Projektmanagement richtig einsetzen" (dpunkt 2007).
