Scrumalogies: Analogies for Scrum - Part Two
Musings from Om Hemant Patel and Rachel Schumacher
Have you ever tried to explain how a Scrum concept works in a way that people can relate with? We find the easiest way to simply explain scrum is to use analogies that fit into everyone’s everyday knowledge. Shopping, biking, dining, cooking – who knew they were Scrum? We gathered together some genius analogies to draw parallels between real life and the Scrum framework. This is a continuation of analogies from Part One.
Producing working software: Horizontal versus Vertical Slicing - Having your cake and Edith too!
Team determines “how” Let the team determine “How” - How Shiny Are Your Shoes?
Small vs large teams: Rightsize your teams for maximum productivity - Too many cooks in the kitchen
What is Scrum? The Why and What of Scrum - Scrumboni - il Restauranté
Horizontal versus Vertical Slicing
Having your cake and Edith too!
Are your teams doing requirements stories, development stories and then testing ones? This is mini-waterfall within a sprint.
It’s your birthday! We got a multi-layered rainbow cake for you, topped with delicious icing!
How do you eat your cake? Do you separate out each layer horizontally? No. You cut a slice vertically to get all the layers from top to bottom. This is how the team should be organizing their work. Vertical slicing helps deliver working software at the end of each sprint. That includes development, unit testing, regression testing, documentation, and so on.
The Solution: Ensure that all the work is structured in a way that the piece cut from a large feature includes all efforts needed to release the development. E.g.: the epic/feature includes 100 items to develop, make the user stories 10 items that include development and testing - Vertical Slicing allows delivery of working software and therefore, business value.
Let the team determine “How”
How Shiny Are Your Shoes?
Imagine you’re walking through an airport or a train station. You look at your shoes and decide they could use a shine. So, you stop at a shoe stand and have your shoes shined.
Do you count how many left strokes the shoe shiner performs? Right strokes? Or whether he uses a cloth to polish your shoes or a brush? Or what order he uses them in?
No, of course not. All you care about is that the shoes are shiny when he’s done. He’s more likely to do a great job if left alone to do it. He is the expert, so trust him and do not dictate the how.
The Solution: Do not dictate to the dev team how they do their work. Collaborate with them and trust them to deliver a finished work at the end of the sprint.
Right-size your teams for maximum productivity
Too many cooks in the kitchen
Imagine a galley kitchen with too many cooks. They’d be stepping on each others’ toes before long. Amid the ensuing chaos, food orders will be mixed up, communication will suffer and most certainly the quality of the food will too.
On the other hand, having too few cooks will lead to longer delivery times and unsatisfied customers.
Right-sizing scrum teams should land you at a sweet-spot, somewhere around 7 ±2. Mike Cohn says that you should be able to feed your team with1 or 2 pizzas. If not, then rightsize your team. Most of the time, the problem we find is that there are too many cooks in the kitchen. Fix that for a smooth, sustainable pace of delivery.
The Solution: Create a cross functional team that is right-sized with all the skill sets necessary to complete user stories to the meaning of Done. An ideal team has members that can fill in for one another - their skill sets are ambidextrous or T-shaped.
The Why and What of Scrum
Scrumboni - il Restauranté
I think of Scrum as if it is a restaurant experience. In this analogy, the Product Owner takes on the role of the waiter. The waiter (PO) is well-versed in the food items and in some cases can help the business decide what to order. The PO then relays the orders to the chefs (or developers in this scenario) and they begin to cook the meal. It would be considered bad taste for the customer to go into the kitchen and disrupt the chefs by asking for additional items while they are cooking. So the business waits a bit until that food course is ready (sprint review), and gives feedback on the dishes the chefs present. At this point, they add new desires (user stories) and thoughts.
The Scrum Master is the Maître d’ in this scenario. The Scrum Master facilitates the business meetings and ensures that the processes are followed to the restaurant’s standards (Scrum). The Scrum Master is always looking for ways to improve the restaurant’s processes and ways to help the chefs with problems that occur. This is important so that the chefs focus solely on creating the food that was ordered.
The backlog itself is a menu arranged to fit the customer’s needs. It keeps in mind any dependencies (the chef can’t cook the eggs if the chicken hasn’t laid them yet!) and is prioritized with their most important needs at the top. The business chooses from the menu based upon what they crave the most while keeping in mind their budget and time constraints. They put their top choices in the order of what they desire most, followed by things that would be nice to have if they have the appetite and time to enjoy them.
Scrum breaks the project into sprints and does planning at each one of these sprints. This is done so the project can adapt to emerging, new desires. The food (product) is brought out in courses (sprint review). After a sprint, as the business enjoys the product, they communicate with the restaurant staff their thoughts on that particular course during the sprint review. This would be as if the entire staff including the chefs came to the table to present the food and gather feedback- great restaurant, right?! Then they make decisions on the best way to adapt the product to the newly discovered tastes (Sprint Planning).
The Solution: The Scrum method works really well when the customer does not know exactly what they are hungry for, or there are a lot of unknowns in what exactly they want. The mass movement to the Scrum framework is due to Scrum allowing for an adaptable and transparent plan. Accountability is shared throughout the project creating an atmosphere of communication and collaboration. As new discoveries are made and previous unknowns become clear, the Scrum plan is simply adapted to accommodate the new desires. -Bon Appetit!
Make sure to check out Scrumalogies - Analogies for Scrum – Part One