This question comes up quite a lot – particularly with those who are new to Kanban. I was reminded of this by Alexei Zheglov recently in one of his tweets and I recall some recent conversations on this topic. The way you handle this kind of situation reflects on the maturity of your Kanban implementation. On lower maturity systems, you will see cards moving backwards quite a lot. However, with more mature implementations this should rarely occur, if at all.
It comes down to whether your board is representing a workflow with handoffs and backflow for problems or if you’re modelling the knowledge discovery process. If you’re modelling you’re basic process or purely specialities of work you will see things move back and forth as people create those handoffs. In this kind of board you’re describing the specialities – so although it may be a useful transition point you run the risk of hardening those distinctions, rather than focusing on the overall flow. You may use it briefly as a transition point – to demonstrate the problems, but please use it as a catalyst for further action and improvement rather than sticking with it otherwise you’ll continue to face problems.
When we teach Kanban, we recommend that your board visualises the knowledge discovery process. What that means is on the left we have little knowledge of the item and as it moves through the flow we gather more knowledge and information about the problem we’re facing, its implementation / rollout to customers. It also means that the titles on the board describe the predominant knowledge discovery activity – it doesn’t exclude other types of activities. Take this simple board:
Just because the title says analysis, it doesn’t mean no development or testing can occur. For example perhaps as part of the analysis you might need a developer to do a quick spike to see if something will work in a particular way. Additionally, the development column doesn’t mean no analysis can occur – for example the developer may analyse the various data scenarios in order to create the appropriate set of unit tests to handle the scenarios. Testing doesn’t mean development activities can’t occur – maybe you’re developing the automated test suite here or fixing bugs.
This brings me to my next point – how to handle these situations. The testing scenario where we find a bug is one that is quite common. In that case we often leave the original card in testing and create a new card for the bug which also traverses the flow. Once the bug reaches testing and is verified as fixed the original card can continue on its way. Another way to deal with this is using blocking stickies. I discussed this in one of my earlier posts on blockers.
If you don’t treat this as a knowledge discovery process and instead move cards back and forth in the flow you’ll hit a number of issues that will make it very difficult – if not impossible, to manage flow effectively:
- Your metrics are going to be out – if you look at your CFD charts they’ll do all sorts of strange things such as lines going down (that’s usually a sign you messed something up).
- You’ll break your WiP limits – these are there to help you manage the flow based on capacity. Items moving back and forth will constantly be breaking WiP limits and you’ll find it very difficult to manage flow as you have no control over the movement back and forth
Furthermore, if you’re modelling the knowledge discovery process it makes no sense to move something backwards. Cards upstream denote that you have less knowledge about them. The trigger for moving something backwards is usually that you’ve discovered something about it – some kind of problem. It makes no sense to move it to a place on the board which denotes you have less knowledge – quite the opposite the discovery shows that you now have more knowledge than you did yesterday about this ticket so it should not move backwards. You may be better off examining your policies to make sure items flow cleanly without the backflow.
Moving cards backwards on a kanban board doesn’t make sense unless you’re using it as a catalyst to bring about improvement. There are better alternatives available that take into consideration the whole of the system. You’re better off going to a place of understanding the knowledge discovery process so that you can manage the flow effectively.