cumulativehypotheses

There’s something about Kanban which worries me. Not kanban, which is a venerable technique used to great effect by manufacturing and service organization the world over for decades, but “Kanban” as applied to software development. More specifically, the examples of Kanban boards that I see worry me.

What you do now

David Anderson gives guidance on applying Kanban to software development something like this:

• Start with what you do now
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles, responsibilities & titles

Which is fine. What worries me is that the published examples of Kanban that I see so often seem to come from a place where what they do now is a linear, phased, one-shot process and the current process roles, responsibilities and titles are those of separate teams organized by technical specialism with handovers between them. Of course, there are lots of development organizations which do work that way.

But there are lots that do not. I’ve spent the last ten years and more as one of the large group of people promoting the idea that linear, phased processes with teams organized by technical specialism is a wasteful, high risk, slow and error prone way to develop software. And that a better alternative is an iterative, incremental, evolutionary processes with a single cross–functional team. And that this has been known for literally as long as I’ve been alive so it shouldn’t be controversial (although it still too often is).

Best case: Kanban will be picked up by those who are still doing linear, phased etc. etc. processes and will help them move away from that. A good thing. Worst case: the plethora of Kanban examples showing phases and technology teams undoes a lot of hard work by a lot of people by making linear, phased processes respectable again. After all, Kanban is the hot new thing! (And so clearly better).

Kanban boards

Take a look at the example boards that teams using Kanban have kindly published (note: I wish every one of those teams great success and am grateful that they have chosen to publish their results).  The overwhelming theme is columns read from left to right with a sequence of names like “Analysis”, “Design”, “Review”, “Code”, “Test”, “Deploy”. Do you see a problem with this?

Taken as a diagnostic instrument there is discussion of ideas like this: if lots of items queue up in and before the the “Test” column then the testers are overloaded and the developers should rally round to help with testing. Do you see a problem with this?

There is a way of talking about /[Kk]anban/ which strongly invites the inference that each work item must pass though every column on the board exactly once in order. This discussion of kanban boards as value stream maps, while very interesting in its own right, makes very explicit that in the view of its author the reason a work item might return from a later column to an earlier one is because it is “defective” or has been “rejected”. How is one to understand iterative development in which we plan to re-work perfectly acceptable, high quality work items with such language?

Not Manufacturing

Iterative development plans to rework items. Not because they are of low quality, not because they are defective, not because they are unacceptable, but because we choose to limit the scope of them earlier so that we can get to learn something about them sooner. This is a product development approach. Kanban is mainly a manufacturing technique. Software development resembles manufacturing to a degree of approximately 0.0 so it’s a bit of a puzzle why this manufacturing technique has become quite so popular with software developers. Added to which the software industry has a catastrophically bad track record at adopting management ideas from manufacturing in an appropriate way. We in IT are perennially confused about manufacturing, product development and engineering, three related but very different kinds of activity.

An Example

So, what if “what you do now” is iterative and incremental? What if you don’t have named specialist teams? And yet you would like to obtain some of the unarguable benefits of visualising your work and limiting work in progress. What would your kanban board look like?

Here’s one possibility (click for full-size):

Some colleagues were working on a problem and their environment lead to some very hard WIP limits: only two development workstations, only two test environments, only one deployment channel. But they are a cross-functional team, and they want to iteratively develop features. So, the column on the far left is a queue for new features and the column on the right holds things that are done (done recently, ancient history is in the space below). The circle in between is divided into three sectors, one for each of the three things that have WIP limits. Each sector has an inner and and outer part, to allow for two different kinds of activity: feature and integration. For example, both test environments might be in use but one for integration testing of several features and one for iterative testing of one particular feature.

The sectors of the circle are unordered. Any story can be placed in, and moved to, or back to, any other sector at any time any number of times, but respecting the WIP limit.

Feedback

Why can’t I find more examples like this?

I expect that some Kanban experts are going to see this and comment that they don’t mean for groups using Kanban to adopt linear, phased processes and specialized teams. And I’m sure that many of them don’t. But that’s what the examples pretty much universally show—and we know that people have a tendency to treat examples (intended to be illustrative) as if they were normative.

I’d really like to hear more stories of whole–team iterative, incremental kanban. Please point some out.