[I’m grateful to be able to include a new post by Bea Leiderman, who is an instructional technology coach at Goochland County Public Schools in Goochland, Virginia. Bea has been working with Scrum at her school and she and her colleagues are having incredible success with it!]

Photo by Brücke-Osteuropa (Own work) [CC0], via Wikimedia Commons

Over the last year, our team has adapted the Scrum framework to help our students work through class projects. In the classrooms where Scrum is used regularly, students have a deep understanding of what it means to collaborate and be part of a learning community. Teachers can plan complex projects, confident that students will rise to the challenge and present outstanding products to their classmates at the end of a few weeks. To us, Scrum makes perfect sense. And it is not too hard to implement with some guidance and coaching. However, getting started on your own can be tough, especially because most of us have never tried anything like it.

When talking about Scrum, we bandy about lots of unusual words to refer to the roles, artifacts, and ceremonies involved. Even those three make Scrum sound like a strange cult. Instead of suggesting books and articles, It might be useful to walk through an everyday, non-educational project in Scrum to give interested teachers a frame of reference. It might also be a good way to introduce Scrum to students in classrooms.

Let’s make a vegetable soup following an everyday workflow (the procedure we use to accomplish things in Scrum). Everyone knows how to make soup, right? What are the steps?

1. Gather all your ingredients
2. Clean, peel, and chop all veggies and maybe some meat
3. Cook all ingredients in a pot of water with salt and seasonings
4. Serve and eat

Generally, that’s how soup works. Of course, the stuff I put in my vegetable soup might not be exactly the same that you put in yours. How long the process takes depends on how many different ingredients I have to prepare before adding them to the soup. If I had to plan this down to the smallest detail, I’d have to expand the above steps to include everything.

Let’s see what a detailed plan for my soup might look like. I have to include every step to make sure I can give my guests a good idea of when we will sit down to eat our soup. Notice that these steps have a well-defined beginning and an end, and usually, will be easily managed in a predictable amount of time.

1. Decide on a list of ingredients
2. Make a shopping list based on what you have on hand
3. Go to the store
4. Select carrots
5. Select onions
6. Select celery
7. Select potatoes
8. Select a cut of beef
9. Pick up some kosher salt
10. Pay
11. Return home
12. Start water boiling in a large pot
13. Add salt
14. Trim and cube beef
15. Wash, peel, and chop onions
16. Wash, peel, and chop potatoes
17. Wash, trim, and chop celery
18. Wash, core, and chop peppers
19. Wash, trim, and chop green beans
20. Wash, slice yellow squash
21. Peel, chop garlic cloves
22. Thaw a bag of corn kernels in the microwave
23. Add ingredients to the pot
24. Add two bay leaves to pot
25. Add peppercorns to pot
26. Wash cooking utensils (cutting board, knives, peelers bowls)
27. Taste the soup and adjust salt
28. Set table
29. Slice and toast bread
30. Arrange toasted bread in a basket
31. Serve soup

Mmm…The soup turned out really good. Too bad it took the whole day to make. Next time, I’ll try this with a team of friends (or maybe I’ll just coerce my children) and I will use a Scrum approach to make sure we can work together well. Let’s see how Scrum would help us get things done with three team members.

First we develop a user story:

We are going to make a delicious vegetable soup with all-fresh ingredients that we can serve for lunch today.

A user story can be very short, or it can be long and complex. For our soup, this one sentence is perfect. The user story sets forth the nature of the product and the standard of quality that will meet the purpose of the project. The soup will be delicious and will be prepared with fresh ingredients — no canned or frozen veggies for us if we can avoid it. We have also set forth a time limit for the execution of the project. If we take too long, our soup will not be lunch but dinner.

I’m going to leave the above as my plan and work from there. These 31 steps are prioritized so the project can be executed in an order that makes sense. The steps constitute our backlog. Each task is a story point, a task that is necessary for the successful completion of the project as described by the user story. I’m going to break these 31 story points into three sprints — smaller sections that make up my overall workflow.

• Tasks 1–11 Planning
• Tasks 12–25 Making
• Tasks 26–31 Sharing

Let’s look at the first part of the list. Notice how items 2–11 depend on our list of ingredients and what we have on hand. The backlog likely did not have any of these items on it until after we, as a team, decided what to include in the soup and looked at what we had on hand and what was missing. If we had found everything in the refrigerator or pantry, we would not have groomed the backlog to include the trip to the store and the items to purchase.

Now that we’ve made our choices and added the missing ingredients, let’s go to the store with our shopping list. We will start with a standup meeting in the parking lot.

• What have we done so far? We made a list of ingredients, a shopping list, and we drove to the store.
• What will we do now? We will each choose two ingredients on the list to get and meet back at the cash register.
• Does anyone have any questions or problems? “Yes, I don’t know where to find the kosher salt.” I either trade this task with someone who does, or I get help in finding the salt.

When we meet at the cash register, we have another standup meeting.

• What did we do here? We got ingredients.
• Are they of a quality we all like? The team should ensure that the vegetables are all fresh and meet the quality standard set by the members.
• When everyone agrees we are done at the store, we pay and go home.

At home, we might want to have another standup meeting to start our second sprint. We might divide the cleaning, peeling, and chopping based on personal preference and skill. We might choose to groom the backlog once again and add some herbs to the ingredients. And luckily, we are a 1:1 cutting board and knife kitchen. We can work in parallel rather than in series. What might have taken a sole cook hours could take three cooks a third of the time or less. Awesome!!

As we are all working on our selected veggie story points, we have to be in constant communication to make sure our work meets our collective standard of quality. Are the potatoes chopped in small enough cubes? Are the carrots sliced thin enough? Should there be a bit more garlic? Does anyone need to have their knife sharpened? Are we keeping an eye on the pot to make sure it does not boil over? If I’m finished with my veggies, may I help someone else with theirs? We are working independently on our tasks, but we are working toward a common goal.

Even though the soup is being made in a single day during a single work session, we still might need to touch base before continuing. We could structure this particular sprint to have a standup meeting before adding the ingredients to the boiling water. After all, once the ingredients are in the boiling water, it will be too late to chop anything finer or to wash something that might look like it needs cleaning. This is the time to make corrections. In this case, we are alone in the kitchen. We don’t have a product owner outside the team whom we need to sign off on our soup — we, ourselves, are the owners of this project. Still, our progress has to meet our quality standard and our definition of done.

Since this is a critical point in the soup-making process, we might want to have a product demo. If we were making this soup for anyone other than ourselves, our product owner would listen to what we had to say about the soup so far and examine the results. The team would answer questions, listen to feedback, and plan on correcting anything that was not to the product owner’s liking. Based on the feedback and required changes, we might need to groom our backlog to include missing ingredients or eliminate something that does not fit with the project.

What? Eliminate something? But we already washed, peeled, and chopped the yellow squash!!

I know, I know… But we’ve realized that one of our guests is allergic to yellow squash. Keeping it in our soup would be a terrible mistake. It’s better to have noticed this small failure now, before we serve the soup. Reviewing the project often, identifying failure, and learning from it is a crucial part of Scrum. FLeRD will help us do better next time: Fail, Learn, Rethink, Do. We failed to ask if anyone was allergic to the ingredients. Now we have learned from our mistake. We rethink our process and add a step to check for allergies in future when we are making our list of ingredients. And that’s how we will do it next time we make soup or any other recipe.

Now we move to the final sprint while the soup is cooking. We clean up, set the table, and get some bread ready. While this seems like a slow, easy sprint, it is crucial. We are getting ready to unveil our finished product. We must set the stage, know what we will say if anyone has questions, and be ready to accept feedback from our guests. We must also be ready to give and take feedback from our teammates.

Let’s have a final standup meeting.

• What have we done so far? We have prepared a lovely soup.
• What do we have left to do? We have to serve the soup. Let me grab the ladle from the kitchen before we sit down.
• Does anyone have any final questions or problems? Nope, I think we’re okay.
• Do we agree that the soup is done and ready to serve? Yes! Let’s eat!

How did the process go? I did not add the final kitchen cleanup to my backlog, but while we dry and put away the dishes, the team should have a retrospective. We must examine how the project went, from beginning to end. We must decide, from planning to serving, what went well and what could use some improvement. Reflecting upon the process and examining the results objectively is a good way to ensure future improvements.

And that’s Scrum!

With this point of reference for the artifacts and ceremonies of Scrum, we can bring this process back into the classroom. Of course, we don’t usually make soup as a classroom project, but the essential steps for many classroom projects line up well with this example: Planning, gathering resources, executing, presenting, and reflecting. The essential elements of Scrum keep the project from ever going off the rails — and it empowers teams working in the classroom to accomplish complex tasks with ease and with a minimum of external intervention or oversight. The process helps people accomplish what they want to do.

Because the structure demands constant communication and prompt resolution of any conflict or difficulty, it also helps people learn to work productively together — so this is about more than just accomplishing projects.

• All the work is explicitly enumerated in the backlog to help all members of the team know what needs to be done.
• The team grooms the backlog based on discussions during standup meetings and on feedback from the teacher.
• All completed story points must be reviewed by the team to ensure an agreed-upon standard of quality for the work.
• Standup meetings encourage team members to communicate and resolve conflicts
• The teacher, as the product owner, calls for a product demo to give formal feedback while the project is in progress.

Scrum may have its origins in the software development industry, but the idea of working towards a common goal without disruptive conflict applies to any context and any situation.

If you want a recipe for teaching students to work in teams and develop important collaborative skills, you should definitely try Scrum soup!