What is LSD?

Lean Software Development (LSD) is the application of lean principles to the craft of software development. So what is Lean? According to the National Institute of Standards and Technology Manufacturing Extensions Partnership’s Lean Network, Lean is:

“A systematic approach to identifying and eliminating waste through continuous improvement, flowing the product at the pull of the customer in pursuit of perfection.” [1]

“Lean Software Development reduces defects and cycle times while delivering a steady stream of incremental business value.” [2]

Lean Software Development is more strategically focused than other Agile methodology. The goals are to develop software in one-third the time, with one-third the budget, and with one-third the defect rate. [3] (Note that although Robert Charette’s original Lean Development concept was the foundation for Lean Software Development, he has not written much easily available information, so most of the analysis here will concentrate on Lean Software Development as presented by Mary and Tom Poppendieck.)

Lean Software Development is not a management or development methodology per se, but it offers principles that are applicable in any environment to improve software development.

The LSD Principles

There are seven LSD Principles:

1. Eliminate waste. In software development, waste is anything that does not improve the quality of code, reduces the amount of time and effort it takes to produce code, or does not deliver business value to the customer. In other words, any activity that does not “pay for itself” in reduced effort elsewhere in the system.
   Tools: Seeing Waste, Value Stream Mapping.
   
2. Amplify learning. For programmers to develop a system that delivers business value, they will have to learn about many things. Some are technical, such as the advantages and disadvantages to various approaches to do remote communications in .NET (i.e., remoting, COM+, web services, etc.). Others are requirements related, such as understanding what the business user really needs versus what the developer thinks the user needs.
   Tools: Feedback, Iterations, Synchronization, Set-based Development.
   
3. Decide as late as possible. The idea here is to wait until what the authors term “the last responsible moment” to make a decision. This is the moment at which, if the team does not make a decision, the decision will be made for them (doing nothing is a choice). The benefits of this are avoiding or delaying the costs of change, which obviously cannot be incurred if you have not limited your options yet.
   Tools: Options Thinking, The Last Responsible Moment, Making Decisions.
   
4. Deliver as fast as possible. This is the foundation of iterative development. Requirements change as a percentage of the original requirements increases non-linearly as the amount of time increases. Typical 9-12 month projects generate roughly a 25 percent change in requirements. However, the amount of requirements change over a month averages only 1-2 percent. And it is much easier to get users to accept waiting until next month rather than next year.
   Tools: Pull Systems, Queuing Theory, Cost of Delay.
   
5. Empower the team. The quality of a software team (the people factor) is the most important element in successfully delivering software. In order to get people to take responsibility, get motivated, and gel as a team, they need to be responsible for the outcome and authorized to make it happen.
   Tools: Self Determination, Motivation, Leadership, Expertise.
6. Build integrity in. The authors make the distinction between perceived integrity and conceptual integrity. Perceived integrity is the customer’s experience with your software. Conceptual integrity is how well the architecture and system components flow together to bring about the perceived integrity. Obviously testing, unit and integration, is a major part of integrity. [4]
   Tools: Perceived Integrity, Conceptual Integrity, Refactoring, Testing.
7. See the whole. Systems thinking has been around for a while, but the typical response to solving problems is to break them down into their constituent parts and optimize each individual piece. This is suboptimization, which leads to the “tragedy of the commons.” [5]
   Tools: Measurements, Contracts.

Applying LSD

Included in the Lean Software Development book are 22 tools. The authors show how to use these tools to identify problem areas and discover possible solutions. Each principle also includes a “try this” showing steps you can take to immediately start applying Lean at work. Since these are principles, they will have to be customized to each situation in order to bring any value. This is not something that can be bought and thrown at an existing problem without any effort.

References

[1] Kilpatrick, Jerry. Lean Principles.

[2] Windholtz, Mark. Lean Software Development.

[3] Highsmith, Jim. Agile Software Development Ecosystems.

[4] Poppendieck, Mary and Tom Lean Software Development: An Agile Toolkit Chapter 2, Amplify Learning, is available online at (http://www.poppendieck.com/pdfs/AmplifyLearning.pdf).

[5] Heylighen F. The Problem of Suboptimization.

For More Info

Many of Mary Poppendieck’s publications are available on her web site (http://www.poppendieck.com/publications.htm).

Peter Lindberg writes a thorough review based on a draft copy of the manuscript:

• Lean Development Part 1
• Lean Development Part 2

Mark Windholtz writes a short introduction to Lean Software Development