Making sense of Kanban (and some doubts)

As regular readers will know I’m a fan of the Kanban software development process championed by David Anderson. However it has to be said that the jury is still out on Kanban.

I’ve come to the conclusion that one of the dangers with Kanban is actually one of the reasons I like it. To properly implement Kanban you need to create a learning culture, there really needs to be a drive towards learning, change and improvement. Kanban raises the importance of understanding and creating a learning organization. Let me explain...

Depending on your point of view, Kanban might be:
a. The first second generation Agile development method
b. A collection of common heuristics
c. Dangerously unAgile
d. None of the above (a-c)
e. All of above (a-c)
f. Just another marketing term

Over at the Peripatetic Axiom blog Keith Braithwaite was voicing some doubts last week.

I had lunch with a Scrum trainer recently who commented “There’s nothing really new there, its stuff people have been recommending for a while”. I’ve said some similar myself - I find Kanban as described fits better with the way I’ve been coaching and running Agile teams for five years.

But then, isn’t that where Agile itself started? - people collecting heuristics and making sence out of them?

The Kanban community is not ignorant of some of the issues, Karl Scotland has a recent blog post about not mistaking Kanban for waterfall.

I have to say, some parts of Kanban worry me. For example, I’ve been telling teams for a while to think management by routine, the drum beats you have a planning meeting, a drum beats again and you do a demo, and so on, it all happens in a predictable fashion. So dropping iterations gives me the willies.

Keith’s point about batch size is well taken. Its all very well to talk about Minimally Marketable Features (MMF) but sometimes what the business thinks of as a MMF is a pretty large project in its own right. I remember one customer who’s idea of an MMF was “Works on Mac” which was a pretty major piece of work before we started to even consider the design limitations imposed, and the ones the engineers dreamt up.

Perhaps one of the reasons so many Kanban success stories involve maintenance teams (I have one too, I promise to publish it soon) is because bug fixes make nice MMFs.

However I don’t think this problem is confined to Kanban. All the Agile process suffer with a version of it. Scrum encourages teams to focus sprints on some meaningful goal, basically an MMF at the sprint level. The work breakdown, from business feature to developer tasks is a central plank of Blue-White-Red Agile.

I’m not doubting that teams can come up with small, non-bug fix, MMFs, I just think its difficult. Some technologies make it easier than others, e.g. its easy to come up with an MMF if you are coding a Ruby on Rails website and much harder if you are coding a C++ shrink-wrap legacy app.

Its also a sign of team maturity - both the development team and business team. The more experience the development team is the more likely they are to come up with a work breakdown were each item makes a meaningful contribution to the overall goal and delivers value to the business. It helps if the teams management is good at getting the team to look at options before deciding on what to do.

The business also needs to be experienced in both identifying small deliverable elements and they need to trust the development team. Rather than ask for the World (because they expect to be delivered Luxembourg) they need to be prepared to ask for Holland (and expect to get Holland).

There is something about Kanban that has troubled me for a while and I’ve not been able to put my finger on. Oddly its related to the fact that I’ve found teams pick it up more easily than Scrum based processes. And it goes back to Karl’s point about a superficial resemblance to waterfall.

I’ve finally worked it out: Kanban needs a culture of learning and improvement. Without a relentless drive to improve teams can fall back to glorified waterfall.

With Scrum, or XP, you know you are doing it because there is a lot of information on how to do it. If you start breaking a Scrum practice (without agreeing it in a retrospective) sooner or later someone will pull you up on it. Kanban removes that safety net.

At the moment the safety net doesn’t exist for Kanban. In five years it might be different because there will be more published on it. But in a way I hope not because the need to learn and improve is what I value in Kanban and its why it maps better to my model of development. A safety net might limit the learning and improvement.

The learning culture you need for Kanban is, perhaps, the result of it drawing more directly on Lean than some other Agile methods. In the absence of a safety net teams must think through problems and find their own solutions.

I think Kanban is here, it is here to stay and it will be found useful. But like other methods it won’t work in some places. With any Agile or Lean method there is an riding consideration:

There is no reason why one method is universally applicable.

Some times one method is more appropriate and sometimes another works better - horses for courses. Scrum is best in some work, XP elsewhere and Kanban in others. And all methods need to tailoring, sometimes you need to roll your own method.