STEP 1: FORM TEAMS
The group’s manager creates a roster template on the wall. The roster template includes a column for each team and empty slots for team members. Rows indicate the desired mix of skills on each team: programmers, testers, UX specialists, DBAs, Op’s, etc.
Everyone in the group writes their name on a Post-It.
The manager explains the goal to the team. Group members fill the empty roster slots with their names. Talking and collaborating are encouraged! When all roster spots are filled, teams formation is complete.
Though not officially part of the scaling pattern, for great teams in just a few days, send them to a Core Protocols one-day workshop or five-day BootCamp.
STEP 2: SCRUM!
Here are recipes for your scaled Scrum events:
Sprint: All teams’ Sprints are synchronized, starting and ending at the same time.
Part 1—What: The whole group gathers in their shared work area. The PO re-acquaints the group with the contents of the Product Backlog. Each Development Team selects the subset of Product Backlog Items (PBIs) that they think they can get Done during the sprint.
Part 2—How: Each Development Team creates their individual Sprint Backlog. They carefully note dependencies and other collaboration needs with their cousin Dev Teams.
Part 3—Align: The whole group gathers again. Each Dev Team shares their Sprint Backlog with the group. Dev Teams share collaboration needs. They inspect and adapt, adjusting as needed. They agree on their Sprint Goal. (Did you notice the Diverge-Converge pattern? You’ll see it again in the Daily Scrum and Sprint Retrospective.)
Each team holds its own Daily Scrum. Daily Scrums are staggered so the SM and PO can attend all of them.
Daily Scrum of Scrums: Representatives of each Dev Team meet to share their progress toward their individual and joint Sprint Goal. They inspect and adapt and adjust their plans.
The group meets all together, along with stakeholders invited by the PO, for their Sprint Review.
Part 1—Teams: Each team holds their own Sprint Retrospective. They create a concrete plan to improve their team during the next sprint. They also identify ideas for improving the whole group. This meeting lasts about one hour.
Part 2—Group: The whole group meets to inspect and adapt as a team-of-teams. They create a concrete plan to improve the whole group during the next sprint.
Product Backlog Refinement
Refinement with volunteer leaders: The PO and volunteer leaders from the group meet to refine the Product Backlog regularly, usually 1-2 times per sprint. The purpose of this meeting is to get the backlog more Ready for the whole group, so we don’t waste people’s time with PBIs that aren’t Ready enough for the group to estimate together. For great collaboration, the size of this volunteer group is around 8 people. (“More than eight, no collaborate.” -Luke Hohmann) This subgroup may provide *initial* estimates for backlog items, to help the PO with initial forecasting. These estimates are not final, though, because estimating is the Development Team’s responsibility. Consider not sharing these estimates with the members of the Dev Team to prevent anchoring. Consider using this Product Backlog Refinement Workshop.
Refinement with whole group: The whole group convenes to refine the Product Backlog. The purpose of this meeting is to get the Product Backlog ready, with 1-2 sprints worth of PBIs totally Ready, and up to 6 months of backlog estimated—with the whole Development Team estimating backlog items together.
Scaling to 500 people
Each group is around 40 people. The pattern scales horizontally, up to 10 Product Backlogs and 40 Scrum Teams. For every five POs, there is a PO Manager. When there are two PO Managers, there is a PO Director above them.
Scrum Masters form a community of practice, perhaps with a manager handling their career development and HR needs. Programmers, testers, and other specialists do the same.
All together there are around 500 people in the business unit, including managers and support staff.