The Lean-Kanban Manifesto

May 1, 2011 — Posted by Al Shalloway

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 90's 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 advantage 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.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


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.

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban