We Need to Stop Queueing Quality

What a restaurant kitchen can teach us about flow

The debate about whether teams should have an In Test column is one that comes around every so often.

The concern is usually the same: once testing is split into a separate column, it can encourage handoffs, reinforce role boundaries, and create bottlenecks in delivery.

I’ve written about this in more depth before, but it can be a lot to take in. So I wanted a more memorable way to explain it, and it reminded me of when I worked in restaurants as a student.

The restaurant kitchen analogy

A useful analogy is a restaurant kitchen.

With a board like In Dev → Waiting for Test → In Test, we are basically running the kitchen like this:

• chefs cook the food

• finished plates are put on the counter, waiting to be checked

• one person checks every plate at the end before it goes out

At first, it can look organised and efficient. It gives us:

• clear boundaries (I know my bit)

• low coordination cost (I can just get on with it)

• visible personal productivity (I can show what I finished)

• less ambiguity (I know what to do next)

The problem is that it optimises for people staying busy in their area, not for work flowing through the whole system.

When things get busy:

• plates start piling up, waiting for the final check

• feedback comes late

• people keep starting new dishes while finished ones are waiting

• the final check becomes the bottleneck

• service slows down even though everyone looks busy

That is what a separate Test column can do to a team.

In a better kitchen, people do not just stay in their lane and keep cooking while plates pile up. They:

• talk more

• call out problems earlier

• help each other when service gets busy

• check quality as they go, not only at the end

That is the shift we should be making with our boards too. It’s not about less testing, but about earlier testing, faster feedback, and more shared ownership for getting work finished.

Moving to a single In Progress column is not about removing testing.
It is about stopping quality from being treated like a final queue.

To be fair, it does ask more from the team:

• more collaboration

• more conversations

• more shared responsibility

• a bit of short-term discomfort

At first, it can feel slower and messier, and when things are busy, it rarely feels like the right time to make a change like this. But in order for us to deliver on what our organisations want from us, we need better flow for:

• earlier feedback

• fewer queues

• less rework

• more work actually finished

So the shift is really this:
From: “How do I keep busy in my role?”
To: “How do we finish this piece of work together?”

What the discussion surfaced

I shared the analogy on Slack, and it sparked a really useful debate.

1. The analogy was just the nudge they needed
For a few people, it was the nudge they needed. They already understood the idea, but did not feel confident explaining it. The analogy helped bring the “why” back into focus and made it easier to discuss with their teams.

2. Sometimes the column is tracking environment state, not testing
A team shared that they were actually using the In Test column to indicate that something had been promoted to the staging environment. It was a final check to see if it could go live. It was not really “in testing” in the way the column suggested. So they dropped the column and used a Jira label to indicate that it had been promoted.

3. Removing the column does not automatically change collaboration
Another team said they dropped the column and used labels, but they were still passing work around. It did not make a difference to how they collaborated. In this case, dropping the test column could actually make things worse, not better. A possibility here is that the team is still optimising for people staying busy rather than for work flowing through the system.

An approach that could help is looking at their ways of working and shifting from optimising individual efficiency towards pairing or mobbing to get work finished as a team.

4. The change can feel threatening, especially for testers
One team said they were up for it, but no one seemed all that enthusiastic about the change, especially the testers, so they let it slide. I totally get it. I’m lucky enough to have worked in environments that have and have not had test columns, and I have seen the benefits first hand. But I think I would have been apprehensive too, especially if the thing that helped me see that I was needed and valued in the team was about to be taken away (the In Test column).

A few champions in the team who are willing to trial a different way of working and share what they learn can help. They could start as a small pilot, then roll out gradually across the team. Bringing in examples of other teams who have successfully done this can also help people see that it can work and that people are still valued, even when the In Test column is removed.

5. Teams still need a clear way to talk about flow
Another team shared that they tried it, but stand-up took much longer because they could not see where a ticket was up to and had to dig through it to find out, so they put the column back in. This made me wonder whether stand-up had become more of a status update than a conversation about flow.

What could help here is the team revisiting what stand-up is for and how they use it. This post, “Should the daily stand-up die?“, is a good starting point for teams that want to rethink their stand-ups.

Close

Simply dropping the test column is a blunt tool to encourage collaboration. There is every chance it just drives the work underground, where developers and testers carry on working in silos and passing work around, but now it is harder to see.

That is why I see it less as a solution and more as a forcing function. It helps teams surface the harder questions about how they actually work:

• how does the team share what has changed and get feedback?

• how do we maintain flow when people are busy?

• how do we make work visible without turning testing into a queue?

The queues on our team boards often reflect queues in our thinking, ownership, and collaboration.

If we do not stop to understand why those queues exist, we risk queueing quality too.

Further reading

• My original post (August 2018): In test column | jitgo.uk
  A detailed look at the problems having an in test column causes and the thinking that led me to this framing.

• Theory of Constraints deep dive: Faster delivering teams? Kill the test column
  A practical look at how the test column becomes a bottleneck, and how to redesign flow.

• Janet Gregory: Do You Need a Test Column?…. Let’s Talk.
  A balanced perspective on when a test column helps, when it hurts, and what to watch for.

• The Testing Pirate: You don’t need a test column
  A clear, opinionated take on why the column often becomes a handoff trap.