0

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.1 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.2

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?


1 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.

2 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.

  • What is your specific question? "Is there a better solution" has no answer unless you can tell us what you expect to be better, and I don't think you've adequately articulated the actual problem you're having. – Robert Harvey Jun 19 '19 at 15:40
  • @RobertHarvey Thank you for pointing this out. Currently it feels like we’re working against the Kanban principles. I’ve changed the question to emphasize this more. Do you think that this makes it easier to answer? – Manuel Jacob Jun 19 '19 at 15:45
  • Is your WIP limit for each column include "in progress" and "done"? Or is it only for "in progress" work? – Thomas Owens Jun 19 '19 at 16:01
  • @ThomasOwens The WIP limits include both in progress and done, as suggested in the book "Agile Project Management with Kanban". Are there good reasons to count only the in progress work? – Manuel Jacob Jun 19 '19 at 16:05
  • @ManuelJacob No - in fact, I don't think it's right to separate them. It just wasn't clear from the question. – Thomas Owens Jun 19 '19 at 16:10
3

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.

  • 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 spacially and temporally). It turned out the the implement-review-implement cycles are a very effective way to spread knowledge across the team. – Manuel Jacob Jun 19 '19 at 16:42
  • @ManuelJacob Without knowing more about your process (and there are probably several other good, specific questions in there), I'd look at how you are pairing and reviewing. The idea with Kanban is that work flows through the system without going backwards - this is something that you should be looking at improving. Otherwise, yes, you're going to be fighting a lot of traditional Kanban principles and practices. – Thomas Owens Jun 19 '19 at 16:46
  • I’ve amended the question based on ideas I had while reading your answer / comment. It seems like there are two separated issues: what to do with things which occasionally need to go back to an earlier step, and what to do with things where cycles are an important part of the process. – Manuel Jacob Jun 19 '19 at 16:58
  • @ManuelJacob Kanban is explicitly designed for flow. Cycles are not flow. You aren't going to find Kanban approaches for dealing with cycles, since they should be exceptions and not the rule. You either need to forget Kanban and find your own path or solve the underlying problems that are preventing flow. – Thomas Owens Jun 19 '19 at 17:01
  • One idea would be to put the implementation and review steps into one. This eliminates the main source of cycles, making the flow go forward more often. Unfortunately, it decreases visibility of whether code is in a reviewable state or not. The specify-implement-specify cycles are much rarer. Putting them into one step seems overkill. Over time we could improve our specification step to decrease the likelihood of these cycles further. – Manuel Jacob Jun 19 '19 at 17:14
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.