Everyday Kanban

Discussing Management, Teams, Agile, Lean, Kanban & more

Kanban in the wild: Restaurants

My last post about Kanban in the wild was focused on Disney World. For this case study, we are going to look at the standard restaurant. But, first, a key…

Case study key

  • Dining parties == Task/User Story/Issue
  • Waiting List == Backlog (usually with estimated wait times listed)
  • Reservations/Call Ahead == Special class of service for task/user story/issue (eg. expedite/fixed date)
  • Tables == In Progress Dining groups (WIP limit applied)
  • Bussed & Cleaned table == Deployment
  • Cycle Time == The length of time you are seated at the table
  • Lead Time == The length of time you are in the restaurant (waiting + seated)

The system

Let’s look at the basics first. Restaurants use a pull system. As tables are cleared, new diners are pulled from the wait list to keep the flow moving. They have a defined WIP limit based off of a combination of both how many tables they have and the staffing level of the restaurant at the given time. The wait staff are their “do-ers”. Not only does a restaurant have an overall WIP limit for in-progress tables, each member of the wait staff has a personal WIP limit.

Prioritization

Unlike at the Magic Kingdom, the queue of wannabe diners at restaurants is not managed entirely on a first come, first served basis. Usually it is the basic principle, but restaurants are an interesting case study for specialization. Just as a team might have developers with different programming specialties, each table in a restaurant is not created equal. Booths might be too high to put a high chair at the end and each table might accomodate a different number of people. So, as with any team that has to accomodate specialization, occasionally you need to go to the #2 or #3 priority, skipping over #1, in order to keep diners flowing through the restaurant. So, you might be the top party on the waitlist but there are no tables that fit your needs. Oh, and those soon-to-be diners who get tired of waiting and leave are our “cancelled tickets.”

Classes of service

Some restaurants choose to offer additional classes of service with options such as reservations and call ahead seating. You can call these the fixed date and expedite classes of diners, respectively. These diners meet certain criteria and then get processed differently than your average diner. For reservations, you are promised to be put “in progress” at a certain date/time. For call ahead, you are generally promised to be prioritized at the top of the backlog. Regular diners, aka our standard class of service, are processed first come, first served taking into account any specialization needs mentioned above.

In a development environment, you may create conditions that a task/issue would have to meet in order to be classified as an expedite or fixed date issue. These are two common classes of service but each business can create their own unique classes of service. Just note that you should pay attention to the effect that classes of service can have on your lead times.

Predictability

One thing that differs between restaurants and most development teams is that restaurants generally try to estimate when every person in their “backlog” will be “put in progress” (seated). How can they do this? Well, using historical data, the restaurant has an idea of their general cycle time for a table and how many tables they “deploy” in a X time. Using this data, they can offer you an estimate of when you’ll get seated. In restaurants, just as with developers, estimation accuracy will vary!

Slack

Now you’re not gonna like this part, but slack… Yes, restaurants sometimes have slack in their system. Have you ever looked around while waiting at a restaurant and gotten irritated when you see empty tables just sitting there?!? Well, next time you feel that way, remember that the goal is not to fill every empty table, the goal is to optimize the flow of customers through the restaurant. If you assign too many tasks to developers at one time it can often stall them, much like creating a traffic jam on the interstate. When you sit too many tables too quickly for a server, not to mention the kitchen, you often get subpar service and your meals take longer.

Its hard not to have double standards, isn’t it? 🙂 Whether its slack or estimation, restaurants don’t get a lot of “slack” from the customers. Does this post change the way you look at your restaurant experience? It is a fun exercise to look around at the world around you and examine the workflow of various pieces and parts. I find that the right example can really make things click for certain people.

Happy examining!

1 Comment

  1. I’ve been triple and quadruple sat a time or two at work (both restaurants). In both cases talented “do’ers” can usually knock it out, but in both cases it takes longer to turn/complete the table/feature. In both cases you end up with the same or longer throughput and one burnt out employee.

    Speaking of, I never worked at a restaurant that allowed slack. If I had 3 tables open, they would sit all 3. I had to get good at timing my tables so that I could stagger the stages each one was at in order not to flood my own personal WIP for each stage of dining (drinks, taking the order, maintenance, delivering the food, post delivery support, check delivery and settlement, resetting). Each of those steps had some slack in them to where I could start then next round with another table. Taking drink orders for 3 tables at the same time was tough, but taking drink orders for one table while another was waiting on their food was way better. So by stalling just a bit on putting in a food order while I got another table “complete”, I could do my own personal pull system.

    Interesting topic.

Leave a Reply