More from Mary Poppendieck's Lean presentation.
After the introduction to lean, Mary illustrated how lean can be applied to software development. The lean tenets are:

1. Eliminate waste
2. Build quality in
3. Create knowledge
4. Defer commitment
5. Deliver fast
6. Respect people
7. Optimize the whole

Many of these topics have already been covered in Mary’s first book better than I can describe them here, so I will focus on new ideas on the first (Eliminate Waste) and last (Optimize the whole) points listed.

Eliminate Waste
In software development, the first principle “Eliminate Waste” requires us to put on “customer glasses” and see the world as customers do. Anything that does not add customer value is waste; these include:

• Paper work and lists – these are just delaying tactics
• Red tape, like signing off on specs and documents
• Anything that confuses people
• Stuff that does not work
• Features that are not needed

In manufacturing there are 7 classic forms of waste and these have parallels in the software development world.

Mary made a nice analogy, likening extra features to “project cholesterol”, the silent killer of projects that drown projects in complexity.

Optimize the whole
Software on its own is rather useless, it becomes of value to an organization when it allows business benefits to be realized. In this regard if we can shift from thinking of software projects to thinking more of software products we will be better aligned with the business.

Projects characteristics include:
Upfront funding, which leads to
Scope fixed at outset, which leads to
Success = conformance to Cost, Schedule, and Scope
Documentation is often tossed to supporting groups

Product characteristics include:
Incremental funding, which leads to
Scope expected to evolve
Success = profit, market share
Documentation typically stays with team

The key point being made here is that many traditional projects are one large batch. They have one lump of funding, one set of requirements, one deliverable, and one set of documentation. From a lean perspective these large batch sizes are wasteful, and it would be preferable to model software development after a product lifecycle that gets smaller batches of funds and requirements and then assesses success by business value. Evolution is expected and the documentation stays with the team.

Finally, Mary wrapped up by talking about meaningful metrics, she confirmed that many traditional metrics such as lines of code are counter productive, and suggested 3 holistic measures to focus on:

1. Average Cycle Time – how long things take to go through the system. E.g. requirements from capture to acceptance and defects from detection to correction.
2. The Business Case – Is the project still viable? Without this, everything else is irrelevant.
3. Satisfied Customers – are your customers happy?

These are great measures to track and a nice introduction into discussing one of my favourite books “Managing the Design Factory” by Donald Reinertsen.