Kanban Is For Attacking Flow Problems, Not For Dropping Iterations

I’d like to chime in on the discussion started by Abby Fichtner, a.k.a. HackerChick in Kanban is the New Scrum and continued by many people in comments and blog posts (such as this one).

I don’t find anything to object to in the article, but I feel that a stronger argument can be made for Kanban than the supposed freedom from iterations.

Time-boxes Aren’t Scrum’s Impediments

The freedom-from-iterations argument sounds like treating a symptom. The iteration length should not be an obstacle to more frequent releases if those are important to users or customers. Demos at the end of a time-box (say, on Business Day 10 of a two-week sprint) are not the right time (too late) for a product owner to become aware of a completed feature and they are not for sort of acceptance tests to decide what’s shippable and what’s not. Suppose a feature is ready by Day 6, the product owner is aware and approves it. It’s the right feature, built right and it’s shippable. If it’s really important to ship it to the users the same day, the ops people can do it. They are part of the team, sit nearby and not in a different building, right? When Scrum is without “buts” (“we do Scrumbut, our PO is never around”), time-boxing shouldn’t hold it back. Scrum has a built-in retrospective process to get rid of “buts” holding teams back.

“We are constrained by Scrum’s time-boxed iterations, so we need to try the iteration-less Kanban process” is a weak argument. Kanban is a meta-method for improving other processes and its main strength is that it can bring many teams closer to their problems and understanding the science of their operations.

Flow Problems

This is a class of problems faced by many software organizations. Take a feature that your paying customer wants, don’t take your eyes off it, and follow it from concept to cash (or from hypothesis to happiness, if you will). Now consider all your features. That’s your flow. That’s how software work behaves. (Some people don’t see it that way. They prefer to look at the org chart. But that doesn’t change the reality.)

Today’s reality for many in the software industry is that our work doesn’t flow very well. There are pools, back currents and even dams (often built by us because of our lack of understanding of flow). What we need to do is to understand how work flows in our context, study the flow and make improvements. This is exactly where the Kanban method comes in with its “improve collaboratively using models and the scientific method.”

What models and methods, you may ask. A short, incomplete answer is: Goldratt (qualitative), Reinertsen (quantitative) and Mary and Tom Poppendiecks’ lean principles as super-useful approximations. Consider the Theory of Constraints. When Goldratt’s Jonah asks Alex about quality control in his plant, he thinks about exploiting a bottleneck by inspecting parts before the NCX-10 gets them. That’s “building quality in.” Specification by example is an attempt to apply similar logic to software development. Check out Donald Reinertsen’s Principles of Product Development Flow. You can find many things in this book, among them charts quantifying what we approximate by using the principle of “deferring commitment.”

Distance Between Teams and Their Flow Problems

Consider one team. They didn’t do XP 10 years ago. They’re mainstream, maybe late adopters. You may have met a team like this one recently. They seem to be doing this:

If you were an XP pioneer or an early Agile adopter, there is something important in this picture that is not actually shown in it: the customer, standing pretty close to it on both sides. Your XP or Scrum framework may not say much about the economics of your product development flow, but the way you work and retrospect are aligned with the desired economic results reasonably well. This is not the case for the mainstream or late-adopting team in our example. But let’s zoom out and see what they’re actually doing:

This is a fairly typical case: a two-week iteration cycle, a quarterly release cadence, and the total cycle time through the whole value stream of more than one year. What is needed here is a dose of lean thinking. Kanban can deliver it and help this team get underway on their lean journey, understanding and studying their flow and finding solutions to their problems. And they may even decide to keep their iterations, or as we call them in Kanban, input, release, and retrospective cadences.

I totally agree that we shouldn’t throw the Scrum baby out with the bathwater. Dropping iterations is not a good reason to do so.

This entry was posted in hands-on. Bookmark the permalink.

7 Responses to Kanban Is For Attacking Flow Problems, Not For Dropping Iterations

  1. Pingback: Getting from A to B with Kanban | MarkjOwen's Blog

  2. Agile Scout says:

    I’m tracking your argument. I would think it depends on the situation…
    Sometimes you should and (can) drop iterations at no loss of productivity

  3. azheglov says:

    Hi Agile Scout,

    Iterations can be kept or dropped, of course, but that is not the point of this post. When people say they switch to Kanban to get “freedom” from iterations, they often miss a lot of what Kanban is for.

  4. Spot on with this write-up, I honestly feel this website needs a lot more attention. I’ll probably be returning to read more, thanks for the info!

    • azheglov says:

      Hi Lean to shed plans,

      Kanban for knowledge work is different from Kanban for manufacturing physical products in several ways. I am mostly interested in the former. I’ve noticed that your business designs and sells shed plans rather than building physical sheds, so I should be able to help you.

  5. Pingback: The Best of 2012 | Learning Agile and Lean

  6. Romeijn says:

    Hi there,
    Great article, thank you!
    I agree about the total difference between a stock management Kanban and a knowledge based work management with Kanban. They just cannot be compared. But, as far as problems and iterations go, I think we should keep in mind, that any Kanban system requires constant looking after, including making sure that the process resembles the actual need at all times. And if the need is working in iterations, this can definitely be done with Kanban. I recently saw an article from a Kanban Tool app blog, that stated the same (http://kanbantool.com/blog/problems-with-kanban). I agree with it, all(!) it takes to make Kanban work is ..working on the system. The Kanban idea is “continuous improvement”, after all.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s