Lean Software Development Overview

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.


[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:

Mark Windholtz writes a short introduction to Lean Software Development

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

2 Responses to Lean Software Development Overview

  1. Darrell says:

    I would say that your Takt Time is the rate at which you release the software into production, NOT your iteration length. If customers are happy with a production release every 3 months, do it! For software, in my opinion it seems, the release to production is favored over customer payment (although if you have a web-based app these may be the same thing). A decrease in Takt Time is another thing that makes web apps so attractive over desktop apps. Releasing a desktop app to production every few months, if it included installation etc., would drive users nuts. However, if it is over the web and they just start getting new features, then they’re very happy.

  2. Rich Horrigan says:

    How would you develop a Takt Time with regards to the actual value stream mapping? Would you even bother to do this?


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>