Cashier to aisle three
Raise your hand if you’ve played the chaotic game of choosing a grocery store checkout line. See yourself and your competition carefully assessing the number of customers, the number of items, the speed at which each item is being scanned and bagged. Revel in the memory of arriving just in time to join a line with only one customer ahead of you. Recall your despair when that customer experienced an issue that took a long time to resolve. See your rival from a much longer line get out the door before your first item is scanned. All the while, other customers keep jumping between lines, and store management has difficulty tracking pressure on the overall system.
Next in line, please
Now think about your experiences at an airport or the DMV. While it’s rare to find someone who enjoys waiting in these lines, take a moment to consider the flow of work through the system. There’s the set of people waiting, and there’s the set of people ready to serve them. When an associate finishes with one visitor, they call for the next in line. Visitors don’t need to guess or monitor which line moves more efficiently. There’s just the one, and they’ll be called when it’s their turn. If the system is moving too slowly, management can put more people at the counter without shuffling or rebalancing the queue. When the pressure ebbs, people can move back to other work, again without shuffling or rebalancing the queue.
When a frequent flier with the most elite status shows up and an airline wants to prioritize that person’s service, this causes little disruption to how work flows through the system (although it may disappoint those who are not so prioritized). Associates have been trained to call upon people from the prioritized queue first, and when it’s empty, the standard flow picks up right where it left off.
Continuous value streams
In my experience, when a product or service will ship in a continuous and iterative model, the business is best served by establishing the desired order of deliverables. Order, not priority. If the work is not high priority, then why are we doing it at all? (Thanks, Phil Japikse).
Having accomplished the ordering, the next step is to defer assigment until the last responsible moment, which is very often the moment when someone is actually available to execute it. Can you imagine being told, immediately upon arrival at the airport, which member of airline staff will check you in? What if that associate has a personal emergency and has to leave suddenly? Who serves you now, and more importantly, where do you fit into that person’s existing commitments? Instead, let teams continuously execute on the next value we wish to add to the system. Order the backlog such that the handful of “next right things” to deliver are right there on top, and let each team member pull the top item1 as soon as they’re free to take on new work.
Across multiple development teams, I’ve found a number of advantages to this model. Aside from simplifying assignment and facilitating dynamic adjustment to those “next right things,” it inherently dismantles the thinking that Person 1 always does X and Person 2 always does Y. While there’s certainly a place for subject matter expertise, the darker side of that coin manifests as knowledge silos and single points of failure. If the five top value-adds for the business are all in the domain of X, and we only have one person doing X, then our system is screaming at us: “It’s time for the team to crosstrain!” Better, in my opinion, to get ahead of that fire drill by thinking in terms of collective ownership all along the way.
What do you think? Where has this model worked for you, and in what cases does it fall apart? Let me know in the comments or LinkedIn!
- We’ve often said it doesn’t have to be the very first item. Maybe we allow looking three to five items down the list given a good justification. For example, someone is about to take time off and Item 3 is low hanging fruit they can easily tackle before departure. As always, put people first. The process should serve them, not the other way around.