The Kanban paradox

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.

Allan Kelly

Allan Kelly inspires, educates and advises teams and executives creating digital products. He helps businesses improve their use of Agile methods and serve their customers better
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newest Most Voted
Inline Feedbacks
View all comments
9 years ago

Hi Allan,

great article. May I ask to which distributions you refer to when you say standard distribution is not feasible for software work.

Thank you.

allan kelly
9 years ago

Sorry if I wasn’t clear, I meant the statistical “Standard Normal Statistical Distribution”

9 years ago

Hi Allan,

sorry I guess my question wasn’t clear. If I have not misinterpreted, in the article, you say the “normal distribution” is not suitable to statistically analyze kanban estimates.

Which are the other distributions which in your experience work best?

Thank you for the prompt reply.


allan kelly
9 years ago

Giuseppe, I’m not going to recommend any distribution! There is no short cut here, you need to analyze your own work. If I just said Poisson or Students distribution I’d be right in a few cases and wrong in many more. Not only do you need to identify the distribution but you also need to identify the parameters, e.g. standard deviation, any skew, etc. A related question is: what do you want to actually measure? The time is takes to do work will probably dominated by wait time, in which case what is the distribution of items in the backlog?… Read more »

9 years ago

Hi Allan,

thank you for your reply. I was interested in understanding if, in your experience, there was a recurrent pattern.

allan kelly
9 years ago

The pattern is: there isn’t a pattern

O well, maybe, the pattern is: people often assume standard normal distribution but the data often doesn’t follow that one.
Is I’ve remarked before, the Power Law shows up surprisingly often

Back to top button