When I started my Kanban adventure some time ago, I heard The Sentence: “Don’t move your items backwards on the board”. The thoughts I had at that moment were pretty similar to the doubts I read about recently when preparing to write this article: why is it not advised to do so? What if we have a rework required? What if an item does need additional analysis? Don’t transport your car The answer, I received, came from kanban manufacturing and satisfied me for a moment. Let’s imagine a car production line. If a defect was detected at the stage of installing the door but it was related to the earlier phase, the car is not moved backwards to the source of error, but rather kept in place. Instead people swarm around it and try to fix the problem. The same way we keep the item on the board in the place where the defect occurred, mark it as blocked, probably create a new item (defect) and track it until solved – usually as an expedite piece of work. That made sense, but still addressed the problem only partially. The game changer What completely changed my perspective was Kanban System Design training with Paul Klipp (kudos to the trainer), where I had a chance to really experience the Kanban origins. Paul put our attention to three aspects of moving cards backwards: 1/ you lose the track of your metrics 2/ you mess up the flow 3/ you violate the logic, because kanban board does not simply mean dividing your process into phases – “you map the series, or sequence, of dominant steps to discover new knowledge.”(1) The last sentence is the key to understanding why we should have never moved items backwards on the kanban board. But let’s take a look at all of them. Keep an eye on the metrics Metrics are not tracked for budget holders or boring accountants satisfaction only. Because they are based on data, the metrics are a very solid anchor in understanding what happens in and with your process. They help not only analyse the past, but also anticipate future patterns of your work items, flow and even customers’ behaviour. They make you predictable. Now… what happens to the basic metrics if you move the item backwards? We can show it the easiest way on Cumulative Flow Diagram. If we use the classic definition of CFD as “an area graph that depicts the quantity of work in a given state, showing arrivals, time in queue, quantity in queue, and departure” (2), we can clearly see that moving item back will:
disturb the quantity of work in a given state – cause one item will be counted twice (or more) in one or more states;
affect the time and quantity in queue – of a given (moved back) item but also the other items in the flow;
violate the arrivals – if an item returns to the beginning of a process.
CFD will make no sense anymore – until we make it a shallow metric to track input vs. output (and praying that our item will not move back to the “To do” list).
Don’t ruin your flow Moving items back and forth mishandles your process. If you do it frequently – you lose the track of your work. The first red flag will be metrics, which don’t work anymore. But then, very soon, your board will not tell you anything except for the fact that your work is in progress. The place where you visualize should be a single source of truth. A glance at your board should tell you immediately what happens. If items fly from right to left and back – how can you know, what happened to them, when you didn’t watch? How would you design your policies? Would you put there a limit of movements per week? When work items change their position frequently and randomly, how would you know, which phase did they hit already? Remember about discovery journey If you stop treating the board as a wall divided into columns that represent your work or people and start thinking of it as a knowledge discovery process, the perspective changes dramatically. You don’t want to move items backwards, cause – following the learning logic – that would mean that you have “un-learnt” something. On the other hand you don’t want to manipulate or hide reality by keeping in development an item that really belongs to the analysis part. There are possible options for leaving this state:
“Remember, the columns on a board (…) are an abstraction of the life cycle of learning that results in a solution to an end user need. And all work can happen in all columns. The current column is just the dominant theme. It’s fine, for example, to have a development and test column and have testers working on some preliminary testing tasks while a ticket is in ‘dev’ and developers working on fixing bugs while it’s in ‘test’.”(3)
Discuss with the team your current process. If you notice that you all feel a strong temptation to start this small movement exercise – react. Gather and think – why do you want to do this in the first place? Why did you think it’s the best idea that would reflect reality properly? Solution may be simple redesigning your flow, as the board is a living organism. (4)
What’s next? The discussion about this topic has been more than 10 years already. One single conclusion was not written down in Kanban annals and passed to the future generations. There is still a lot of space for challenging our brains, so… let’s discuss! (1) https://www.linkedin.com/pulse/statik-systems-thinking-approach-implementing-kanban-david-anderson/ (2) https://en.wikipedia.org/wiki/Cumulative_flow_diagram (3) by Paul Klipp at KanbanPoland slack channel (4) This is what happened to my team recently. We had 3 columns (analysis, design, development) where tasks tend to move back and forth. Short retro with the team helped to identify that our workflow required redesign. We removed ‘design’ phase and added ‘review’ after ‘development’ (which was the check with Business before testing). Problem of travelling cards was solved.