How to deal with roundtrips in Kanban

Question

We use a Kanban process with the following steps:

• (backlog)
• specification
• implementation
• review
• (completed)

The specification, implementation and review steps are divided in in progress and done phases.

The implementation step is done when the implementer thinks that the code matches our quality standards. The review step is done when a second person thinks that the code matches our quality standards.

Sometimes, during the implementation step it turns out that some part of the problem wasn’t considered during the specification step. In this case the work item goes back to specification in progress.

Quite often (often several times per work item) it happens that the reviewer isn’t quite happy with the code.¹ In this case the work item goes back to implementation in progress.

If a work item goes only forward, we can use the standard Kanban workflow: pulling work items into the next step while observing the WIP limits.

If a work item goes backwards, there are a few problems.

When pushing the work item to an earlier step, it could be the case that the earlier step is already full (i.e. it has at least as many items as the WIP limit). What should we do in this case?

When the implementer has incorporated the review feedback, it’s unclear what to do with the work item. Currently, it’s assigned back to the reviewer and pushed again to the review step.²

In both cases we push instead of pull, which seems like working against the Kanban principles. Is there a better solution? Should the steps be re-arranged to make the flow go forward more often? If yes, how could that be done?

---

¹ A thorough review is an important part of our process. We have some developers who are not yet very experienced programmers. Also we want to avoid that specific knowledge is concentrated on few developers, so people are sometimes assigned to tasks which they are not very familiar with (but then the reviewer should be experienced in that area — sometimes we pair, but our team is partly separated spatially and temporally). It turned out the the implement-review-implement cycles are a very effective way to spread knowledge across the team.

² In some cases we know that the previous reviewer is unavailable for a longer time. In this case we unassign the work item and put it to implementation done. But this is an exception.

Answer 1

Two things stand out to me.

In the long-term, the Lean-Agile methods are centered around building quality into the process from the beginning (and at every stage) and Kanban is centered around continuous, incremental, and evolutionary changes. It seems like your process has issues if sending work back is a common occurrence. The review activities that you have in place are not effective and should be evaluated and changed to minimize the work that needs to be sent back to a previous step.

In the shorter term, you need a way to manage this work. My initial recommendation would be to add an "expedite" row that ignores WIP limits. Work that is sent back would end up here and be the most important work to progress. The rationale here is that it was the most important work, therefore it was selected for development first, so unless priorities have changed, it continues to be the most important work to get to done. Things in this row of work will stand out and can enable the team to identify things that get sent back and work on understanding why they are sent back and to make changes to the process to prevent it in the future (see the long-term solution).

Ultimately, though, the team needs to be empowered to understand the problem and develop the solutions. But if the team was stumped, the two above is what I would initially propose as next steps.

Answer 2

First impression: you are too fixated on the process and to violate some process principles when the whole Agile idea is people over processes. If the WIP limit proves repeatedly to "overflow" increase it or reduce the amount of stuff you put in each stage in the first place, i.e. add buffers. If it does overflow, pushing something just back forward seems like the wrong idea, something needs to be thrown out backwards, i.e. some item on which work didn't start yet will be done later.

You can also allow or encourage reviewers to implement the changes they want to see and then have a second review step where the original author gets to see those changes so he can learn from them (and potentially dispute them). This will increase the review time but you can plan that in.