Wednesday, September 06, 2006

Lean Software Development (LSD)

What is LSD?

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.”

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

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. 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

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.

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.

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.

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.

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.

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.

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.”



Post a Comment

<< Home