Kanban and “On Hold” status

Time and again I see Kanban boards with a “On hold” status. The justification for maintaining this status defeats the purpose of Agile completely. The most common ones include:

1. QA suggests that the story cannot be “In QA” status if defects have been found and the developer is fixing the same. Keeping the story in QA will paint a wrong picture around the time to get the story tested.

2. Developers have a issue keeping the story “in development” since the work was completed and the issue identified may not a defect but a change in requirement or maybe a corner case.

The reasons mentioned above are examples of lacking collaboration and team ownership. These concerns can be attributed to how metrics (lead time and cycle time) are calculated in a Kanban setup. Individuals get into a defensive when assessing cycle time as they think it is reflective of their individual performance and not about the team as a whole.

Imagine this happening in a car assembly line, no car would ever make it to the exit or best case we might have a car with certain key features missing as there seems to be no way of reversing the assembly. The key to the success of Kanban is about maintaining a manageable flow and as teams hop between stories and tasks, it is bound to impact the throughput of the team.

To summarize, it is imperative that teams look at tasks and stories as team goals instead of individual performance indicators. If a story cannot move forward, it needs to be taken off the line. There is no pit stops or reverse gear.