Theory of Constraints at lunch

Mary Poppendieck and James Bach taught me to look out for lessons in everyday life. Everything is connected with everything else. So, as I visited today during lunch break the local McDonald’s restaurant, I started to observe while waiting for my lunch. Here is what I observed filled in with some lessons from systems-thinking and the Theory of Constraints.

So, the restaurant was unusually full today. There were three counters open, serving the enqueued and waiting people. Whenever there is a queue, there is something locally optimized and the bottleneck around it is not exploited. Therefore I started to look out for the underlying reasons. Since I had previously worked at a supermarket counter, I had a feeling for what to watch out for.

Starting with the first counter, there was a young woman serving. She was obviously helpless as I watched her using the cashier and giving out change. She seemed to be very uncertain and routine hadn’t revealed to her. Obviously for me that queue was a bad choice to wait for food, since I got hungry.

On the next counter, there was a young man serving. He had a bit more routine or experience as the young woman next to him, but he seemed to be rather inexperienced compared to others I had seen in previous visits. In addition that guy seemed to be in the role for catching up on serving the food to the tables, exchanging fries when they were finished, etc. So, this guy was really overworked, and I could sense it by observing him for maybe two minutes. No good choice to wait for, when you’re hungry, either, but I took the queue, since the colleague who went with me was on the last open counter waiting, and I found it a better mix to have us wait in two different lines.

On the last counter, there was a real senior serving. I have seen him several times there in the past, and he was really fast, compared to the others. So, my colleague got seated long before I placed my order.

Now, this isn’t yet the final story. What then happened was that the guy from the counter for the McDrive helped these three out with the cashiers and the serving. Given the fact that the drive-through is the most critical, fast-served place at such a restaurant, that guy was really up to the last cashier. Now, the McDrive guy was not helping out on every counter, but yet on a single one. So, guess where he helped out? Yes, right, on the last of the three that was already way-outperforming the other two. If I had to put a number on it, that counter had double the throughput of the other two counters without anyone helping there.

Why is this a problem? Well, after I got finally served by the last counter – the queue was empty right before I got to order at the second counter – I got to my colleague and explained him the following. There were basically three queues. There was one bottleneck station, the first counter, and the second counter had generated a bottleneck station himself by conducting all the work that the first woman was not getting to, since she was too slow at serving. Last, there is the regular station, which is not a bottleneck.

From the systems point of view the regular station got optimized when the McDrive guy started to help out. The Theory of Constraints taught me that instead everything should have worked towards the bottleneck stations. This could have been to get the McDrive guy helping the second counter guy out on the surrounding preparations with the fries or serving the food to the tables. This could also have been to free up some of the woman’s time by fetching the just ordered food from the customers in the line, so she mainly needs to take care about the coins and the change. Instead a non-bottleneck workstation got optimized, resulting in local optimization.

Another reason this optimization choice was bad, is the fact that the two others did not have the slack to learn how to work faster. The worst performers in that restaurant were constantly under pressure, since there were more and more customers queuing up all the time. Instead of providing slack time for them to be able to think about how to do their work more efficient, their thinking collapsed under the perceived pressure from the customers waiting in line to get served. Surely, they will not have learned anything during these maybe 15 minutes I could watch them, since they were permanently dealing with the next fire to take out.

Finally, how does this relate to software at all? Well, give your people the right amount of slack, the right amount of time to think, and watch out for local-optimizing. Alistair Cockburn uses the analogy of “unverified decisions” as inventory items to transport Lean processes and lessons from the Theory of Constraints to software development. So, find the workstations where these “unverified decisions” pile up. Where in your process are many decisions handed-over to someone else? Where are the most handed-over? These are your bottlenecks. After having identified the bottlenecks in your process, you may start to either exploit them, or to place in quality steps right before the decisions get handed-over (this is the major case for test-driven development), or see how others can bring in some relief for the bottleneck station by taking over some of their work. Taking the problem to the systems view helps understand the dynamics in place – for software development as well as for food serving in a fast food restaurant.