Making the Complex Simple

I am almost jumping on the Kaban bandwagon, but not quite.  I don’t really like to be on any “bandwagon”, because when you are you seem to get stuck in a rut and don’t see the next improvement that is coming along.

What is Kanban?

Let me give you the simple simple and you can look up what other people have to say about the details.

The simple simple is this:  Kanban is a pull model where you are strictly controlling work in progress (WIP), by limiting the amount of work that can be in each phase of development.  It eliminates the needs for time boxing and committed sprints and replaces it with just in time priorities and time in queue instead of velocity.

Is it still agile? In my opinion yes and even more so.  Is it still Scrum? Only in some of the principles, but really it’s a different animal.

Here are some good links to people who have written about Kanban:

http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html

http://www.infoq.com/articles/hiranabe-lean-agile-kanban

http://leanandkanban.wordpress.com/

Excellent presentation here:

Why Kanban?

The reason I am starting to move in this direction and away from Scrum is mainly that very few people can actually get Scrum working.  Let me list out some of the most important issues I have been seeing:

1. Missing top level buy-in.  (Scrum pretty much requires this since you have to have the business commit to an iteration, and commit to what it means to be a chicken.)
2. Planning meetings take up time and provide no real value.  Estimation provides a value for planning releases and figuring out what work can get done, but itself does not actually provide a tangible value.
3. This is related to 1, but the business likes to be able to change priorities more frequently than 1 sprint.  (In general I have seen this to be true)

In some ways I am starting to wonder if Scrum is like training wheels.  It takes a large amount of dedication and attention to rules to make it work, and if you are missing the top level buy in, you can pretty much forget about it.

I am seeing Kanban as taking the good things that we learned doing Scrum and applying them in a less restrictive sense.  I am really liking the idea of focusing on controlling work in progress versus controlling time in which work is done.  There is a subtle difference here, but I think it is important.  I am recognizing there a many things in Scrum that we are doing that are not really adding bottom line value and most of these issues really rely on the time boxing aspect of Scrum.  If you take away the time box, but keep the idea of working on items in priority, limiting the number of items you are working on at a time, and the agile development methods which are used in Scrum you get pretty close to Kanban already.

Am I 100% sold on Kanban yet?  No, but neither was I on Scrum.  I really think the best approach may lie somewhere inbetween a Kanban + XP type of process.  See my post on pair programming.  Perhaps I’ll get a chance to try this out.  I already bring a large amount of XP to my Scrum, because XP has very good software construction practices.

So if you get a chance take a look at Kanban.  I really like what David Starr has been posting here and here about Agile not being Scrum.  It is very true.