Author: Riccardo Mariti

Riccardo Mariti is a visionary entrepreneur, real estate expert, and negotiation and mediation specialist. Renowned for creating the world's first Agile restaurant, Riccardo has over 30 years of experience pioneering innovative approaches to business transformation across hospitality, real estate, agriculture and banking. His expertise in negotiation and conflict resolution has helped organizations unlock their potential, blending creativity, adaptability, and operational excellence to achieve remarkable results.

How can I translate the Agile Software Manifesto and 12 Principles to Apply to a Restaurant?

Manifesto for Agile Software Development	Comments
Individuals and interactions over processes and tools	Yes, self-explanatory
Working software over comprehensive documentation	If we define “working software” as something that is of real use to the customer, something that has value, that the customer is happy to pay for, we are getting closer to being able to find a definition that would translate to a restaurant – so we could say “food, drink, ambiance, and service that they need and want, once they experience it” I add the last part because of ‘Humphrey’s Law’ which says in software dev. that users do not know what they want until they see working software. Often end users say, “I’ll Know It When I See It” (IKIWISI). I think the same is with most things so the importance of testing on the customer as often as possible, the “inspect and adapt cycle” where we have iterations or evolutions of products all based on testing and feedback direct with the end users.
Customer collaboration over contract negotiation	OK, I covered that above, but how does the contract negotiation part relate to a restaurant? Well, it would apply if we were arranging a wedding lunch for a client, rather than trying to lock them into an agreement, to be constantly evolving the event so as to maximize the client’s satisfaction. In a single service, it’s about getting constant feedback from the customer and adjusting the service based on their needs in the moment. Also allowing and encouraging customers to ask for changes to regular menu items. “I’d like the salad with the dressing on the side” or “I’d like extra green vegetables instead of the potatoes” etc.
Responding to change over following a plan	This is such a fundamental part of working in the hospitality industry, we have a plan at the start of a service or party, but needs change constantly, so we have to respond to what is happening at the moment, as Eisenhower said, “In preparing for battle, I have always found that *plans are useless but planning is indispensable.” and “Plans* *are worthless, but planning is everything”*


12 Principles behind the Agile Manifesto
1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.	OK, in a lunch or dinner service, this means to serve quickly and respond to what the customer wants, to anticipate in each moment and get things moving quickly. On a longer-term perspective, we can think about product development. Things like a) seasonal changes b) health trends c) product improvements whether to do with food, drink, service, ambiance. As an ‘agile’ company we are attempting “Kaizen” – constant and never-ending improvement in every aspect of what we do. These improvements should happen often and be in line with what the customers need and want and be developed by the team by pulling from a prioritized backlog.
2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.	Self-explanatory
3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.	See point 1) above
4) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.	Self-explanatory
5) Business people and developers must work together daily throughout the project.	Self-explanatory – in our business ‘developers’ are chefs and front of house team members including receptionists and home-delivery operators – cross-functional teams, and ‘business people’ are the shareholders, suppliers, legal professionals, the executive board and any management.
6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.	Yes. Pre-shift meetings and hands-on training etc. Pairing, and Scrum of Scrums (sharing impediments) and Meta Scrum (sharing and dividing up the vision).
7) Working software is the primary measure of progress.	What is our version of ‘working software’? I suppose it’s great quality products we can sell to customers.
8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.	Self-explanatory – let’s make sure our team members have enough time off to enjoy life!
9) Continuous attention to technical excellence and good design enhances agility.	Self-explanatory
10) Simplicity–the art of maximizing the amount of work not done–is essential.	Self-explanatory – KISS – keep it super simple, but as Einstein said, “everything must be made as simple as possible, not simpler”
11) The best architectures, requirements, and designs emerge from self-organizing teams.	Self-explanatory – the people doing the work know best how to do it and let the teams self-organize to create harmonious teams – some combinations of team members are better than others
12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.	Self-explanatory – This is the key – the Kaizen, the way we become great.

The Starting Point

Keith Cunningham said, “what would your business look like if you never lost a customer”.

For the last few years, I’ve thought about it a lot, I thought about what the business would look like, but comparing it to now, how it is.

I think I missed the point of the question. It came to me this morning what would my business look like if we had never lost a customer, what type of business would it have to have been and what would it look like now? What would the business have had to look like in order to have made that happen?

What would the business have had to look like in order to have made that happen (that we had never lost a customer)?

This is such a great question and it forces us to do two things:

Imagine the perfect business from the customer’perspective.
Imagine what things would have to have looked like at those moments when things have gone wrong in the past for them a) not to have gone wrong in the first place or b) if things had gone wrong, for the situation to have been resolved so well after they went wrong that we turned it around and showed how much we cared and won a raving fan?

This is where we can start building a list of potential things to work on, it’s what is called the Product Backlog (PB) in Scrum.

How to handle distributed teams in a restaurant

One of the first observations made by Jeff Sutherland is that stable teams perform better and faster.

After studying 5000 teams at MIT the best performing teams are an average size of 4.6 members.

It makes sense and from my experience putting teams together over the past 20+ years it feels right.

So how to do it?

When I went to ScrumInc’s & Joe Justice’s training “Agile Hardware development, April 20-21 2017” in Stockholm Sweden I had so many questions

“What does a team look like when it distributed by time?” as in shift work

“How long should my sprints be?” (I wanted them to be 1 week, not 2 weeks)

Question: “How do you handle mundane work that gets done day after day?”

Answer: Create a backlog for every item and then as the team gets more experienced, the backlog gets briefer until it becomes “build car”. But, you still keep the original backlog and update it when you make changes so when you have a new team member you give the all the items.

I like this and it seems sane, but in my experience, I still like my team to use an opening checklist because when they don’t, they miss important things, even simple things like changing till roll or resetting the computer with the new stock of dishes available so the till may say that there is no Tiramisu, because we ran out last night, but there are 10 in the fridge just made fresh this morning.

I mean, all teams have a DoD (Definition of Done) and a DoR (Definition of Ready) and that’s written down in a prescriptive way.

Read the Checklist Manifesto and see how a simple 5 point checklist for doctors saves 1000’s of lives every day.

Joe Justice said that our sprints could be each shift, so we would have two frameworks; one is the service (breakfast, lunch or dinner) and the other is product development of food, drink, and service. So we have a service team and then we have a product development team. Service teams have bi-daily sprints and they are like ‘factory workers’ making the product and then we have the product development team who have weekly sprints. these guys will also deal with developing the areas we diversify into like weddings etc and when we introduce these new areas for development we may morph into more specialized teams.

So we have a ‘service team’ and then we have a ‘product development team’. Service teams have bi-daily sprints and they are like ‘factory workers’ making the product and then we have the product development team who have weekly sprints. these guys will also deal with developing the areas we diversify into like weddings etc and when we introduce these new areas for development we may morph into more specialized teams.

Service teams have bi-daily sprints and they are like ‘factory workers’ making the product and then we have the product development team who have weekly sprints. These guys will also deal with developing the areas we diversify into like weddings etc. and when we introduce these new areas for development we may morph into more specialized teams.

Manifesto for Agile Software Development

Comments