I guess I am somewhat late to this discussion - but hopefully you will see this and respond. I am still early in my learning of Lean Software Development - and your two posts were very instructive.

However, I am left with a nagging question - how different is all this from Agile or Iterative development - both of which also talk of many of the same things such as delivering in small chunks, delivering continuously for faster market/ customer feedback, etc.?

A secondary question - based on the current capabilities of various software engineering and project management tools, what can software teams actually practice of Lean methods? There are a lot of tools that support Agile development, including the one my company produces - are there tools that explicitly provide Lean related processes, workflows, metrics and measures? Or are Lean practitioners able to do Lean projects using standard/ Agile tools in the market - in other words - is it more to do with the methods than the tools?

Thanks,
Mahesh

I very much agree with you about the overspecification of tools and practices, and you picked a good example. I like User Stories, and sometimes I use them because sometimes that is an appropriate method. Other times it isn’t. I’m glad I know more than one requirements analysis technique. Right tool for the job. No golden hammers.

The areas where I believe lean software development practitioners betray lean’s roots is specifying certain technologies or patterns. The whole point is that process will be specified at a team, or organization level from the ground up. One example of this would be declaring that you can’t have lean without test driven development.

PDSA is also known as the Deming cycle, which is an evolution of the earlier PDCA / Shewhart cycle.

You’ll find metrics galore in the new Don Reinertsen book, but the core are your basic throughput metrics: throughput, cycle time, lead time, work-in-process, station availability. “Software by Numbers” also makes a solid economic argument.

We’ve been seeing 2-4x productivity improvements over comparable teams using Scrum-like methods (e.g. http://www.ddj.com/architect/218000215), and even bigger improvements over teams using traditional phase/gate methods. But of course, this stuff is really about scale and enterprise integration. Team performance improvement is mostly a bonus feature.

Can you provide some pointers in the way of metrics to feed the idea to more data-oriented personalities? I agree with the concepts in the article, but the art of pursuasion usually requires back-up data, and specifically data from the software industry.

I had never heard of PDSA specifically, but it sounds just like the Six Sigma DMAIC concept. The continous improvement ideas are also stressed in Human Performance Technology.

The stop-the-line case from the parallel workflow example might not stop the “design logic” step immediately. If that workflow segment is kanban-limited, then the second path will continue to process any work that is already underway. If the problem on the first path is not resolved before the second branch completes, then the second branch will stall. This might be a good thing, because the people working on the second branch can use their capacity to try to help the first branch resolve their bottleneck instead of building up new design-in-process inventory that will then have to be burned off at some downstream bottleneck.

The second branch might also stall if it is determined that the root cause was a defect in the specification step that preceded both design steps.

There is no one Lean development process, so the first step is usually Value Stream Mapping to show how people really work in your business.