Scrum doesn’t work for us; should we try Kanban?

Two and a half years ago I published a blog entry entitled “10 things to know about Kanban software development” which has consistently been the most read piece on this blog. At first I thought “Well there isn’t much published on Kanban relative to Scrum” but then David Anderson published Kanban and that wasn’t true any more.

Others have written about Kanban too over the last two years but still there is a hunger out there, people want to know about Kanban. I see this too when I deliver my Agile training courses, the moment Kanban is mentioned people want to know more.

Although Kanban is conceptually simple you really need a day or two to discuss it properly. Still, I regularly find myself squeezing an hour, or just 10 minutes, into a Agile training course because the audience want it. I say “I really need a day” but I can’t avoid it – they are paying for my time so they get what they want.

One of the reasons people give for buying an Agile (Scrum/XP style) course and wanting Kanban is, they say, “we don’t think Scrum will work for us so we might try Kanban.” Then when I return to coach teams I’ve given training to I’m regularly asked “Scrum doesn’t seem to work for us, should we try Kanban?”. I reserve judgement and enquire before I give my advice, and what I find is….

They haven’t really tried Scrum(XP).

Or rather, they have tried a Scrum(XP) type approach and they hit problems. Despite my telling them this would happen they think its Scrum. The thing is, Scrum fixes some problems “out of the box” but it doesn’t fix them all, in fact it exposes old problems and highlights difficulties which you then have to fix. Thats the way it works, that is the way it is meant to work.

Let me repeat that: Scrum and XP do, in and of themselves, right out of the box fix a lot of problems software development teams typically have. But Scrum and XP do not (despite what some people will tell you) fix all problems right off: you have to continue the work and fix them yourself. Sometimes Scrum, as officially described, will just not work, you have to modify it to your environment.

What worries me when teams say “Scrum doesn’t work, we want to try Kanban” is: if a team can’t make Scrum(XP) work because they cannot fix the impediments or make their own modifications then Kanban will never work. In fact, Kanban will probably be dead on arrival.

Some years ago Karl Scotland said “there is a subtle difference between kanban and typical agile processes such as Scrum. Scrum focuses on being agile which may (and should) lead to improving. Kanban focuses on improving, which may lead to being agile. However, being agile itself is not important – it just happens to be the best way we (or at least I) know at the moment.”

Thus: If you want to try Kanban because Scrum doesn’t seem to work for you then the chances are Kanban is only going to be a diversion. Set about fixing your problems.

Now there are reasons why Scrum doesn’t work, and there are reasons you should try Kanban, that should be a separate blog. One common case is because the development team has some support or maintenance responsibilities. In these cases my XP-Kanban hybrid Xanpan works quite well.

(I keep taking about Xanpan and a few people have asked me to write about it but a) I don’t think the world needs yet another Agile method, and b) until recently I wasn’t convinced there was enough difference between Xanpan and either Kanban or Scrum/XP to make it worth while. On the second point I’m changing my mind. If you want to know more about Xanpan let me know.)

Back to topic, although a team might not need to move from Scrum/XP to Kanban or Xanpan there might still be advantages to doing so. However moving because you can’t overcome your own obstacles is not a good reason for changing. If you can’t make Scrum work because you can’t fix your own issues switching to Kanban is not the answer.