Kanban is not for the Idle or Newbies

For four of my six and a half Agile years I was solidly in the Scrum camp, Lean, in my opinion, was already part of Scrum and its influence made Scrum even better. I don't think that any Agile practice is for the work shy and there is a lot of personal courage needed to get any practice working well. Many people call Kanban an evolutionary rather than revolutionary process (my disagreement of this bland throw away statement will be in a later post), and I think this allows too many people keep the dinosaurs roaming the earth, if the mass extinction event has just happened then apart from the obvious sense of loss , at least you have an empty playing field to start from. Scrum at least with its slightly more prescriptive approach gives you somewhere to start.

About two years ago Kanban for software finally entered my Agile sphere. I initially relegated it to the ideal-for-support-teams division, and sneered at the new kid on the block. But time spent seeing Kanban in action and listening to the wise words of people like Gareth Evans (understanding the cost of delay was a revelation for me) and presentations including "Agile isn't the point, better is the point," by Michael Bromley, made me think about Kanban in a more positive light.

For most of you reading this the truth that neither Scrum, XP nor Kanban are for lazy is self evident and if you are lucky enough to have a coach around then these truths can be further explained by them. Having a coach is however not the norm for most companies or teams, it's often seen as an expensive luxury (until it all goes wrong). So if you don't have a coach and you want to start being "evolutionary rather than revolutionary", why were you not doing that before? Surely your practices, processes, etc must have d(evolved) over the last few years, no? Then what gives you the motivation to start?

You still need an event (e.g project about to go completely off the rails) or a rebel ("I have read a bit about this Agile stuff, I hate the way we work now, let's give it a go" to start Agile revolution and all the requisite energy you need to keep it going. But if this event is not there then I think that Kanban can be seen as the "easy out", especially for teams who see no issues with how they currently work or who dislike the initial "rigidity” imposed by Scrum or for those who desire an Agile veneer to appease the dictates of their managers.

Finally if it is an evolutionary approach you want and you have selected Kanban as your framework of choice for the right reasons i.e. to get the best out of your delivery, why do I always hear you have to drop Scrum, rather than let's keep what works and evolve the rest.

When I asked a Scrum team who were considering a move to Kanban why the individuals wanted to switch, the answers included magically solving systemic dysfunctions (which Kanban would not have), and my all time favourite, "...because, I don't like making commitments, and I don't like meeting deadlines". I struggled to contain the "WTF" scream at the back of my throat when this came out. Another team said it was so that they could have less meetings, Surely the point is , to understand the value (or lack of) the things they are losing before changing, so that change is done to make things better … . A great example of dropping things without thought is when we see "working software over comprehensive documentation" to mean no documents at all.

Time for a slight digression if you think that Scrum is too rigid a method, then one or more of the following is probably true:

• You are doing it wrong


• You are in your first IT job


• You work for a company where chaos was the former method of choice


• You think stage gates are for theatres, and a waterfall is something found at Niagara.

For the Kanban guys out there, yes I know that Kanban is not a method, rather a set of principles that allow you to create a great method (system, whatever), but when it's new to you and you are learning having a method really helps get you started.

We all hear the phrases, "Less is more," and, "Individuals and interactions over processes and tools," over and over, and for me I think they sum up nicely why Kanban is not for the motivationally challenged or inexperienced.

In 'Kanban and Scrum, making the most of both' by Henrik Kniberg & Mattias Skarin, they list the number of practices in common Agile methods:

• XP 13


• Scrum 9


• Kanban 3

The choice seems to be clear: if you don't want to be told what to do or how to do it, Kanban is for you, or is it really that clear?

What I think gets missed when you switch from any method without much thought and especially so if you want to switch from Scrum to Kanban, is that you need to balance the "individuals and interactions over processes and tools" equation. As you reduce or change the number of processes and tools you must increase or change the individual interactions or things you took for granted that helped may suddenly stop and rather than getting better you get worse.

I know some of you will argue that that's how you start with Kanban. First, map the work, then work through the dysfunctions as they appear. Yes all true,. But if this is your first step into Agile (without a coach) where do you start? at least with a retrospective once a sprint you have a baked in chance of getting it right (regardless of how well the first sprint goes).

By being LESS prescriptive you need MORE discipline to work at getting it right.

So if you want to deliver great software whilst enjoying your job, I recommend starting with Scrum it will help embed the basic,yet essential patterns of Agility you need. When you have grown up and can maintain Agile values and practices without an obvious framework, stay with Scrum or move to Kanban, Neither really matters, it's the ingrained values and practices and your personal drive for excellence makes it work in the end.

But if deadlines, commitment, continuous improvement, fixing problems, cross-functional teams, desirable products , and making the work actually work are not for you, and you think hard work is for suckers, then Kanban will not help.