- 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
Managing Dependencies
Interteam dependencies inside a Sprint can prevent teams from achieving their goals. Consider a team whose Sprint Goal is to implement a wall-climbing mechanic, but it has to rely on another team to provide the animation. Because of the separation of teams and goals, the mechanic team will likely hand off its work to the animation team near the end of the Sprint rather than collaborating daily. At best, this limits the number of iterations that can occur with the mechanic. At worst, the goals that the animation team has for its Sprint might prevent it from handing back the wall-climbing animation in time.
When projects begin using Scrum, these dependencies are quite common, and they are the source of many impediments and failures to achieve Sprint Goals. Over time, teams change their membership to reduce dependencies and establish other practices to prevent their impact.
The goal isn’t to find ways to utilize everyone’s time fully. To respond to work that couldn’t be planned for, there has to be a certain amount of “slack” available. Ultimately this slack, which allows everyone to respond quickly to problems, is more effective than attempting to plan it all away.
Team Formation
Changing membership to create more self-contained teams is a valuable solution. If the team implementing a new mechanic needs full-time animation work throughout the Sprint, having an animator join them is best.
In many cases, there isn’t enough work to justify a specialist joining one team full time. In these situations, teams can share specialists within a Sprint or trade them between Sprints. Doing this requires a bit more planning and foresight to avoid overlapping demands for a specialist’s time. There are two places where this is done: at Release Planning meetings and Backlog refinement meetings.
Release Planning
In Release Planning, teams identify potential Sprint Goals for the next several Sprints. Using these goals, they identify Sprints where part-time specialists or a concentration of disciplines (such as a bunch of texture artists) might be needed. Often these will uncover conflicting needs among teams. The best way to resolve these is to raise or lower the priorities of PBIs creating the conflicts. For example, if two teams require the same FX artist full time during the same Sprint, then the Product Owner changes the priority of one of the PBIs requiring FX work enough to shift the Sprint for one team to remove the overlap.
Problems occur with little warning on a day-to-day basis that require a specialist on another team to help out. For example, one of our projects had one UI scripter who could implement UI changes rapidly. Almost every day he was requested to help another team for an hour or so. Because of the demand for his time, his team would allow him to commit to only half the available hours during a Sprint.
Requests like these can be handled in the Scrum-of-Scrums meeting described earlier. Whether or not a specialist can help another team within a Sprint lies with the current team to which the specialist belongs.
Team Dependency Management
Although a goal in an Agile transformation is to eliminate all dependencies, some will slip through from time to time. Relying on teams to identify upcoming dependencies in Sprint Planning and even the Daily Scrum can mitigate many of those that emerge.
I’ve seen two tools used by teams to help visualize and track emergent dependencies:
Project Board Lines: If the teams are using a project board to visualize the Release plan, connecting dependent PBIs with string on the board can highlight dependencies. I’ve even seen teams use colored yarn to identify the urgency of a dependency.
Dependency Sheet: This is a single spreadsheet that is updated by teams and posted in the area the Scrum-of-Scrums meeting occurs. Each row identifies a dependency and a column or color rates its urgency. The list is discussed during the Scrum of Scrums (Kniberg, Ivarsson, 2012).
Reducing Expert Dependencies
Most project managers are afraid of a proverbial bus that’s seeking to run over one of their expert developers. These developers are the ones who are the most productive or are the only ones who know how a part of the code works.
These experts are indeed hard to replace, but they are often bottlenecks that teams and games depend on. One useful practice to is apprentice someone to work with them and learn how to offload some of the less challenging parts of their work or to deal with issues that would frequently interrupt the expert.