Lean or Kanban or Agile

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 skills, 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.