Training Exercise: Scaling Scrum
It’s been a while since I blogged, but I have a good excuse… I have been working hard co-training CSM (Certified ScrumMaster) and CSPO (Certified Scrum Product Owner) classes with Peter Hundermark. I am hoping to become a CST (Certified Scrum Trainer) myself, and the best way to learn is co-training with other trainers.
Over the last few weeks I had the pleasure of co-training with Gabrielle and Robert Benefield. During a discussion about sharing different training exercises I thought it would be great to blog about some of the exercises we use in training; to share them with a larger audience and get some feedback from how they work for other people.
I’ve already had great feedback on my estimation techniques post which explains a session you can run with teams to help them understand different estimation techniques. It seems likely that more training exercise posts would be helpful. The first topic is an exercise Gabby used to teach Scrum scaling patterns.
Setup: Split people into groups of between 3 to 6 people, ideally ensure each group has a flipchart, but if not maybe just give them a sheet from a flipchart so they can illustrate their answer.
Exercise 1: Present the scenario below (or one of the variations at the end) and ask the groups to spend 10 minutes discussing how they would structure the teams, and prepare a flipchart to illustrate.
Timing: Allow 10 minutes for teams to prep and 5 minutes per group for feedback. Note this can run much longer is you get stuck in the debates, so beware if you are trying to timebox to a short period.
- 1 Product Owner
- 2 Assistance Product Owners
- 1 ScrumMaster
- 13 Developers
- 2 Testers
- 2 DBAs
- 1 User Experience expert
- 1 Visual Designer
- 1 Interaction Designer
- 3 Product Backlogs
- 1 Product
Once everyone has had a chance to discuss in their teams, get each team to share how they structured the teams, and their reasoning behind it. Try not to pass judgement on any of the solutions until each team has presented. Often teams will find flaws in each others solutions and I tend to find learning is enhanced when people realise things for themselves rather than being told.
Depending on the results you get this fuels a great discussion about single vs multiple backlogs, if ScrumMasters and Product Owners can be shared between teams, and cross-function teams vs shared resource pools.
In our class we found most people wanted to group the designers and DBAs into a shared pool, rather than embedding these skills directly into the teams. I think this shows how we have been conditioned to think of people as being defined by their role, rather than understanding that individuals usually have multiple skills, and the ability to learn new skills. I’d be interested to hear other people’s findings if you run this exercise.
Exercise 2: After identifying the best pattern for splitting the teams, we asked each group to answer the following 4 questions to think about how multiple teams would impact standard Scrum meetings. We found people without experience with scaling did not come up with answers themselves. In future classes, I might change this to an interactive lecture.
Timing: Asking teams to answer these for themselves, and then share their ideas took a fair amount of time: 10 minutes of discussion, plus 5-10 minutes per question for feedback from each team. I think this could be done more quickly by removing the 10 minutes of discussion in groups, and simply asking individuals for their thoughts, and then explaining some good patterns.
1. How would you organise the daily Scrums?
A good pattern here is to hold them consecutively so that team members are able to attend each others daily scrums if they want to know what the other team is up to.
2. How long should the sprints be, and would you stagger the sprints or have them end at the same time?
Since scaling adds complexity, shorter sprints are probably better as you find out sooner if you have problems. A good pattern is to synchronise the sprints, since that enables teams to better manage releasing software from a single branch, and better manage dependencies between teams.
3. How would you get communication between teams working?
This is where you can introduce a Scrum of Scrums concept. Good patterns for Scrum of Scrums are to hold them after the daily scrums for all the teams, either daily, or a less frequent basis e.g. 3 times a week. Teams should each send a representative from the team, and rotate this amongst team members. ScrumMasters from each team can also attend, but it is better if the meeting includes team members who know the details, rather than just the ScrumMasters acting as messengers. Finally these meetings can take a little longer than daily scrums as they are problem solving meetings not just synchronisation meetings.
4. How would you run sprint planning, and sprint reviews?
Here a good pattern is to have a joint sprint planning 1 meeting with all the teams, and allow the teams to hold sprint planning 2 on their own, but close to the other teams in case they need to talk, and a joint sprint review. This minimizes the number of meetings stakeholders have to attend; helps ensure teams are collaborating across team boundaries where necessary, and helps teams understand what other teams are working on.
Here are a few other ideas we haven’t tried out yet, but will do in the next few classes and hopefully share how they work.
- A scenario with multiple products and lots of really small teams (1 to 2 people per team)
- A scenario with distributed teams
I think you could use this exercise either in a classroom setting when doing Scrum Training, or to help a team struggling with how to scale to understand some of the concepts. If you run this with your teams, or classes we’d love to hear how it went. Please add a comment about your experience.