I re-read Lean Software Development by Mary and Tom Poppendieck. My opinions haven't changed much of the book. It is late to the cause, and unlike the agile and XP methodologies this has vague type ideas, rather than concrete solutions and implementations. Again, I don't see that great a value in it. The ideology has been covered earlier and better in the scrum and agile books that have come before it.

One of their arguments is for the reduction of waste in the process. It is probably the most compelling part of the book. To the authors, waste is anything that does not add value, basically anything that does not go toward the final product.

The authors state that management does not add value to the product or the customer but they can reduce waste in an organization and have a high impact their. Often agile methodologies are introduced into a company or organization but there is no re-organization and the positions that existed under a heavy waterfall method; such as project managers and business analysts just get plunked into an agile. So there is no reduction of waste in that respect.

One of the purposes of agile is to have the product owners and engineers directly in communication with each other. The reduction of waste as that there are no layers of organization, no conduits of other people or positions for the goals of the product owner to get Chinese whispered before the engineers get it. I think one of the big failings of agile transitions is this. The Poppendieck's state;

Project tracking and control systems do not add value, and further, they may be an indication of too much work in the system. In a just in time manufacturing system, work moves so quickly through the factory so quickly that sophisticated tracking is unnecessary. If work moved through a development organization in a just in time manner, it would not need a sophisticated tracking system either.

One of the benefits of a continuous deployment system is that there is no wasted time going from dev, to QA, to stage and to production; it goes from check in, to automated tests, to production. The Poppendieck's continue;

Learning to see waste is an ongoing process of changing the way you think about what is really necessary. One way to discover waste is to think about what would jettison if had to get rid of all the excess baggage on a troubled project. It is usually easier to see waste in a crisis.

Since I have been in a troubled project in the last year one of the first things we did was drop the jump from development integration to QA and went straight to a second stage environment. There are other things I would have changed, we should have spent two weeks and automated the entire delivery mechanism from dev to prod.

What we haven't dropped, which we should have, was the vendor. The vendor has been unable to produce the quality output required, they have been unresponsive and this project was beyond their capabilities, more than their product could deliver, and was an entirely new methodology of delivery for them. Unfortunately we could not, we were trapped essentially, and an in house solution would have been better, faster and more astute as it turns out.

More Reading on Agile

• Agile
• Agile Training
• Differences Between Use Cases, User Stories and Scenarios
• Scrum Wall
• Book Review: Lean Software Development by Mary and Tom Poppendieck
• User Stories for Nanotoa
• When to Fix Bugs in Agile
• Behavorial Driven Infrastructure
• Lean Development and Elimating Waste in Projects
• Lean Development and Waste: Debugging Environments