At one point or another in our lives we have all experienced a long queue, stuck in a car on the motorway, sat on a train waiting for an open platform. My favourite memories stretch back to that line for the lunch at primary school where it was cake and custard day!
A recent trip however really highlighted a major problem with queueing systems. This trip I can only describe as a punishment camp for parents…. Legoland Windsor.
Legoland Windsor had some incredible queues for the rides and amusements, the worst I spotted was a two hour wait time for the Ninjago ride.
So the questions that spring to mind:
- Why don't they just build more rides?
- Surely they could just restrict the number of people into the park?
High demand for existing services and the cost of scaling, weighed up against utilisation are all dynamics at play here. This is true of most, if not all service systems. If you are looking into scaling your organisational flow, these are all dynamics that will effect your ability to deliver as a unit to your stakeholders.
The thing thats been bugging me with the whole demand vs supply throughput and wait time problem is why do we instantly think that adding costly resources is the answer to our queueing problems?
What if first we looked at how we queue and how we can use the information around us to make better decisions about whether it’s worth queueing at all. Would providing our customers and stakeholders with more information about the potential wait time and position in the queue actually lead to a better experience?
I've recently read “The bottleneck Rules” by Clarke Ching and it reminded me that not all bottlenecks are bad. Some as Clarke points out are there for safety and quality.
In the book Clarke talks about a delayed flight due to bad weather and the airport shutting down available runways for safety reasons, in effect the weather acting as a bottleneck to limit the amount of flights so there wouldn’t be a tragic accident. I guess what stood out about that analogy were the dimensions and perspectives that the effect of a bottleneck can have.
Let me explain.
If we look at the safety perspective from the Airport it’s definitely the right thing. From the passengers “in flight” again it’s the right thing for their safety.
From the perspective of those waiting for their journey to work, or family holidays etc, those basically stuck in the airport, it’s a really sucky situation. Clarke has a similar take on this as me. Theres not a lot we can do so lets grab a coffee and cake. Ive paid my money, I’ve made the effort to get here… I may as well wait.
So how do I know waiting is the right thing to do?
I could be stuck here for days…
Let's push this analogy further. Planes, Trains and Automobiles. A film from the 1980s starring John Candy and Steve Martin, where a pair of travellers set off on their journeys home for Thanksgiving while being hampered all the way by weather and the eventual choices they make in order to reach their goal. They continue to change their travel plans and don’t sit and wait for the latest transport system to resolve its difficulty and get them back on their journey.
Some may see this as wasteful, others may applaud their tenacity to complete their goal. In order to make this decision though we need information
Theres something here about being able to make a decision about your position in a queue, and what information you need in order to do so.
Weighing up the cost and wait time vs potential benefit from staying in position allows us to make a decision.
If you are able to communicate a position in a queue, why isn’t it possible to combine this with forecasted wait times to your customers, users, product owners, stakeholders. And if you did so, would they still wait?
In any queue and especially in Legoland there is something fundamental that we need in order to make that kind of decision.
Transparency for your wait time in a physical system such as a coffeehouse is what you can understand from the queue of customers in front of you vs the amount of staff working the till and the espresso machine.
However that can only go so far as the gaggle of people clustered around the serving side of the bar waiting for their order, as they also have a wait time and no obvious order, and what happened to the chap who ordered a panino with their latte, where is he in the queue.
Sure we maybe able to see him, but how long has everyone else been there, when will I get my turn to order? When will he get his panino?
We’ve suddenly uncovered a sub-queue of a different work type and this now has its own SLE for the staff to deal with.
So we have this kind of physical transparency that we can inspect. We do this a lot in Agile by using Kanban boards to communicate how much work and where it is in the flow.
What we don’t typically have is an SLE or Service Level Expectation that tells us how long we will be in the queue in order for us to make a decision about leaving or staying in position. This is a kind of virtual transparency that Teams migrating from Scrum to Professional Scrum with Kanban find a massive benefit in using.
The chap waiting for his panino as well as a coffee, has no idea how long he will be waiting in his own hidden/sub queue - The new panino and coffee SLE. Actually, how are the staff dealing with his priority in the work system etc. Ahhh it gets so deep the more I think about it.
SLE’s for forecasting are essential. A position in the queue is one thing, but knowing when you will be served in addition to your position is a really powerful decision making tool.
(**An SLE is a forecasting metric that allows us to understand and set expectations about when something will be usabale/available/ready/done. SLE’s are calculated on known sets of historical data from the context of the flow you are inspecting. Every system will have one. It is how long a given item takes to flow from start to complete within a teams workflow.**)
Legoland had a neat system, dotted around the park were screens letting the customers know the estimated wait time. The main problem with this is that they were seemingly not driven from realtime data. The system became even more frustrating for customers waiting in queues. Legoland provide the option of a paid-for virtual system that queues for you. A Q-Bot.
So for a sum of money you can reserve a virtual space in the physical queue. You can pay more to halve your wait time, you can pay even more to jump straight to the front of the queue.
To put this in context, imagine you are waiting for a coffee in your favourite coffehouse . All of a sudden someone walks to the front of the line and orders ahead of you. A little bit of British passive aggressive commentary forms in your mind as another does the same, and another etc. You get the picture I hope.
But it’s ok for the coffee shop as they still sell coffee, the queue jumper is happy as they don’t have to wait…. But what about everyone else waiting.
So we have arrived at some kind of SLE independence, where physical systems and virtual systems are saying two different things. I can physically see there’s a big queue in front of me and the board is telling me a wait time but we have hidden sub queues that we cant control One queue is actually formed from two systems (Virtual and physical) converging and jostling for priority.
The major problem with this queueing system is while the queue in front of you is transparent, as is the estimated wait time, there is no transparency of the ‘virtual queue’ as well as the physical one.
It would be kinda cool if you had a queuing system held total transparency and even provided your position in the queue as well as a wait time wouldn’t it :)
Aim for complete flow transparency
Transparent flow is incorporating all of your flow systems openly and honestly and communicating that in a way that allows for Inspection and Adpatation. If people want to pay to jump the queue then lets also make the impact and the ordering effect on our backlog equally as transparent and not hidden away so we frustrate our customers.
In my example above, the Legoland team could make the Virtual queue transparent to those in the physical queue and its problem solved. We can combine the estimated wait time with what I can physically see and now with the virtual data of SLE and position. I can now make an informed decision.
As work flows into your backlogs from multiple sources, the Product Owner and even the Development Team shifting prioritisation and order are bumping other work around. (kind of like the Q-Bot system above).
The more transparent you can make this ordering the better engaged your stakeholders will be, combining this with an SLE, your stakeholders will be able to understand their true position in the queue and make a decision to wait or leave.
Your Kanban board is your transparent flow, no matter how work enters your delivery system you must make this transparent. If you retain hidden queues for fear of showcasing unplanned work, you are undoing all the good work that you may have done by promoting transparency in the first place.
Work to deliver measures that speak to the wait times of the system. Measure how long it takes for a single item of work to get through your flow to value delivery, and this will be your SLE.
Using cycle time with your teams flow will provide a real time SLE of days for a single change. It allows teams to make strategic decisions about ‘when’ based on a level of confidence and risk.
You now have a way of communicating a forecast that is honest to your system and not based upon intangible measures such as story point velocity predictions.
We now have transparency.
For more information please see:
The Kanban Guide for Scrum Teams - scrum.org
Professional Scrum with Kanban - scrum.org
Bottleneck Rules - Clarke Ching - Available on Amazon
Actionable Metrics for Predictability - Daniel S. Vacanti - Available through LeanPub and Amazon