Skip to content

The Curse of the Queue

This might get a bit ranty

Being British, I should love queues.  Adore them.  Lovely organisation and British fairness all in one single-file line of brilliantness.  Gosh!  All those conversations you can have about the weather or why there are fifteen tills closed when there are people queuing around the block.  And what about all those improvements we share amongst ourselves?  Like, why don’t they cut the bread in advance?

But I don’t love queues.  I hate them. 

Having lived in India for a year, I got very familiar with the push and shove approach when it came to queueing.  Only the strongest survive.  Or at least only the strongest get served.  I recall a friend of mine who also lived there, once strode to the front of a busy London Starbucks queue.  When someone piped up and put him to our very British rights, he apologised and said he had forgotten how to queue.

Epiphany

So where were we?  Oh yeah.  Queues.  I had an epiphany on a course not so long ago.  After going through a few exercises, you know those ones with Lego and Post-its, we were shown a sample scrum board much like the one below:

Screen Shot 2016-10-21 at 14.46.07

Given this was mid-sprint, we were then asked whether this was healthy.  To which I replied like an idiot – “of course!” and patted myself on my back for sheer intellectual brilliance. Sprint halfway through, only four stories left in To Do.

Until the instructor put it another way: Halfway through only two stories have been completed.  Play that forward and at sprint end only four stories would be complete.  Now, I do know there is often a mad rush at end of sprints, but that is not necessarily a good thing either.

So what can we do?

The learning here is about Lean and limiting work-in-progress (WIP).  It’s better to finish something in progress than start something new.  But how do you move people across to this way of thinking if not there already?  Here are some ideas.

Firstly, tell your team that it is a false economy to work on more than one thing at once.  Those stats I am sure you have all seen already about waste when switching contexts are freely available on the Internet.

Secondly, try enforcing them.  Stand-ups and regularly checking the board are but two of many ways of doing this.  If you are using a tool such as JIRA to manage your board, you will often find a setting that limits WIP by either blocking columns or flagging a column red.  And if you don’t have a tool, why, count cards instead.  Looking for instances where a person is assigned to more than one card is normally a good start

Thirdly, good story writing always helps.  If a story is written in such a way that lengthy elapsed time or hand-offs are required to complete it, then there is more chance that someone will work on something in parallel while they are waiting.

This brings me to my favourite part

On your board, look for columns that have words like “awaiting” or “ready for” in them.  And then DELETE them.  Having these columns gives a false illusion of progress and a false economy. These columns allow people to “park” things so they can pick up new things.

This like telling someone you on are on your way when in fact you have you found a nice pub en-route and have no intention of moving anytime soon.

“But”, I hear you say, “what if these columns have stories in them”?  Move them back to the previous column.  And reassign them to the person who last worked on them.

“But”, I hear you whine like Trump, “what if there is no-one free to QA my story?  What does the dev do then?”  Help the QA is the correct answer.  If there is no one to help, it inevitably means the QA’s are either busy or have ran away screaming at their workload.  Help out, find another story to test and see if the bottleneck clears.  After all what is the alternative?  Oh yes!  Pick up another dev story, complete that and make the QA column even longer!

By the way, it is really good fun to remove these queues overnight when no one is looking.  Then the next day explain why you have done this and that from now on stories can only be moved over when someone is free to pick them up.  Pull not push.  Don’t pick anything else up until that story has a new owner.

Well rant over.  Apologies for the sarcasm.  I have had a couple of gins.  I am now trying to see if there is a practical application of these techniques to queuing in bars.  Any suggestions would be welcome.

Footnote: I have blogged on a related topic before here

One Comment

  1. Kim Kim

    Is it also likely that stories that are “awaiting” or “ready for” may require that the Dev push or work with the BA or maybe even the Scrum Master to revisit the story so that it doesn’t get prioritized until everything needed is available? I also realize that sometimes we miss criteria that isn’t caught until the story is being worked. If the story was assigned to a Dev, it may be helpful in this case for him/her to work backward in the SDLC to get clarity as well as helping the QA clear the test queue. Are these acceptable Agile responses to the problem? So with all that in mind, if code has been developed for stories that cannot move forward in development, should the code be removed or left until the issues have been resolved?

Leave a Reply

Your email address will not be published. Required fields are marked *