- The Solutions in This Chapter
- Challenges to Scaling
- Should You Scale Up?
- Scaling the Wrong Process
- The MAGE Framework
- The Product Backlog
- Team Organization
- Product Ownership
- Additional Roles
- Managing Dependencies
- Distributed and Dispersed Development
- What Good Looks Like
- Additional Reading
For large games, Releases establish a cadence that
Enable distant stakeholders to gather and discuss the progress
Enable teams to realign around upcoming Release goals
Provide regular checks on debt and the “shippability” of the game itself
As teams and studios improve, this cadence improves to the point where these things can occur far more frequently than once a release.
Chapter 9, “Agile Release Planning” describes Release Planning as
Establishing Big Hairy Audacious Goals (BHAGs) for the Release in an initial planning session
Capturing those goals in epic stories
Breaking out upcoming Sprint Goals from those epics (the Release plan) in regular Backlog refinement/Release Planning sessions
Larger teams use the same approach, but with the following changes:
The BHAGs and epic creation are not created by the entire team, but a subset of the team consisting of leads, stakeholders, and the Product Owner group.
The BHAGs are presented to the entire game group.
The breakout of the Release plan occurs at the team level.
These changes still allow each team to participate in the creation of the Release plan at the team level, which is great for building and evolving a shared vision.
Rolling Out the Release Plan
On larger projects, having the entire project staff attend the Release Planning meeting is sometimes impractical. In this case, only the Product Owner, domain experts, and discipline leads attend.
After Release Planning, the Product Owner presents, or rolls out, the Release plan to the entire project staff. The owner describes the BHAGs and Release plan and answers any questions raised. The project staff is then given the opportunity to organize themselves into Scrum teams that would best achieve the initial Sprint Goals in the plan.
The creation and conversation about the Release plan is an excellent place to examine the best team formations for achieving release goals. Depending on what level of self-organization the team practices, one of the following occurs:
Managers make team assignments from the available staff.
Senior team members have conversations about team makeup and recruit members of the team.
The entire game’s staff gathers and, after the Release is described, decides team formation on their own.
Between Sprints, teams can swap members as needed. Although keeping good teams together is best, you have to acknowledge reality. If you don’t plan any animation work in the next Sprint, let your animator help a team that does!
Updating the Release Plan
Large teams will often have two meetings to update the Release plan after each Sprint. The first meeting is among the members of the group that established the BHAGs to review the general direction of the game’s progress and any reprioritizations or respond to dependencies that have arisen.
The second Release Planning session is among the team and its Product Owner to refine their portion of the Release plan.
Using Project Boards
On larger teams, having a “big picture” view of the current progress is a useful tool. The project board shown in Figure 21.11 is an example of such a tool.
Figure 21.11 A project board
The board shows a 6- to 12-week Release plan, which consists of epic Product Backlog Items (PBIs) being worked on by three teams. Each team area shows the epics each team is currently working on, but not the task details. Each team manages that level of detail on its own board. The board also shows the current progress of the features going through acceptance testing and the ones deployed in the current Release.
A project board can be used to gather all teams working on the game or for a Scrum-of-Scrums meeting at whatever frequency they need to.