Agile/XP Restaurants

It occurred to me one day whilst eating at Taki Japanese Steakhouse that whether the owners knew it or not, they were practicing many of the fundamental concepts of Agile/XP. Now I've never heard anyone at the restaurant use such words other than the people I may be lunching with at the time; though I've observed through countless visits their relative consistency in these practices.

Let me walk you through the experience.

1. Non intrusive relationship building
Someone casually greets me nearly as soon as I get through the door onto the premises. Whether it be the actual host closest to the front door, or the sushi preparer furthest away from the door, someone always says "Hey", "What's up" or "How are you doing" before I've had opportunity to fully take in the surroundings. What's interesting is in some restaurants when I'm greeted, I feel like some unsolicited obligation was just placed on my shoulders and now I owe someone something for the attention. Here, I walk in anonymous, I become important for a moment with no obligations, and then they leave me alone to soak in the environment for a moment or two. The greeting is truly a "Hey, I'm glad to see you and glad you're here" ... without obligation, pressure, or being made to feel like I'm putting the host out by making him or her do their job. After I've had a moment, the same or different person, host or not, ordinarily asks me one question: "Where would you like to sit?" Often, someone simply hollers for me to go and sit anywhere I choose. And I do.

Relationships in an Agile/XP framework are low ceremony just like this. There is no formal diplomatic relationship with Mr. Barnaby Jones, President and CEO or "The Team" with formal inquests for data by utilizing two of each kind of resource in the company in the pre-scheduled executive conference room with hors doeuvres, mint tea and a ballroom dance. Quite the opposite, the relationship is of necessity and without baggage ... "Hi. My name is Matthew. I wondered if you'd like to spend some time teaching me about the problem you'd like to solve? I have some index cards and a pen. We can go anywhere you want for the conversation and it can be as long or short as you choose." This approach works at the restaurant and client-site alike - because they are fundamentally the same in nature - simple, casual, customer servitude.

2. Sprint planning meetings
Now after I choose a seat somewhere in the building, it is quite okay if I grab my own sushi menu or wait for someone to bring one over. Furthermore, I have the option of walking around looking at the sushi bar, talking to the chefs, reading the assorted menus, staring at the fish, or simply sitting down immediately. There are no clear expectations, but I have many options - start now, start later. Talk to anyone or be silent. The customer:restaurant relationship is one such that the sprint planning meeting, i.e. the beginning of this particular eating experience, starts when I want as the customer, on my terms, in the order I choose.

In nearly every case at this particular restaurant with few exceptions, the minute I sit down, someone expectedly asks me what I'd like to drink, and whether I'd like one of two soups, and one of two dressing options for a salad. You see, I have options. Somedays I choose no salad and one soup. Other days I choose both soup and salad but have options to vary which type of soup and salad combination is appealing to me for that particular visit.

Agile planning meetings are customer-driven just like this. The point of delivering software is to solve a customer need and/or problem. When we sit down with the customer, on the customer's schedule and convenience, it is the customer that chooses what items we discuss, in what order we discuss them. Now we may want to add a pinch of risk and value considerations into the conversation, but the meeting is driven by the customer. When at the restaurant, I have the choice of discussing and choosing drinks, soups, salads, menus, location, and timing. When we sit down with customers to plan the next sprint, they have the choice what what gets delivered next and in what order. If we practice two week delivery sprints, there is no likely need to discuss 'time' as this window is far shorter than current industry practice in many companies anyway. The point is ... the customer drives the experience per planning meeting or experience. Were the restaurant to note my requests on the first visit and then lock me into those choices everytime I visited thereafter, I'd stop going back. My tastes, preferences, moods and desires for sushi, soup and salad change weekly. Thankfully, so does the restaurant.

Ah, one beautifully Agile-like thing to note - when I make my drink, soup and salad choice, the server leaves immediately. In less than 3-4 minutes (Yes, I clocked it multiple times with witnesses), the waiter brings back our selections for this portion of our experience - for the entire table. I don't have to wait 18-months for a prototype, I asked for something now and they delivered something now. They deliver something right now to instill confidence in me that they are capable of delivering at all. Furthermore, if I receive something right now ... I become more patient for those things I expect later. And what could possibly be more enticing? The first delivery, the soup and salad, are free.

3. Delivery Sprints
Now ordinarily at many restaurants I've experienced, while a salad and drink may or may not show up in a timely manner, the entrees are usually delivered in one big bang for the table. The variables impacting how quickly and thoroughly deliveries are made ordinarily include the number of people placing orders, orders en queue, number of servers, number of chefs, the complexity of the item(s) ordered, number of people at your table and so on. For any one or more reasons, one could experience food in fifteen minutes or fifty depending upon the situation.

This simply is not so at the sushi restaurant under scrutiny. On any particular day, I may order two or more sushi rolls depending on the day, the mood, and the hunger. As well, if with another person or two, they order two or more sushi rolls (approximately 8 pieces per roll for non-sushi-ites). Were we at standard and traditional restaurants, we wouldn't see this food until all food was prepared and then delivered at the same time. At this restaurant however, all orders are queued and prioritized for the chefs, by the chefs, in order to deliver quickly. Then, depending upon how busy they are, the chefs will make one roll per customer per table and the first wave of rolls is delivered immediately thereafter.

Most often this is not our entire order. However, they continue to keep me happy because they gave me food immediately upon entry (the soup and salad), and then they deliver a portion of my entree (the first roll) thereafter. Often, I'm barely done with my soup before the first roll shows up. And in nearly all cases, the second roll shows up before I'm finished with the first. Of course there are variations in here based upon complexity of roll, number of orders, number of people sharing or individually ordering and so forth. The point is ... I as the customer do not have to wait.

Agile practices expect teams to deliver incrementally and quickly just like this. When a customer places an order of ten user stories, maybe even prioritizes which ones they would like to have first, we do not need to wait until "all" work is done before delivering anything. More appropriately, we'll take a look at the order and priority and determine what we will deliver first, and deliver it. The difference between this idea and common software practices for many teams today is we are discussing what can be delivered fully functional, fully usable, fully tested in a two week sprint, not a 6-month requirements elicitation phase generating a document that dicusses what will be delivered in the next 6-months.

Most restaurants understand that to keep customers, customers must be happy. They know that customers come to the restaurant because they are hungry, not because they wanted to see the cook or talk about how difficult it will be to prepare the food. When customers order food, they want food now rather than the promise of food later. Software and systems customers are no different.

4. Pairing+, Backlogging and Prioritization
At this particular restaurant, were you to walk by the sushi bar you would see 1-3 sushi chefs working quickly and efficiently on any number of orders at the same time. Looking a bit deeper what we really see is all of the orders laid out side by side in front of the chefs, in order of arrival. Now what's interesting is that one entire order is not created at the same time. In fact, if there were 10 sushi orders in front of the chefs, the orders become mentally indexed by them thereby creating a type of mental, prioritized, backlog based upon a) the customer arrival time (first come, first serve), and b) what work is going on at the time. Let me explain.

Let's say there are six orders split across three tables: 1 california, 1 spicy tuna, 2 tempura salmon, 1 eel, and 1 rainbow roll. If the upline sushi chef (first reviewer of incoming orders and usually the senior) notices there are two orders of tempura salmon at two different tables, he'll ask another downline chef to pick up the order for two tempura salmon rolls and it will be done. At the same time the lead chef notices the order for a rainbow roll from a yet different table, which just happens to have salmon in it, and he asks the same chef currently building the tempura salmon rolls to build the rainbow since the salmon is out and about being prepared. The remaining rolls are each unique to the other in terms of unique ingredients, but still have common denominators involved, i.e. rice and seaweed/rice paper/soy paper. So either the primary or another chef will build the base infrastructure for the remaining california, eel and spicy tuna rolls concurrently, and then create the variations thereafter. In practice, the three rolls picked up by chef B and three by Chef A should all finish around the same time; but remember, they do not wait until all is done to big bang the meal. Thankfully, they do not build out the entire base infrastructure for all possible orders and only then begin building on the details. First roll done is delivered. Next roll done, is delivered, and so on. A form of spiking the system if you will as mentioned in some of Mike Cohn's work in Agile Estimating and Planning.

And they do this in real time. There is no time for meetings to discuss work - work is performed in real time, adjustments are made in real time, and the team picks up whatever work is necessary to make that particular batch of orders (sprints) available to the customers.

Agile teams make real time assessments, prioritizations and indexes of all known backlog elements at the time of review just like these sushi chefs. There is a backlog and ideally the customer prioritizes what they want first; but the technologists (chefs) are expected to manage customer value with delivery risk at the same time, so order of construction will be balanced between customer desire and risk of delivery (technology or food quality). Thankfully, the chefs have one backlog, else the probability of my order getting lost increases with every additional backlog from which the cooks pull and execute work.

Agile teams pair up when necessary just like the sushi chefs. When in need of help getting the work done, mentoring, accountability to quality, teaching, timeliness and efficiency, pairing up with a peer or even more experienced person is immeasurably valuable. Having a team member sit beside you and share the responsibility helps both people improve in real-time versus delivering something to alleged completion, and then receiving significant rework feedback at a later date. Rather than sending a sushi chef to endless hours of coursework, they learn through pairing. Rather than sending a technologist to days or weeks of class, pair them with someone.

A couple of mild differences to note in a sushi versus software construction environment:

  • Regarding sprint planning versus real-time assessment activities: In the sushi environment a single person is reviewing all incoming orders and distributing the work in real-time; whereas in the software environment during an agile sprint planning session, all team members actually review the work and sign-up for what work they will do during the upcoming sprint. Note the difference is really based upon the work product and customer expectations. For example, I want my food in under 30 minutes as opposed to a 2-week sprint. Having multiple 30 minute sprint meetings would delay my food to perhaps 2-weeks, which of course, I stand opposed. The solution to delivering is context-driven in both examples. Both are sprints; both are implemented contextual to the problem statement.
  • Regarding pairing: In the sushi environment, pairing is used to teach and hold accountability to the quality, timeliness and efficiency expectations held by the senior sushi chef and restaurant owner. Sometimes, pairs are used to perform concurrent delivery work for the same sprint. In the software environment, pairing is used for education, quality, timeliness and efficiency in developing a solution for a customer driven sprint. However, the purpose and use of pairing in no way pays homage to Mythical Man-Month logic whereby if one person can do two rolls in 5 minutes, 2 people should be able to do 4 rolls and so forth. Sushi and software stop showing similiarities exactly right here. Something to note.

5. Review meetings and demos
Nearly every time a server passes my table thereafter, someone asks if everything meets expectations - and this includes servers _not_ taking care of my table. Constantly are people asking if the food is good, warm, whether it meets expectations, more drink, less drink, different drink, napkins (I'm messy), etc. Social conversation even occurs just asking how the day is, what is planned for the afternoon and so on. The informal, relaxed relational conversation is continued throughout without pomp, circumstance, high-ceremony or the tedious dancing of the "Where's my waiter?" game. Constantly is the experience being checked upon.

Agile teams informally and constantly check with customers for acceptability; and specifically, if change is desired at any time along the journey just like this. In the customer environment, change sometimes happens with or without customer desires or plans. As product and service vendors, Agile teams roll with the punches accordingly. A new change comes in, prioritize it within the next sprint, and deliver it as requested in the next sprint. How much more expensive eating at a restaurant would be if we were charged everytime we changed our minds about food, drink, temperature, dessert or seating arrangements.

Agile teams have review meetings and demos very frequently

  • Deliver a portion now, more immediately thereafter, and more immediately thereafter, etc.;
  • Ask if it is what was ordered (perception v reality);
  • Ask if it meets expectations;
  • Talk about it if desired; and
  • Make changes to the next delivery iteration as requested.

At the end of every review experience with the customer, leave knowing what is most important to the customer next, and deliver it. When it is ready, show it to them and invite reaction. How often is often contextual to what is being delivered; but no more than 30 day increments - two weeks being ideal.

And as far as the sushi restaurant? They're Agile and don't even know it. What a great problem to have. How many software solution providers out there have this problem? Or is it a strength? You decide. As for me, I'm thankful my favorite sushi restaurant is an Agile practitioner.

No comments:

Post a Comment