Dan opened his talk by addressing the difference between Agile and Lean directly. And in his view there is no difference. Perhaps someone else who was in the room can help me with the exact quotes but this is how I remember him putting it:
• When Dan, Jim Womack and Daniel Roos wrote did the research that resulted in The Machine that Changed the World they had to think of a term to describe what they found. Toyota Production System was too Toyota specific. They eventually came up with Lean. In the process they considered the name Agile but rejected it - “because it wouldn’t sell” he quibbed.
• Later (someone who’s name he gave but I don’t remember) decided there should be an “American version of Lean” and decided to use the term Agile. As far as Dan can tell it is this source that the original Agile software people (those who wrote the Agile manifesto I guess) picked up on.
• As far as Dan is concerned he doesn’t care which term we use, its all the same.
• (And he’s glad to see IT folk taking an interest because traditionally the Lean manufacturing movement has found IT a block to Lean adoption.)
I’m glad to hear Dan say this, certainly my flavour of Agile has long been influenced by Lean - even before the Poppendieck’s excellent Lean Software Development. I now feel more able than ever to talk about them as one.
That said I think there is a subtle distinction, its actually a distinction that can be helpful on some context. Its also a distinction which helps explain why Agile is not XP even though XP is Agile and why there is more to Agile than Scrum.
It helps to look at this diagram - if you’ve seen it before you’ll notice I’ve extended it recently:
At the top there are specific Agile methods like XP, Scrum, Crystal, etc. These are quite prescriptive in their ways - some more than others. Each is an Agile method but none are Agile.
Agile is a toolbox, these methods have chosen elements from the toolbox. Agile is more general, Agile is more of a value system, a philosophy.
Agile itself is Lean but it is more prescriptive than Lean. Few Agile teams would not do Test Driven Development for example. So while Agile is more general than XP or Scrum it is less general than Lean.
Lean itself is more philosophical still and contains fewer specific practices. You have to apply Lean thinking in your own context. Lean is a journey.
Still further down we find Organizational Learning. All these methods are based on continual learning - systems thinking should probably be included in here. But organizational learning is almost entirely values, philosophy and academic research, it is almost devoid of specific practices. (I could get into the Knowledge Management debate here but not today.)
Recently I’ve added RUP and Kanban to this diagram.
RUP shares a lot in common with Agile methods but it comes from a very different place. It comes from traditional software engineering, it comes from the unification of object orientation and it comes from the commercial world. RUP can (I am told) be made to look and feel like Agile but this doesn’t change where it comes from.
Then there is Kanban. Kanban is the new kid on the Agile block but it is derived more direct from Lean thinking. So for me it doesn’t inhabit that top apex of the pyramid, it draws on Agile and Lean. And this is where Dan Jones point is very appropriate: it doesn’t matter, at this level Agile and Lean are merging. So if you want to argue that it should be up there with XP and Scrum I don’t mind.
My feelings exactly. I was at the presentation at XPDay and also can't remember the exact quotes, but can substantiate your inference with the post I wrote here. I have recently been getting annoyed with David Anderson trying to make a polar distinction between Agile and Lean. In my mind they're close enough to being the same thing that it's not worth arguing the toss!
ReplyDeleteHi Allan,
ReplyDeleteThe problem is the labels and using them to selling ideas. To sell something you need to label it and yo also need to differentiate it from the competition. Interestingly the Japanese do not have labels like Lean, Agile, Six Sigma, TQM etc. These were all invented in the west.
In reality no off-the-shelf process will solve all your problems for you and there will always be gaps that you will need to fill in yourself. I like your pyramid, and it fits with how I use these ideas. I especially like your bottom tier of organisational learning, which I presume refers to the teachings of Edward Deming.
If practices at the top of the pyramid do not address my needs then I fall back on the values and philosophies lower down inorder to come up with practices of my own that do. I got this idea from Kent Beck in XPE1.
Interestingly the joins aren't seamless. For example, Lean Thinking places a big emphasis on the principle of eliminating waste. This emphasis is much less prominent in Agile, where the emphasis is on amplifying learning.
I believe this is why Kanban doesn't neatly fit into the pyramid. Whilst Agile builds on the values and philosophy of Lean Thinking, it has also derived an emphasis, principles and practices of its own that are deemed appropriate to software development. Kanban isn't an attempt to fill in the gaps, but rather an attempt to replace Agile with something else - Lean.
I think this is a mistake. Higher up the pyramid you go, the more prescriptive the practices become, and the more taylored they are to the context of software development. We shouldn't be looking to replace software principles and practices with manufacturing ones.
Paul.