The Lean-Kanban Manifesto
I'm pretty excited about heading down to Los Angeles today to speak, network, and attend sessions at the Lean Software and Systems Consortium conference. This is just the start of three conferences for me in May. I'll be speaking at the LSSC11, the Scrum Gathering and the Seattle PMI event. The differences between the mindsets of these three communities is very clear to me.
Later in this blog I will talk about some outdated Waterfall beliefs – please do not infer I mean the PMI has ever, or still holds, these beliefs. I can't speak to the PMI's mind set more than 10 years ago and I don't believe they have the outdated mindset now that many Agilists believe they do.
I believe Lean-Kanban is coming of age. There have been significant advances in the combination of Lean and Kanban over the last two years. As Lean-Kanban becomes more widespread, and as we better understand why it succeeds the differences between Scrum and Lean-Kanban appear to be greater and greater to me. The irony, however, is that at the same time, the Scrum community seems to think the two are not that different. This has occurred because many people doing Scrum have incorporated some Kanban practices into their Scrum framework (mostly managing work-in-progress WIP). Unfortunately, they have not usually acknowledged many of the key Lean-Kanban principles.
Kanban is not managing WIP (that's merely one of its many tools). To me, this is not unlike mostly Waterfall folks 10 years ago who evaluated where they were every four weeks and thought they were doing Agile. This, and other attitudes make me believe that Lean-Kanban is coming forth in a manner analogous to Agile's birth 10+ years ago.
I spoke about this a couple of years ago – A Tale of Two Communities . Many of the way Agile was thought about in the late 90s and early 21st century by practitioners of the current waterfall method, is not dissimilar to what I see many Scrum folks thinking about the Lean-Kanban community. Back then I heard – well, we build in stages too, every month or so we see where we are – so I guess we're Agile. Or, Agile doesn't' do any planning, how can it work? Or, Agile says no documentation, ever, which can't make sense. And no design either!
These statements were all wrong, of course. And the Waterfallers didn't want to really hear how. Nowadays I hear so much about Kanban that is incorrect that I even took the time to write an article for Cutter trying to set the record straight about it – Demystifying Kanban. To get a copy go to Cutter or to one of our events. Most of this misinformation about Kanban comes from folks who've never done it – much like 10 years ago. And again, in this case, the Scrummers don't want to hear how Lean-Kanban is different, but prefer to label those who discuss it bashers. It's déjà vu all over again.
I've been trying to get this point across for quite a while – with little success. During a conversation with David Anderson about an article on the principles of Lean he is writing, an idea sprang to my mind and it's the inspiration for this blog. It's a somewhat tongue-in-check "Lean-Kanban Manifesto." In this case, it's not Agile springing from Waterfall, it is Lean-Kanban springing from the classic Scrum model mindset many Agilists have. I call it
The Lean-Kanban Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
explicit conversations over intuitive abilities
small steps over big changes
quality systems over heroic individuals
principles that guide our understanding over practices in which we must trust
That is, while there is value in the items on
the right, we value the items on the left more.
I'm not looking for signatories or anything like that. I'm looking for people wanting to learn and to give up what they know to start using something better. To acknowledge when they have to reset their knowledge status from "expert" to "beginner." Boy, I've done that more than once in the last 2-3 years alone with Kanban. It's scary, but it's exciting, fun and more importantly, effective. If you're at any of the three conferences I mentioned at the start of this blog, please come up to me and tell me what you think of this manifesto. I'd love to meet you. I'm the Net Objectives guy (I typically wear one of my many Net Objectives shirts) with a goatee.
Postscript: After writing this, I discussed it with David Anderson and he had a great idea – to pursue this with a real Lean-Kanban Manifesto at the conference this week during the technical advisory board meeting on Tuesday. Be clear that what I've written here is not a starting point. What we'd like to do is to come up with a statement about how Lean-Kanban is different from both the software community and the Agile community. We now have the capability to articulate how we are different from Agile as well as how we are different from manufacturing focused Lean. This differentiation is necessary to truly create a community. When David and I first helped form the Lean SSC, the knowledge base and number of experienced practitioners was not what it is now. We want to take advange of this to how the Lean Software and System Consortium can best meet the needs of this growing community.
Alan Shalloway
CEO, Net Objectives
BTW: If you're interested in learning about Lean, Kanban, and Scrum in one course, check out our Lean-Agile Project Management course we have a couple coming up.
- alshall's blog
- Login or register to post comments


Technorati Tags:
tag with del.icio.us
Comments
Contrasting Agile and Lean
So, before I comment, a bit of background. I have been practicing one Agile form or another since signing the manifesto in 2000. I have since trained in Lean as part of Operational Excellence (abridged version of Six Sigma). I have worked for small start-ups (one becoming quite not-so-small) and for a Fortune 500 Financial Services organization, consistently as a senior member of technology teams.
All that said, my personal conclusion is that Agile is about creating new functionality while Lean is about defining the (typically people oriented) processes needed to put that new functionality to use for business value. They are highly complimentary, even essential to one another.
Of course I suppose you could also use Lean to define a process to create functionality in place of Agile. But I don't see the point. We already have Agile. Let's remember two of the most basic Lean principles; avoid local optimization and don't bother fixing something that already works really well. I believe we need to refine our understanding of how to be both Agile and Lean. But maybe that's your conclusion as well?
Now, using Lean to revise an existing software development process by replacing Waterfall with Agile ... that's more interesting.