I was throwing some shapes on Twitter recently about some concerns I have with the current Kanban craze. Unfortunately I think the cursed 140 character limit meant my points got misinterpreted and may have lead people to think I’m anti-Kanban which is not the case in fact it’s quite the opposite. I’ve been using Kanban boards for over a year and half and jointly ran a presentation at XPDay2008 on evolving from Scrum to Lean which focused heavily on the use of Kanban boards.

The thing that’s making me itchy is how Kanban has somehow been elevated into a methodology unto itself. We don’t have “Scrum and Sprint” conferences or XPandPairProgrammingDay so why do we have Lean Kanban Conference Miami or the UK Lean and Kanban Conference? Also, pretty much everywhere you see someone talking about Lean software development the title of the blog or presentation also includes Kanban in the same breath? More than that I see a lot of discussion around Kanban in blog posts and Twitter but very little on Lean or the Lean Software Development principles.

I’m sure proponents of Kanban will say no one is suggesting Kanban is a methodology and I would agree I’ve not seen anyone say it is. The problem is interpretation. People have a habit of focusing on rules and methodologies because they’re a lot more easy to tackle than the problems they we’re created to solve. Scrum has been enormously successful (if you consider wide adoption a measure of success) but very few teams are doing it well as James Shore has been writing eloquently about recently because it does not force you address the real issues. The beauty of Lean software development is it is just a set of principles. It intentionally avoids prescribing how to do something. Obviously this causes problems as most people don’t want to get involved in the difficult stuff they just want to be told how to do it. Consider this reply I received on Twitter:

erwilke @robbowley “I think we’re trying to avoid kanban being seen as a stand-alone methodology, but people don’t “get” it as a set of tools”.

Maybe there’s a good reason why people don’t get it – because it you need to understand where it’s coming from. Focusing on Kanban and ignoring all the rest however, that’s easy!

Elevating Kanban to the prominent position it is now in makes me feel like history is going to repeat itself. I prophesied this some months back. It has been the most popular post on my blog by a long way.

If you’re getting into Kanban, be warned. Kanban is just a tool and in my opinion no more important than say, pair programming, unit testing or domain driven development. It is certainly a lot less important than the white elephant in the room which very few people seem to be addressing which is building the right thing in the first place. As Peter Drucker famously said: “There is nothing so useless as doing efficiently that which should not be done at all”.

Kanban is a small part of something much, much bigger, see the whole.

 

*Edit* Some responses to this article:

Is Kanban Just a Tool? – David Anderson

It is Not What It is that Really Matters - Israel Gat

Kanban: It’s a Tool, and There’s No Such Thing as “Just” a Tool – Project Management Revolutionary

As a general rule of thumb you should depend in the direction of stability (The Stable Dependencies Principle (SDP)). A package should only depend upon packages that are more stable than it is. If something is changing a lot it we should not depend on it. If it isn’t then we can comfortably reference it as a versioned package/assembly.

“But I want to add something to the GeneralFunctions/Domain/Utilities project”
Why? If you are the only one using it then there is no reason for it to be there.

“But someone else may want to use it in the future”
The possibility that someone may is not a good enough reason to put it there. Follow the principle of You Aren’t Gonna Need It (YAGNI). 

“But what if I need to change something that already exists?”
“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” – The Open Closed Principle