So a ticket has failed QA, and the fail’s a bad one, it needs to be fixed for sure. A dev (probably the one who coded it in the first place) needs to change the code, and then it needs re-reviewing, re-testing, and hopefully will pass second time round.

This is one of the most common situations in a software development team (unless you’re the one team in the world who manages, without cheating, to produce no bugs at all). How should these steps in the life of this ticket be represented on an Agile Board?

There are two basic patterns that can be used. We’ll start with the most commonly used pattern, the ‘Looping Method’, which can be summarised as ‘move the ticket left, back to the In Dev column, for the code amends, and then to the right through Code Review, Ready for QA etc, just as it did on the first iteration. In fact, every time a developer needs to work on that ticket, it jumps left to In Dev for the new code changes, then moves across again to the right’.

Note that there’s nothing special about the In QA column we are using in this example. The Looping Method applies equally if the bug had been found in different column, such as Sign-off, or Ready for Live, it’s just that the ticket would just have to jump that much further to the left to land back in ‘In Dev’, so the loop is bigger.

A pictorial representation is below. The ticket reaches In Dev for the first time and is assigned to a developer to write the initial code. It moves rightwards through Code Review and Ready for QA, then a tester picks it up at ‘In QA’, assigns it to themselves and starts testing. The nasty bug is found, and the ticket jumps three columns to the left and is reassigned to a Dev. This ticket will now loop between columns until every nasty bug is fixed, and it can finally move on beyond QA. At that point more bugs might be found, and more looping will start.

It’s easy to see why teams might work in this way –  it’s just doing the same thing on the second, third or fourth iteration of coding as happened the first time. Is there any problem here?

In fact there is. Due to this looping, tickets are jumping horizontally whenever a different sub-team (often, but not always, Dev) needs to work on them next. As a result you are now unable to use the triangulation method of reading a board, as this method uses both horizontal (‘Done-ness’) as well as vertical (‘Priority’) planes to work out the correct order of tickets. But there is no alternative to triangulation to reliably order all tickets on a board, so the Looping Method destroys a key property of a good Agile Board, that it broadcasts to everyone what to pick up next.

In fact the triangulation method tells us that moving tickets left is functionally equivalent to de-prioritising them, as moving left means a ticket is ‘less Done’, and therefore less urgent. But a moment’s thought tells us that it is simply not true that finding a bug deprioritises a ticket, so on the Looping Method our board is Not Telling The Truth – a big problem.

Let’s consider which of the following options we would prefer an available Dev to pick, other things being equal: a) fix a bug on a ticket they had previously coded, b) work on other code that hasn’t reached QA a first time, or c) start something entirely new? The answer is clearly a), to fix the just-found bug. There’s a good chance of getting such a ticket finished and off the board with relatively little extra effort – it genuinely is closer to Done. Remember, it is only finishing tickets that provides any value to the organisation, so it would be crazy to deprioritise a ticket just because it needs some dev attention.

In fact the behaviour we generally want to encourage on finding a bug is for developers and testers to work in close collaboration, with tight feedback cycles of testing, recoding, reviewing and retesting, until the bug is fixed. If each step suffers delays, even relatively minor bugs can take an absolute age to fix, with both parties context switching each time, and quite possibly the underlying codebase changing considerably as other tickets flow to the right. Deprioritising tickets will lead to loss of focus and increase in delays, so that’s the very last thing you want to do to a ticket when it fails QA.

Indeed, if you allow or encourage Devs to start on new code in preference to fixing already-written code that just failed QA, the team will quickly end up with a mountain of unfinished, buggy work piled up in the middle of their board. Such a team – great at starting things, but lousy at finishing them – can only be very unproductive.

Of course, not all teams using the Looping Method sink that far. Good practices outside the Agile Board – strong leadership, effective meetings and internal comms – might compensate for a deficiency in how the board works. But good board usage is designed to make all this far, far easier. What is the alternative practice we can use here?

The alternative is the ‘Tickets Don’t Move Left’ method (TDML)*. It says simply that when a ticket requires the help of some other part of the team to move onwards, you leave it where it has reached on the board and reassign. This way the board continues to represent Done-ness accurately, so the triangulation method works and you can always use your board to figure out the Most Important Thing To Do.

Let’s see this method in diagrammatic form.  The first two parts are exactly as before, but when the ticket reaches QA and the bug is found, it stays in the In QA column and is reassigned to the Dev for re-coding:

And then when it’s time for a second round of Code Review on the recoding, the ticket again stays where it is, but is reassigned to a different Dev for that review. And then it will go back to the QA for retesting, again, without moving column:

This is really a trivial change in board usage. Team members just have to get used to relying on the Assignee field to know what to pick up, and understand that they might need to pick up from any column on the board, rather than only ever bothering to check one particular part of the board (for Devs this would typically be the In Dev and Code Review columns).

I have moved teams from the Looping Method to TDML method in a single day. It really isn’t that hard, and the payoff is enormous; we stop working in a way that continually destroys a board’s ability to clearly represent the priority of work. The triangulation method works, so you get the huge benefit of easily reading your board and knowing what to pick up next.

On top of this, there is a more subtle attitudinal change when you become accustomed to looking across the whole board to find your work. A large part of the Agile mindset is to have everyone working and thinking as a team, rather than the siloed mentality of a Waterfall process, where in strict order Analysts do X, then Devs do Y, then QAs do Z, and the success of the thing-as-a-whole is always someone else’s problem.

The correct team attitude is that the entire workflow is a shared responsibility. In a truly Agile team it’s not your narrow job title that defines what you do; your job is to use all your skills to help the team get its highest priority work all the way to ‘Done’. And TDML is the perfect visual representation of that approach, where everyone is co-operating fluidly with everyone else, as need dictates, to maximise the value of the whole, with a collective sense of ownership of the flow of work.

In that sense the board usage recommendation of this article is very powerful. Though TDML is on one level no more than a minor tweak to how teams use an Agile Board under some circumstances, it has a strong resonance with how team members need to think and act such that they are genuinely a team, working together constructively towards a common goal.

*a caveat to the TDML rule: as with all rules, there is a superior rule which takes precedence: ‘Common Sense Always Wins’. So if a ticket is ever simply in the wrong place on a board, you should always correct it and Make The Board Tell The Truth, whether that involves the ticket moving North, South, East or West. Even the best rule can be taken too dogmatically; it doesn’t make it a bad rule, it just means you need to use Common Sense at all times.

Note: I am indebted to David Shrimpton for introducing me many years ago to the key concepts in this article.

EDIT: this article from June 2021 makes many very similar points:

Don’t move items backwards on the kanban board: “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 back to the source of error, but rather kept in the place where the defect was detected. Instead, people swarm around it and try to fix the problem.”