The way that scrum teams are structured are very different from how I had originally learned to structure teams, and the new way of structuring teams has allowed us to break the silos between different disciplines to accelerate development.

How I had originally learned to structure teams is that there is an art team with a lead artist, a design team with a lead designer, and a programming team with a lead programmer. Communication between these different teams had to funnel through the leads, creating communications bottlenecks at the top of the team’s structure.

Scrum teams are cross-disciplinary, meaning that the members of a scrum team aren’t all testers or aren’t all designers – they’re a mix of the different disciplines necessary to execute the team’s sprint goal. A team might have all programmers if the sprint goal only requires programmers, but it’s much more likely that the team will have a mix of all disciplines.

Scrum teams are also smaller than your usual game development team. A scrum team has 5-9 developers plus a product owner and a ScrumMaster. Larger teams are broken into multiple scrum teams and each scrum team might have a different sprint goal. One team might be a features team that is focused exclusively on the character, controls, and camera. Another team might be a production team that is focused on building a level.

However, this doesn’t mean that there aren’t leaders or senior members within the disciplines. The disciplines should form communities of practice that meet across teams to discuss elements of development that need to be known across teams.

Scrum teams are also self-organizing and self-managing. The developers choose which work they will commit to each sprint, and they choose the members of their team. If there is a problem with someone on a scrum team, then that team has the authority to kick that developer off the team. The developer that gets removed from a team must find a team that will take them on knowing the issues that lead to their being removed from the previous team. If none of the teams will take on the trouble developer, then that developer will have to be terminated.

Outside of the normal development team there are two specialist roles on the scrum team: the product owner and the ScrumMaster.

The product owner is analogous to the lead designer in the way we traditionally structured our development teams. This person is not the boss and the game is not theirs – the game is the team’s. The product owner is the advocate for the player. They must be willing to share ownership of the game and share control of decisions with the development team. They must trust their team to make decisions that support the vision of the project and the intent of the features and user stories. The product owner doesn’t assign tasks to people or to sprints – they prioritize the features and trust their developers to make the right choices on what the sprint goal should be.

The ScrumMaster is very similar to what was usually just called a producer in the way we traditionally structured our development teams. The Scrum Master is a facilitator and an advocate for the team. The ScrumMaster’s job is to assist the team in their implementation of scrum and to handle any impediments that hinder the team’s pursuit of their sprint goals. The ScrumMaster might double as a developer, but it isn’t recommended and they should clearly differentiate between when they are acting as a developer and when they are acting as the ScrumMaster.

I hope that this article has helped you to understand how changing the structure of a development team can speed up development and communication on a team.

References

Keith, C. (2010). Agile game development with Scrum. Upper Saddle River, NJ: Addison-Wesley.