We use a Kanban process with the following steps:
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.