Agile Game Development With Scrum: Teams
August 26, 2010 Page 2 of 8
When the various documents are written and schedules are created, the priorities of each discipline's schedules don't often mesh. Programmers often read the design document and architect a number of systems based on the goals established in the document. Complexity and risk prioritize this work, not feature value.
For example, if the design identifies characters that walk on walls, then they architect that requirement into the character system. This requires a great deal of work to alter the physics system and the camera system. The programmers consider these changes as high priority, since they affect core systems at a fundamental level. As a result, they begin working on these changes from the start. The problem is that the "walking on walls" feature may not be very important to the designers. The feature may even be dropped when it is seen.
This lack of synchronized prioritization between disciplines leads to delays in building knowledge about the game: knowledge that comes only from using each mechanic in a working game.
Scrum requires a synchronization of the disciplines every sprint. This forces change in how each developer works daily regardless of their discipline. A cross-discipline team uses value to explore a solution, which addresses the needs for technology, design, and animation.
This drives changes in the way each discipline works to avoid one discipline getting too far ahead of the others, such as creating speculative architectures.
Programmers on a Scrum team may eventually adopt test-driven development practices, discussed in Chapter 10, "Agile Technology," to enable value-prioritized development without the cost of late changes that up-front architectures attempt to avoid.
Cross-discipline Scrum teams minimize the delays and costs that are incurred by large discipline-focused hierarchies. Team members share the same goal and therefore the same priorities, which encourage collaboration. Practices such as the daily scrum reinforce a team's commitment to the sprint goal and to solving the problems that ordinarily would "fall between the cracks" between the disciplines on a daily basis.
Scrum addresses the problems of communication on large teams not by adding management layers but by dividing the project staff into small teams. Scrum teams are usually composed of five to nine cross-disciplined developers who take on major game features and create vertical slices of those features every sprint. Teams take on an increasing level of self-management by doing the following:
- Choosing the amount of work to accomplish for the coming sprint and committing to its completion
- Deciding the best way to work together
- Estimating their own work and monitoring progress toward their committed goal daily
- Demonstrating sprint goals achieved to the stakeholders every sprint
- Taking responsibility for their performance and finding ways to improve it
Team self-management doesn't happen overnight. It requires mentoring and practice to achieve. It requires trust to be built between management and the teams and the clear definition of the dividing line of responsibilities.
Team self-organization is the most challenging practice for teams trying to achieve self-management. Self-organizing teams select their own members whom they believe can help them achieve the best results.
The benefits of self-organization are an essential part of a self-managing team. When teams "own" their membership, then they treat team commitments with a great deal more ownership. When people are assigned to a team built by management, it's something that they have no control over, and, as we've seen, a lack of control prevents full commitment.
Teams are allowed to change their membership between sprints, but most often they only make changes before the first sprint of a new release. Shortly after a release plan is discussed with the project staff, they negotiate among themselves to exchange members. The teams take the following into account when self-organizing:
What are the release goals and initial release plan? Sometimes release goals require a complete reorganization of the teams. For example, a game that has focused on single-player mechanics might work on online gameplay during the next release. This might require a new distribution of skills.
What disciplines and skills are required to implement the release goals? For example, if a team that has been implementing a shooting mechanic is now being called upon to create AI characters that shoot back, they need to bring an AI programmer on board. If some simple changes need to be made to the codebase, perhaps a junior programmer is the best fit.
What are the priorities of the release goals? If teams compete for people, the higher-priority release goal determines where people go. For example, if both a shooting and driving team need AI and there is only one experienced AI programmer, the higher-priority goal determines that the AI programmer first goes to the shooting mechanic team.
Do the team members have chemistry? Although it is often ignored, the chemistry of people working together on a team has as much impact as any of the practices. For example, teams often benefit from having one outspoken member but suffer from having two. Both might be equally talented, but together they just don't work well. Teams recognize this and should be able to control their membership to avoid it.
Like many other Scrum practices, a team isn't expected to master self-organization from the start. Most studios starting Scrum avoid this practice at first and slowly over time allow the team a greater degree of influence over who is added and removed from the team.
Eventually the team will make the decisions on their own, with leadership influencing their decisions and providing help with conflicts and problems that exceed the team's authority. The rewards are profound. Self-organizing teams deliver unequalled levels of performance and enjoy their work far more than conventionally managed teams (Takeuchi and Nonaka 1986).
When people first hear about self-organization, they are skeptical. It reminds them of painful childhood memories of not being chosen for a sports team. Inexperienced teams treat this practice as a popularity contest. They will need the assistance of management to help them make the best choices (see Chapter 16, "Launching Scrum"). Experienced agile teams, which understand team commitment, end up making better choices that benefit their velocity.
Occasionally, teams "self-organize people off" between sprints. The team removes poor performers or poor team players (see the sidebar "When Someone Is Kicked Off a Team"). This is necessary to allow teams to truly take ownership and commit to their work.
When Someone Is Kicked Off a Team
It's pretty rare for a team to unanimously eject someone from their team. Usually the person ejected has ignored months of team and leadership feedback about their poor performance or teamwork. However, being ejected from a team cannot be ignored. It is a strong statement from a group of your peers.
After this occurs, another team willing to take this person has to be found. They have to be made aware of the issues that led to their ejection from the last team. Teams cannot be forced to accept people they don't want.
If it's the first time this person has been ejected and several other teams are around, the person will be able to join another team easily. Most of time this person corrects the issues and becomes a valuable member of another team, or the person simply finds a team where the chemistry is better.
On rare occasions, they don't work well on the next team either. After a few ejections, it's common to find that no other team will accept this person. It then becomes management's duty to release this person from the company. Sometimes the person gets the message and leaves before this happens.
I've only seen this happen a few times. It's unfortunate, but it makes a statement to the teams: They control their destiny. They are responsible and have the necessary authority to make changes to improve their performance. When this authority doesn't exist, it doesn't allow a team to achieve its potential. Teams that can't self-organize will feel that they are stuck with the members on their team and there is nothing they can do about it. They feel helpless to make the change they need and don't make the same level of commitment they possibly could.
When you see the performance of teams that achieves their potential, you stop questioning the value of these practices. It does take a leap of faith to allow them into your studios. Unfortunately, some don't reach this point and don't see the potential of great teams realized.
Page 2 of 8