The Kanban paradox

Allan KellyApril 28th, 2015Last Updated: April 28th, 2015

6 53 5 minutes read

I’m a big fan of David Anderson’s Kanban method, I always said my brand of “Agile” was heavily infused with Lean before David presented Kanban. In the same way that Kent Beck said Extreme Programming was about “turning the dials up to 10” David turned the Lean ideas behind Agile up to 10 and in the process dropped a lot of we (the Agile community) had come to regard as accepted wisdom – stuff like iterations and estimation techniques.

From my vantage point, sitting on the side of the Kanban community all these years, I’ve noticed two trends. Firstly Kanban as stripped itself down. I seem to recall someone saying the way to start Kanban was to “visualise your work in progress and take it from there.” Second, Kanban has relaxed its focus on software development. It now bills itself as a management method or even a “change management” method. The net result is that even as Kanban itself has slimmed its applicability has broadened.

Stripping away non-essential elements makes Kanban simpler to communicate and understand but at the same time says less about what you should actually do. Kanban is getting closer and closer to its Lean roots. I’ve long considered Lean to be more of a meta-method than a method, that is to say: Lean doesn’t tell you how to work (unlike say Scrum) but it tells you how to think about how you work. I sometimes say “Scrum and XP tell you what to do at 9.30am tomorrow morning while Lean tells you how to think about what you will do at 9.30 tomorrow morning.”

I have no disagreement with the way Kanban is going, I still like it as an approach and I think the people who are changing it are doing the right thing. (The opportunist side of me might even reason that as Kanban distances itself from software development it leaves a gap in the market that Xanpan is ideally placed to exploit, but that would be incredibly cynical of me and risks all my credibility!)

(I should mention that while I’ve been invited to a couple of Kanban “Leadership Summits” I’ve never attended, a combination of my natural Groucho Marx tendency and family commitments means I’ve opted not to contibute.)

But… and here is the meat of this blog post…. I think the way Kanban is going creates a paradox.

As Kanban gets briefer and smaller then implementing Kanban requires more expert knowledge.

You can put up a Kanban board and track your flow and work in progress. You can set WIP limits. But if you don’t know how to read the board you don’t know how to act on it. And if you do know how to read the board acting on it isn’t always a rationale engineering discussion: acting on the board often involves office politics.

For example, I once helped a company create a Kanban board with many (too many) steps and (too) many queues. After a few weeks the problems were obvious. But instead of acting to remove the problems the board was used in evidence to apportion blame.

Kanban can generate many metrics: cycle time, lead time, utilisation, etc. etc. But if you don’t know what these metrics mean they are pointless. And even if you do know what they mean knowing how to act on them is another matter.

For example, Kanban relies on queueing theory, some of the things queuing theory suggest you do is counter-intuitive like reducing work in progress, and therefore worker utilisation to speed throughput.

Sure you can learn queueing theory, you can read the books, you can learn about metrics, you can reason about your own board but these things take time. Even then I doubt if any book, course or programme can give you the knowledge and understanding that comes form experience, from seeing it done before and from seeing multiple implementations.

In at full-throttle Kanban teams dispense with iterations and estimation. They substitute statistical analysis for estimation – and I believe that is a “better” approach but that also requires a good understanding of statistics. Most people are pushed to remember one distribution and when they do its standard-distribution but software work is unlikely to follow standard distribution so unless you know there are others you will come unstuck.

Then take value, Kanban – like Lean – aims to enhance value. But how do you define value? What is valuable to your organization? Is value quantity? What do you do when you can’t put a dollar amount on value? Someone needs to understand value and how to work with it.

And then there is software development itself. Implementing Kanban in a software development environment has many more issues. You need an understanding of quality, an understanding of software products (features or solutions) and more – even before you get to the technical stuff!

To my mind this makes Kanban difficult. It requires expert knowledge. Sure you can learn this stuff – book your Kanban course now! – but it takes time. I started studying software development properly in the reading room of Liverpool Library nearly 30 years ago and I still don’t know everything.

And its not only my study of software development that I find essential in helping teams with Kanban. Years spent studying economics, years spent reading management books and yes, time spent at business school earning a degree so many in our profession (not without reason) rubbish but which equipped me with understanding I use regularly. When I help teams with Kanban I draw on all these sources.

Sure this is good news for me, it makes work for Agile/Kanban Consultants (sorry, Coaches) but it also makes harder for non-experts to practise. And most people trying to do Kanban are experts in software technologies not process and flow.

So here is the Kanban paradox again: as Kanban gets briefer and simpler practicing Kanban requires more expert knowledge.

The beauty of Scrum and XP was that you could practice them quite well without expert knowledge. You may never be the greatest team on earth but frankly most businesses don’t care about that, they want something (anything!) better than what went before.

You don’t need to be great at Scrum/XP to get benefit: stick to a two week iteration cycle (most of the time), get a clear steer on work prioritisation once every two weeks, hold some kind of regular meeting, thats about it. Sure its good if the stand-ups a short, if you don’t work from a requirements document, if you do retrospectives, and especially if you do some of the technical practices. But, just doing the basics it is democratic and everyone can understand it.

Scrum and XP made the development process accessible to those who practice it, they can reason about it. Kanban done well is far far better, but Kanban done badly, without understanding? I suspect it is dangerous.

I’m not sure Kanban is the same, I think understanding Kanban requires a lot more understanding, therefore Kanban is not democratic, it is more of a management method, more of an experts approach. And this its a paradox.

And what of Xanpan?

Does my Xanpan approach suffer the same problem?

Well maybe, but I am the worst person to ask, I’m biased. Xanpan is “the way Allan Kelly does it” – well, it was, a few others are now trying it now. Maybe Xanpan does, after all Xanpan tries to have its cake and eat is, I give detailed description of how to do Xanpan but at the same time say “make your own method.” I sincerely hope I can keep Xanpan democratic.

Maybe Xanpan is just a training version of Kanban. Maybe Xanpan is a cut down Kanban, maybe its a neutered Kanban. Maybe when you’ve practiced Xanpan for a bit you can mutate so its more Kanban. Anyway, who cares what you call it.

Reference:

The Kanban paradox from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog.

The Kanban paradox

Thank you!

Allan Kelly

Thank you!

Thank you!

Related Articles

Thank you!