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.

Agile Styles: Dynamic Systems Development Method - DSDM

Jean Tabaka gave an overview of DSDM at Agile 2006. Jean begins by giving us some background on DSDM which stands for dynamic systems development method. DSDM has 9 principles. There is nothing remarkable about them other than that business people sat together and agreed on them.

1. Active users involvement is imperative

2. The team must be empowered to make decisions

3. The focus is on frequent delivery of products

4. Fitness for business purpose is the essential criterion for acceptance of deliverables

5. Iterative and incremental development is necessary to converge on an accurate business solution

6. All changes during development are reversible

7. Requirements are baselined at a high level

8. Testing is integrated throughout the life cycle

9. Collaboration and cooperation between all stakeholders is essential.

Collaboration and cooperation is one area of differentiation of DSDM. DSDM is very specific about having very clear stakeholder relationships that are explicitly brought in. This is really built into the method and it is not just be hopeful that stakeholders will like it.

Jean then presents the ‘3 pizzas and the cheese’ picture which represents the phases of DSDM. It has phases beyond development. There is the pre-project phase which is a feasibility study and a business study that addresses thing like how a project gets started and where the funding is coming from. Then there is Functional Model iterations, Design and build iterations, and Implementation iterations. Finally there is the post project phase which addresses things like what happens after deployment.

Next, Jean talks about the core agile components of DSDM. They include the 9 principles, the fixed time box, the collaborative and facilitated workshops, and the Prioritized requirement list or PRL. Like other agile methods, in DSDM the iron triangle is flipper over. Time and resources are fixed. Requirements are managed through prioritization and inspection and adaptation. Requirements are baselined at a high level usually using MoSCoW technique (Must have, Should have, Could have, Would like to have it) and delivery is between 2 and 6 weeks.

Other aspects of DSDM include being founded by business owners as opposed to software developers or engineers. It has specific integration points with business processes. It is phase driven. It is consortium-based which gives access to continuous growth of the method. It has licensing fees and multiple certifications which seems appealing to large enterprises.

Some of its benefits include documentation since 1995, continuously evolving, guidance maintained and updated in multiple languages, certification recognized worldwide, and provides a nice enterprise wrapper.

Jean wraps up by pointing us to the source as

This presentation is available on InfoQ at