Alan Shalloway has posted an interesting blog about how Scrum is evolving in its understanding of itself much the same way Extreme Programming (XP) did in the early part of 2000.  As someone who was very much into XP at that time, I agree that XP was first defined as the original twelve practices that you always had to follow and then morphed into XP is what you do after doing all the practices – not a very useful definition for people not familiar with the process steps.

However, the more I think about Agile and Lean, the more I become convinced that its ALL Lean and we do not need to rebrand what we do as “Lean-Agile”.  As I alluded to earlier, I believe that Agile is an instance of parallel evolution of Lean in the software industry.  Either by accident or deliberate thought, the Agile thoughtleaders of the late 1990’s came up with a manifesto for software development that is essentially Lean.  Only later when the Poppendiecks showed up (not sure when) is when many more people began to make the connections to Lean.

So what is Agile?  How is it related to Lean?  Lean is a set of values and principles that are portable across industries.  Unfortunately, many of the Lean practices were developed for manufacturing and if we have learned anything from Scrum it is this: software development is NOT a manufacturing activity, but new product development.  As a result, many of the original Lean practices are not applicable.  Normally, we would be out of luck as practitioners went through trial-and-error to learn what Lean tools worked in software, but we got lucky.  We had an independent instance of Lean appear in our industry about 10-15 years ago and we have gone through a lot of trial-and-error to understand what works and what does not.

IMO, Agile is the toolkit you use when you want to do Lean software development.  Many of the tools are mature, but there are also many gaps.  One that comes to mind is the weak state of product design in the Agile community.  Agile’s default position on product design is you iterate on your code until you get something the market wants – I think that might work if you have small products and\or only serving a single market segment.  For big organizations, multiyear projects that approach could be exceeding naive.  There are Lean tools out there that have gone through the trial-and-error process, so why not use them?