Sunday, July 15, 2007

Agile Styles: Lean

Leading Lean Software Development: Results Are not the PointMary Poppendieck covers Lean Software Development at Agile 2006. She mentions that Lean came into being in 1990 based on book ‘The Machine that Changed the World’. The book compares and shows the advantages of Japanese auto manufacturing vs. USA manufacturing. Most of the Lean practices trace their history back to Toyota. Originally it used to be Just In Time (JIT) and then later it became Lean. It’s used it manufacturing, operations and supply chain. We can’t apply it directly to software development, but we can use the Lean principles and look closed at Lean practices in product development. These principles end up deriving the agile practices.

Next Mary discusses some fundamental principles of Lean. She starts with eliminating waste. The trick here is to decide what waste it. She states that it is the customer’s view of waste that matters. MUDA is Japanese for waste or anything that does not add customer value.

Then Mary mentions that Testing is not for finding defects. In lean the job of testing is to prevent defects. If you have a quality process, you are building quality into the code. If you routinely have test and fix cycles, it means you are testing too late. Your process is defective. Final verification should be used to verify that something is working as expected and not for debugging. Defects are a management problem. We should look at defects as caused by a system which allows defects instead of just caused by developers.

A fundamental principle of Lean is to respect people. Toyota’s success was based on their ability to harness intellect of ordinary employees.

Lean looks at the whole picture. Software by itself is useless. It needs to be embedded in a business process, hardware, or an activity to become useful. The goal of software development is to support the development of a complete product (a process that helps customers get job done). The team should include business people not just developers.

Next Mary covers the process of iterative development. She also mentions that if churn or requirement change is as high then you are writing requirements too soon. You should move requirements gathering later into the process.

Lean has quality built in by having:
1. Standards: Architecture, Conventions, Tools. These should constantly be challenged and changed.
2. Continuous improvement: Improve the process, refactor the code.
3. Synchronization: Merge early and merge often. Configuration management, automated build, one click build, continuous integration, nested synchronizations, stop and fix if something is wrong
4. Frequent deployment. Small releases, automated deployment, automated installation.

Implementing Lean Software Development: From Concept to CashOnly when quality is built in, one can deliver fast. This provides a significant competitive advantage by rapidly respond to change, and a larger barrier to entry. Examples are of Lean companies with such an advantage include Dell, LL Bean, FEDEX, Toyota, patientkeeper.

Mary then discusses risk. Sources of risk include un-coded requirements, untested code, un-integrated code, or code that is not used in production. The best risk mitigation is synchronization which includes early automated testing and continuous nested integration. The big bang is obsolete. There should be no partial credit for incomplete software.

Next Mary defines cycle time as the average end to end process time from problem detection to problem solution. It begins and ends with customer. Software development cycle time is the speed at which a customer need is reliably and repeatedly translated into deployed software. Mary list 6 ways to reduce cycle time straight out of queing theory.

1. Even out the arrival of work:
2. Minimize the number of things in the process: stop trying to do too much
3. Minimize the size of things in the process: work in small increments
4. Establish a regular cadence: deliver every 2 weeks
5. Limit work to capacity: do not do more that org can handle
6. Use pull scheduling:

Finally Mary discusses 3 holistic measurements:

1. Cycle time: from concept to release or from defect to patch or from feature request to deployment.
2. Business case: Did we achieve business case. P&L, Market share, ROI.
3. Customer satisfaction: Net promoter score. Would you recommend product to a friend? Correlated to market share and long term growth.

This presentation is available on InfoQ at