This is going to be a quick rant post, hopefully. Today I saw another Kanban board which had a “Read for test” column on it, here’s the screenshot:
Not 1 but 2 “Ready for” columns!
I Think “Ready For” Columns Are Baaaaad
With most Kanban boards you mark a card as done when it’s ready to be pulled into another column. If that means it has to be deployed before a card is ready for test then so be it. The last thing we want is cards just sitting around waiting – this is baaaaaad. “Ready for Test” usually means it’s either deployed (and yet to be tested) or waiting to be deployed. Either way, not much is happening to the work sitting in this column. Basically it’s waste (or “muda” as the Lean Kanban aficionados might call it), and remember, waste is baaaaad.
Seriously, I Think They’re Baaaaad
A result of using these “Ready For x” columns is that they tend to slightly move us away from the “stop the line” practice that good Lean/Kanban systems employ. Basically whenever there’s a problem, or a bottleneck is appearing, we want to stop the production line and address the issue. So, if we keep all these “Ready for QA” cards in our In Dev or Code Review Column (basically whatever column comes before your Ready for QA column) then we’ll very quickly reach our WIP (Work In Progress) limit and the line will be stopped. That’s a good thing! We want to catch that bottleneck as soon as we can, we don’t want to hide it by pushing our cards into another “buffer” column.
Did I Mention That I Think “Ready For” Columns in Kanban Are Baaaaaad?
Yet another problem with “Ready for x” columns is that they quite often tend to be push rather than pull columns. You can’t really pull into a Ready for QA column as it isn’t an actual “workflow” state, it’s a “wasteflow” state (see what I did there?). I mean, who’s going to pull stuff into that column anyway? I’ve yet to meet a “ready for test” team who just sit around pulling cards into their column before marking them as “ready” (presumably once they’ve verified that they are indeed ready for test). Ok, you might have a deployment team who are responsible for deploying stuff to your test environments and so forth. In this case, your workflow state still isn’t “Ready for test” it’s “In Deployment”.
Conclusion
“Ready for x” columns make baby Jesus cry.
DevOpsNet 
Apposite and true. Work in progress limits are what Jesus would have wanted.
Nice article. “Ready for” columns are basically buffers – the equivalent of parts stacking up on the factory floor in front of a workstation. As such they should be viewed as a potential area to improve.. but – I’m not sure I agree with the passion that you have towards removing them.
Say I have a technical writer… and that technical writer is the bottleneck in my flow. Things get stuck waiting for her to document before we push to production. Certainly I don’t ever want that writer to be without work to do as time lost at the bottleneck can never be recovered (Read “The Goal” by Dr. Eliyahu M. Goldratt). In this case a buffer to protect the bottleneck makes sense.
I agree with you that placing buffers without consideration is a bad idea.
Pull where you can, push [into buffers] where you must.
Spot on, James – ‘Ready for X’ columns seem to me to indicate a cargo cult mentality (“we’re using Kanban therefore we must be Lean!”) without understanding the fundamentals behind the practices, such as waste reduction, avoiding inventory build-up, etc.
Thanks for this article, this is something I’ve been pondering for a while.
Your 1 “Ready for x” board has nothing on the ones currently on show at our place.
Ready for test
Ready for deployment
Ready for UAT
I was looking at them thinking, this can’t be right but didn’t know why.
Also – your last sentence killed it!
The vast majority of Kanban adoptions I’ve encountered are ‘push’ based rather than ‘pull’ based systems. I do wonder if the community should advocate more constrained rules for new adopters in order to force teams to reflect upon what changes would improve their current process when they’re currently sweeping all problems under the ‘our context’ rug.
And how will you know when where your bottlenecks are if you don’t understand when work is “done” in a given state? How will you differentiate between value-add activity and work simply waiting to be pulled to the next state?
Good questions, thanks for the comment!
Q: “How do you know where your bottlenecks are?”
A: Because you can’t pull anything in to your column! That’s surely the most obvious way of identifying a bottleneck, when people are immediately impacted due to a downstream blockage?
Q: “How do you understand when work is done in a given state?”
A: I usually put a tick or a star on the card to denote that it’s “done/ready to be pulled”. Of course, there’s no substitute for face-to-face communication!
The other thing worth mentioning is that “Ready For” columns don’t really work in a pull-based system. Who pulls into the “ready for” columns anyway? What I’ve tended to see with “ready for” columns is people adopting a push-based system instead.
“Ready for” columns are actually buffers and should be used whenever task is passed between different people / teams / companies, especially if their performance or work cycles varies. Just like buffers in computer science, they help to maintain steady flow of work through the system, and allow for bundling and re-prioritization of work between workflow stages. Also, just like buffers in computer science, their size/capacity should be limited. With such limits in place you still get the ‘stop the line’ behavior when things go really bad.