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.

Demo or Die -The Sprint Review – Joe Justice’s Deep Dive into a Simple Concept

The benefit of coaching comes from small distinctions that can have a profound effect on your understanding.

I really understood this when Joe Justice asked two questions after we watched the video clip above.

The video is under 3 minutes long and I had watched it several times in my preparation for the training. I got the idea, but I missed two very important points.

Joe asked, “What two things did you notice about this?” Silence in the room. “OK, one, how many demos did they do?”  Continue reading “Demo or Die -The Sprint Review – Joe Justice’s Deep Dive into a Simple Concept”