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:

  1. Imagine the perfect business from the customer’perspective.
  2. 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.

Making Work Visible

For years almost all of the problems we’ve had at the restaurant have resulted from rumour and gossip.

We don’t have many strict rules, but one of them is that if you want to discuss another team member unless it is to say how well they are doing, you have to be willing to repeat what you are saying with that person present. If you are not, then we don’t want to hear it.

People discussing remuneration has been one of the recurring issues.

I’ve been toying with the idea of putting a list on the wall showing everyone’s remuneration with a note explaining why there is differentiation in the rates. each time I’ve discussed this with team members or professionals I was told this was a bad idea.

After researching what great Scrum companies do and listening to Jeff Sutherland and talking to Joe Justice, I’ve decided to take it a step further.

Here’s what I have decided to do:

My first list of making work visible

  1. Share my vision openly with the world through this site and through a vision board which will be a series of epics written on post-it notes and put on the wall at the restaurant. This will be in a prominent place where customers and team members will be able to see it. I will write these in the form of a Product Backlog Story, “As a customer I want ………….. so that …………….”, If I can’t put it into the perspective of a) a customer or b) a team member, I probably won’t include it.
  2. I will make our accounts public and encourage the team to read them and teach them how to understand what the numbers mean.
  3. Publish all salaries so all can see.
  4. I had a thought yesterday about creating an ascending remuneration package where every team member is trained to do every job in the restaurant. it will lead to an ultimate qualification called “Restaurant Owner” where the team member will have enough information to open and run a restaurant from scratch. when they reach that point they will be entitled to a full share of the profits and before that, they will be entitled to a scaled down amount dependant on how much knowledge they have of the various roles. There’s something great that comes out of knowing all of the jobs in your business, it enables you to make better decisions and it enables you to do any of the jobs you undertake better.