Double the work in half the time

Long into the Scrum hype, Kanban may be the better way into Agile for many organizations

The urgency to substantially improve the performance of my development teams and a strong Lean background brought me to start experimenting with Kanban boards some years ago. Soon after, a more structured approach to agility and scrum followed by reading books, joining networks and coursing certifications. And, of course, by experimenting further.

I learnt for example that scrum is not new nor it is constrained to software. It first appeared in the development of hardware in Japan in the mid 80s as a natural evolution of Lean for knowledge work. I learnt too that scrum puts high hurdles to western organizations (team, culture, processes, structure…).

Kanban in an agile context organizes a team’s knowledge work along a visualized value stream using self-adopted policies. This is straightforward Lean Thinking (Hitozukuri) and, equally to its workshop version (Monozukuri) it is as well about empowerment, transparency and customer orientation. It builds as well pull-systems provided with a robust visual signal driving decisions and trigging action. And it does as well boost performance, quality and customer satisfaction.

Though the appealing title of this article is almost invariably linked to scrum. The superior suitability and performance of scrum against other setups is the dominant paradigm driving most agile transformations. And so was my belief until our results contradicted this hypothesis.

Many scrum initiatives, and so is my experience too, drift off sooner or later to ‘scrum, but…’ setups where teams basically ‘cherry-pick’ from the scrum tool box and operate a hybrid scheme that often resembles more a Kanban setup than does a scrum one. And this makes sense:

Scrum is the best setup to work on extremely complex, uncertain contexts, hands down. But it is also true that most organizations being pushed into scrum these days are not really putting a man on the moon. I live in Munich, Germany, where the scrum initiatives of large global non-software companies like BMW, Siemens or Allianz are visible to the local agile community. Why do these organizations, given they are not in a desperate situation in their own markets, embrace uncertain, painful large-scale revolutions instead of following a safer evolutionary path as ie. Kanban?

Yet some organizations succeed with their pilot projects using scrum to-the-book to fail afterwards when scaling it up. Kanban offers for this problem also a clear advantage, as it does not break up with the status quo right away and is better at infiltrating tayloristic structures with the Hitozukuri mindset. Scrum is rather revolutionary while Kanban is more evolutionary. And evolution may not be as appealing to short-term oriented decision-makers yet it may better fit the needs of their organizations.

Given, my point of view is the one of a practitioner, my experience is related solely to the hardware product development and my data points are just a dozen rather small-scale prototyping experiences with up to 30 people. Though the results are clear and consistent to others’: it is possible to double-the-work-in-half-the-time with Kanban. We indeed managed to cut cycle-times and development costs by almost 70%.

But easier than scrum does not mean easy at all. If you are striving a paradigm change expect resistance. Specially in organizations lacking agile, Lean mindsets or a sense of urgency.

I am personally still a fan of scrum, and we ourselves sporadically use it if we find ourselves in a complex, uncertain and time critical context, for example in a project early stage, a due diligence or a task force. Then we can switch from our factory mode (Kanban) into studio mode (scrum).

I acknowledge that the agile Academia may not like this probably oversimplified statement, though I see an evolutionary path in Lean first, then Agile; Kanban first, then Scrum.

Do you still want to go Agile? Kanban may be your best choice today. If at the end of that journey you still need to put-a-man-on-the-moon, then you will be much better prepared to cope with the challenge with the help of scrum.