This post originally published by Mike Cottmeyer for Agile Chronicles, May 2009.

Here I am.. Sunday afternoon.. Mother’s day. Just got back from taking the family out for a low key Mother’s day celebration and now I’ve got a little quiet time before the week begins. The conference last week was quite a rush… had a great time… met a lot of great people. Before the week gets going I want to sort through some of my thoughts on this whole Lean/Kanban thing.

A bit of history… Mary Poppendieck was one of the first few authors I ever read when I got formally introduced into the agile community. I recall how much her book resonated with me then… and looking back I can see how much it influenced how I think about agile… and the agile movement as a whole. I tell you guys that to say I have never made much of a distinction between agile and lean. To me… it was just a different way of looking at the same fundamental truth.

A buddy of mine recently told me the story of the blind men and the elephant. The general idea of the story is that we have a bunch of blind guys in a room with an elephant (sounds like a problem waiting to happen to me). These guys are each touching the elephant on different parts of its body. The guy touching the tail says an elephant is like rope… the guy touching its leg says the elephant is like a tree… the guy touching its ear says it is like a giant leaf. You get the idea. The point is that without being able to see the whole… they each describe the elephant from their own particular point of view.

As I watch people debate over what it means to be agile… it seems we were a bunch of blind men arguing over the nature of the elephant. If your point of view is small, colocated teams… scrum brings a valid perspective. If your focus is more technical… the practices of XP tend to resonate. If you come from a larger more structured organization… you might need AUP or DSDM. If you have a really small team of experienced developers… let’s talk Crystal. Context is everything.

It seems to me that much of our debate is out of context. When we get dogmatic about one methodology… about one set of practices… we are often not taking the other person’s context into consideration. That is why the Agile Manifesto was so powerful… it was a set of value statements… it was a set of principles… that was broad enough to be applied in a situationally specific way. We have to take the local context into consideration.

I don’t think the Lean/Kanban proponents are saying they have found a better way… I think that we are continuing to learn and to grow and to better understand what it takes to deliver great software. It seems to me that the Lean/Kanban movement is not out to replace XP or Scrum or DSDM but to help organizations that are having trouble adopting these practices… or have adopted them and need something else to increase their productivity.

Here is a quote from the Schwaber and Beedle book “Agile Software Development with Scrum”…

“Empirical process control models are elegantly simple. They employ feedback mechanisms to monitor and adapt to the unexpected, providing regularity and predictability. The actors in a Scrum team empirically devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves”

The line about the team devising the best processes possible based on their slkills, experience, and the situation in which they find themselves has always resonated with me. I think that Lean and Kanban give us another set of processes and tools that can help the team improve. I do not believe Lean and Kanban are at odds with Scrum… nor do I believe that Lean and Kanban are going to be successful without the engineering discipline encouraged by XP. We are just another set of blind men looking at a different part of the elephant.

My personal take…

Kanban is a visual process control tool that helps teams effectively manage the flow of work through the sprint. Scrum gives guidance that the team decides what they can do… and the team decides how it will get the work done. Kanban gives the team another way to inspect and adapt and to learn how to get better. I am not hung up on the fact that Kanban is iterationless… I can apply it within the iteration. If I determine that the iteration has become waste and no longer need it… I’ll get rid of it.

My goal has never been to do Scrum… my goal is to build great software as fast as possible. In Scrum process improvement is implicit… the team inspects and adapts and find ways to get better. In Kanban we put specific visual controls in place that help the team better understand the flow of work through the sprint and make targeted improvements as necessary.

To me the idea of Lean is a bit broader… lean deals with the enterprise. Lean is about managing the flow of work across teams. How do I take an idea that comes from biz dev… turn it into a product idea… get the work assessed and approved… built… tested… delivered to the customer… billed… and supported. Lean can give us some guidance here for how to manage the flow of value through the organization. Kanban is a tool… Lean is a philosophy.

A team could use a Kanban board to manage the backlog item through the development phases… analysis, design, code, and test. An enterprise could use Kanban board to manage the flow of an idea from inception through development to billing and support. The principles of Lean can be applied within the team and across the teams. Understanding value streams… identiying constraints… eliminating waste are all explicit ways of helping the team get better. These are principles and tools that explicitly help the team inspect and adapt and make better decisions.

As a founding member of the Lean Software & Systems Consortium I hope we continue to build on what is out there and resist the urge to make this something wholy new. Remember… agile is all about uncovering better ways of developing software by doing it and helping others do it.

Lean/Kanban gives us another set of tools to help that come about.

Share on facebook
Share on twitter
Share on linkedin

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

Six Actionable Nuggets of Advice for Becoming a First-time Technology NED

If the pandemic has taught companies anything it’s that tech is not something that you put off and think about ‘later’. The last year has seen organisations go through huge digital transformations, whether planned or otherwise. And for those that aren’t technology-based companies, getting the right board-level advice can not only be hard to find, but the difference between success

Read More »

Culture, Skills, and Capabilities // How to become a more data-driven organisation

In our whitepaper “How to become a more data-driven organisation”, we wrote about the five steps that an organisation would need to take, which are: Outcomes: Defining goals and metrics to ensure clear and measurable outcomes Analytics: Implementing and sharing the analytics to improve data-driven decision making Innovation: Testing assumptions through hypothesis testing and learning Data Platform: Gaining new insights

Read More »

Data Platform // How to become a more data-driven organisation

This is the fourth article in our series on “How to become a more data-driven organisation”, and we are going to be focusing on Data Platforms. It is at this point that most people start to dive deep into the technical aspects of Data Lakes vs Data Warehouses, but we want to bring us back up a level and ask

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?


101 Ways Limited
145 City Rd
United Kingdom


101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at