Play this simple game with your colleagues when you have a chance. Give them a piece of paper and a pencil. Tell them to pretend they run a pizza shop. Ask them to describe the variety of what they deliver.
This is a tricky question. The answers are usually about the variety of pizza sizes, crusts and toppings. But let’s look at the Domino’s store closest to where I live. (You can tell I live in a temperate climate.)
It’s interesting that Domino’s don’t call themselves the pizza crust or topping experts, but the pizza delivery experts. They are not in the pizza baking business. They are in the pizza delivery business. Baking a pizza pie is just part of the process of delivering it.
The Pizza Service Delivery
The store delivers pizza two ways:
- Pizza ASAP
- Pizza at the right time
When I order the first type of delivery, speed is important to my satisfaction. I order this service when I’m hungry. If it takes too long to deliver my pizza, I have to look at other options, such as ordering Chinese takeout or cooking something in my kitchen.
When I order the second type of delivery, speed is not as important as the precision. It can take many hours from placing my order to taking delivery. If I have invited guests and want to serve pizza at 7pm, I wouldn’t be happy if the store told me, like a cable guy, to be there from 5 to 9. In that case I would have to look at other ways of entertaining my guests. (But this store can deliver with the 5-minute precision.)
Note that the two services have different customer satisfaction criteria:
Note that neither service has, as a satisfaction criterion, a metric resembling velocity or throughput. Customers mind with their own pizza order delivery, not how many pizzas per hour the shop can bake.
It does matter, of course, how well-cooked the pizza is, how it tastes and whether the toppings are correct. But the standardized ingredient supply, baking process, and topping checklists take care of that and result in predictable, satisfactory quality. The “expert” part of running this business appears to be how to manage the work and sequence the orders such that the shop can deliver to two different classes of customers and meet their conflicting satisfaction criteria.
From Pizza to Knowledge Work
A software development manager requested a consultation with me. His group tried to start an iterative development process, adopted some practices, but was unhappy with several things:
- their “velocity wasn’t consistent”
- there were “too many interruptions”
- the retrospectives at the end of two-week iterations showed that, although something was finished, not all of it was planned at the start of the iteration. A lot of what was planned wasn’t finished.
The following picture emerged during our consultation.
The group was producing a new analytical product. One service they obviously delivered was a stream of new product features. Several key, early-adopter-type, well-paying customers occasionally requested custom analytic research reports. Why the group had to deliver them – it will suffice to say, these particular customers helped create the market and it fit the company’s growth strategy, so it was the right thing to do. These reports required creative work by specialists skilled in statistics and data mining. But the same specialists had to produce some product features as well.
The group had its fair share of production issues. It was also often contacted by the Sales department to assess feasibility of proposed features. The Sales people would use this information to negotiate with customers and possibly close deals. Often, this information would make no difference, the customer would or would not sign up regardless of the feature, but sometimes it would bring in a sizeable new contract.
Here is the summary of what this group delivered:
|Service||To whom||Request arrival pattern||Customers’ delivery expectation|
|Service #1||All customers||Backlog||Predictable velocity|
|Service #2||All customers||Unpredictable||ASAP|
|Service #3||Select customers||Random, but somewhat predictable||7 days (fixed time)|
|Service #4||Customer within the company||Unpredictable||1-2 days|
So, there are four services delivered to three different types of customers, work arriving in different patterns, to be delivered against different expectations.
Something Changed At This Moment
The manager realized he was in the business of making four different pizza deliveries!
Now we can discuss how we allocate his group’s capacity to deliver these services, make relevant policies explicit, and so on. We can be free from dogmas like “protect the team from interruptions.” We can appreciate what those “annoying” Sales people do and give them a better service. We can simply start with what we do now and think about making our service delivery better and satisfying all our customers.
Before our meeting, the manager wondered if a kanban system would help his group. We hadn’t designed a kanban system yet, stepped to a whiteboard, put PostIts on it, or crisscrossed it with painter’s tape. All of this can follow in due time. But we did one very important thing.
The visual management part of a kanban system has to show how we deliver services. It is so much more effective if we understand what we deliver and the needs of those we deliver to.
Some Questions to Ask
- Whom are you delivering to? What? Why?
- Have you identified all services you deliver? How?
- What is the arrival pattern of requests for each service? Consider: regular intervals, random, chaotic, backlog, etc.
- What are the customer expectations on the service delivery?
- What is your group’s capability to deliver each service? How did you measure it?
- Do you provide different classes of service? Are any policies governing scheduling and sequencing of work explicit?
Love the illustration with the pizza delivery service. Understanding how many types of “pizza deliveries” need to be made is an important first step in figuring out how a team needs to work. Great post!