mostly professional blather

Iterative, Incremental Kanban

with 8 comments

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):

Iterative, Incremental kanban board

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.


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.


Written by keithb

September 16, 2011 at 11:59 am

Posted in kanban

Tagged with , ,

8 Responses

Subscribe to comments with RSS.

  1. […] Iterative, Incremental Kanban « cumulativehypotheses […]

  2. Interesting example. Energized Work have an example of a non-linear whole-team Kanban board: There’s also Arlo Belshee’s Detective’s Board idea

    Benjamin Mitchell (@benjaminm)

    September 16, 2011 at 1:44 pm

  3. Interesting visualization of work, both in the post and from Benjamin’s comment. I’ve also another backlog board (link, image near bottom of ) from Energized Work.

    However, I read the usual linear-looking Kanban boards as work flowing through phases, not necessarily between specialists.

    And so, regarding team focus, it’s not about handoffs. F.ex. with a testing policy saying work items have to be tested by someone other than the one doing the work item, it’s doesn’t have to be about handing off to a tester.

    And regarding iterative development, the iterations on features can happen before the kanban board, f.ex. with tools like Benjamin and I have noticed in use at Energized Work.

    Ingvald Skaug (@ingvald)

    September 18, 2011 at 2:03 pm

    • Well, can we not call them “phases”? If the work does not pass between specialists then where do the limits in the “testing phase” come from? Where do the limits in any other “phase” come from, if not from too few humans with that skill?

      Can you expand on your comment that

      the iterations on features can happen before the kanban board

      this I do not understand.


      September 19, 2011 at 5:11 pm

  4. […] When designing a kanban system’s visualisation, thinking about how the TIPs are used can help come up with solutions which are creative and contextually appropriate, and help avoid falling into the trap of copying known and sometimes simplistic examples, as highlighted by Keith Braithwaite. […]

  5. This has been bothering me for sometime, I’m glad that you’ve said it as it is and challenged the de facto approach. I think it’s an interesting thought experiment to consider what a Kanban board would look like for a team of true T-shaped developers, would they even bother having multiple columns or simply have one labelled WIP?


    January 2, 2014 at 10:59 pm

    • Even though this article is quite old it’s still very relevant (have really we not moved on in more than two years?) and I find myself iterating on the idea. A question came to mind yesterday, why do the majority of Kanban boards have the customer on the left (the priority queue / backlog)? I thought this was a “pull” system, the pull starts at the customer. This might seem trivial but it speaks to mindsets and gets people off on the wrong foot if we start with customers pushing work onto the team (because that’s the reality even though we tell ourselves we are pulling in requirements as capacity allows). Instead, if we think about customers having needs that we are going to service and that we don’t start on work until they “pull” from the system, then the backlog won’t be a great big laundry list of features but, as Dan North has written, a set of hypotheses which we run as experiments to learn more about their needs and evolve better solutions.


      January 5, 2014 at 4:20 am

      • In most cases that I see, the customer arrives at the beginning of an engagement with a great big laundry list of features in mind. Ones that they are sure they want. As a result they are strongly resistant to the idea of needing to step back and begin a process of learning what they need—however necessary that may be.

        But then, I mostly see clients who think in terms of projects, their funding and governance policies require it, and projects need to have a goal and they need some sort of business case, and all of that comes before anyone being in a position to pull anything from anyone. I stand by my observation of long ago that /[kK]anban/ doesn’t have much to say about projects. And that’s confirmed by all the alleged “kanban” boards around with no WIP limits on them. They may be very good and useful visualisations of the state of the project, but they aren’t doing anything to help anyone manage the flow time of work items in the team, or optimise dwell time or whatever. And in a genuine project scenario, I’m not sure that’s a problem.


        January 5, 2014 at 8:50 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: