- 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
- Releases
- Sprints
- Managing Dependencies
- Distributed and Dispersed Development
- What Good Looks Like
- Summary
- Additional Reading
This chapter is from the book
This chapter is from the book
This chapter is from the book
Releases
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.
Release Planning
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.
A GLOBAL GAME RELEASE STORY
CCP Games, the developer and publisher of EVE Online, was founded in 1997 with development split between studios in Reykjavík, Iceland; Atlanta, United States; and Shanghai, China. It has grown to have more than 400 employees and to host more than 300,000 active subscribers in a single online world.
In the fall of 2008, CCP undertook the development of its tenth expansion pack called Apocrypha. Apocrypha was the most ambitious expansion of the EVE universe. It added major technical features and significantly extended the size of the EVE world. The goal of the company was to release the expansion pack within six months following a four-month development cycle (see Figure 21.9).
)
Figure 21.9 The Apocrypha timeline
This ambitious goal required CCP’s worldwide development studios to work in parallel. Features and content developed simultaneously across three continents had to come together to achieve their goal seamlessly. Usually, this would be the introduction to a disaster story, but CCP pulled it off. CCP is a longtime adopter of Agile methods, specifically Scrum.
In the case of Apocrypha, with more than 120 developers in 13 Scrum teams spread across three continents, nine Product Owners were required. These Product Owners took their direction for the game from a project management group in Iceland.
Release Planning
The stakeholders identified two release cycles of development to release the expansion pack in March 2009. Ideally, Release Planning should gather every developer, but it was nearly impossible to collect 120 people from around the world in one location, so CCP had to create some innovative practices to perform Release Planning.
Apocrypha Release Planning meetings took place over a single 12-hour period. A high-definition video conferencing network facilitated this meeting and allowed every developer to take part.
Because most of the development staff, including the project management group, was in Reykjavík, the meeting was focused there. It started at 9 a.m. Because of the time difference, it was far too early for the developers in Atlanta to attend. It was the end of the day for the developers in Shanghai, so they and the Reykjavík group met first. Hours later, the Shanghai team would leave, and the Atlanta team would join to discuss the Release (see Figure 21.10).
){kind=link}
Figure 21.10 Overlapping meeting times
You can see a time-lapse video of this fantastic meeting in Reykjavík on YouTube.3
It’s important to note that the time zone limitations and the limitations of video conferencing allowed only two teams to meet at one time. In this case, Atlanta and Shanghai could not attend together. To avoid potential problems, two developers from Shanghai flew to Reykjavík to participate at the core meeting and to represent the Shanghai teams.
Each pair of locations would discuss the Release goals and begin breaking them down into smaller goals that were reasonably sized to fit into a Sprint. The conferencing network enabled multiple simultaneous meetings to occur. This was necessary because many questions raised during this process required a great deal of lively conversation among the entire staff or individual teams.
The goal of the Release Planning meeting was to generate a set of potential Sprint Goals for each of the 13 teams that would fulfill the Release BHAGs. This wouldn’t be the last time that the teams would communicate. Daily issues were discussed, and a build of the game was demonstrated every two weeks at the Sprint Review. Changes to the Release plan were made every Sprint to adjust for the realities of development.
After two releases, Apocrypha was ready to do final testing and polishing, and on March 10, 2009, it shipped on schedule.
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.
Forming Teams
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.