Game Smarts

Scrum is becoming increasingly popular for game development. I too jumped onto the bandwagon of Scrum Master training and certification, which makes this subject all the more interesting to me. Scrum migrated to the games industry because of the pioneering work of a company in San Diego called High Moon Studios. In a sense, their best game is often branded as the poster child of Scrum for the games industry. But while DarkWatch is certainly way above the average game (it shipped and gets 75% reviews on average), it’s not among the top games of the year. So what makes Scrum so useful, and how come companies that don’t use it can get better results?

Scrum focuses on making a great product, providing some structure to the development process. It suggests maintaining a backlog of features, evaluating their complexity, prioritising them, and selecting them in chunks of 2-4 weeks of work. Then, daily iterations are used to get them implemented. From an organisational point of view, Scrum provides a way for the team to be given enough freedom to shine, while giving the customer enough transparency. Technically, Scrum provides a segway into the world of extreme programming and agile practices in general (e.g. automated testing, or daily builds). But most games companies are doing this to some extent already…

Under the hood, Scrum is based on principles such as commitment, courage, and most importantly self-organisation. As such, some of the practices are implicitly designed to help a good team emerge from the process of development. For example:

• Regular stand-up meetings to improve communication,
• Reducing the discussion and increasing the ratio of useful facts,
• Taking a constructive approach in the retrospective meetings, or
• Isolation from negative forces from the customer/company.

None of these policies are explicitly about making a good team; it’s all about the product. However, it’s safe to say that Scrum works best if there’s a good team behind the development, and in fact it almost assumes that’s the case. Conversely, the main reason for Scrum failing is because the team is dysfunctional in the first place — and not much can be done about it.

Veterans game developers criticise Scrum because good game development teams are organic anyway, and communication just works. You don’t need artificial constructs to facilitate the process, and there is no chaos to control — as the Scrum motto goes. In the games industry, shared vision is typically less of a problem than in sterile corporate settings. In fact, if you have a good team, many practices of Scrum are second nature; you’ll end up doing some automatically. As many joke: Rockstar North (who developed the Grand Theft Auto series) didn’t think about adopting Scrum.

So the situation can be summed up as follows; if you have great people that work well together, then Scrum is a good option to help them deal with external forces (e.g. the publisher) and can improve internal efficiency. On the other hand, if you don’t yet have a great team, then Scrum only tries to create a nursery where the team has the opportunity to grow. Most often, strong external pressures can cause a developing team to implode. Arguably, preventing this is the primary job of the Scrum Master, and indeed, a lot of Scrum consultancy is specifically about this: implementing unwritten rules that help the team gel and work better together.

And that’s where The Core Protocols (see this PDF of version 3) can play an important role. These protocols are essentially software for your head, introduced by Jim and Michele McCarthy. The specific behaviours described in The Core have evolved and been refined over the course of dozens of their Boot Camps, where people get together to learn to work as a team and improve their effectiveness.

The primary motivation for focusing on making a good team, is their belief that the Team is the Product. If you assemble a group of great people that work very well together, then you’ll end up with an awesome game. (I believe in this entirely.) So, unlike Scrum where building a good team is left implicit, The Core’s protocols are designed explicitly for this.

So the combination of The Core Protocols and Scrum seems like a good fit. Here are some examples of protocols at use in a Scrum environment.

1. A team member uses the Intention Check protocol on someone who makes a sarcastic comment during a daily stand-up meeting. It lets everyone know why the person made that comment, and what can be done about it. It also encourages that person to use more constructive channels of communication in the future!
2. The Decider protocol can be used to build consensus on actionable items resulting from a retrospective meeting. Eventually, planning meetings could be run entirely with Decider, with everyone making proposals or counter proposals until the best solution is agreed upon by everyone. (There is no wasteful discussion.)
3. Ask For Help is generally a great protocol for relieving the pressures on developers who are often solicited within a team. But in Scrum, it can be used to request assistance or more information from the customer within a sprint.
4. The Investigate protocol is a good way to assert the meaning of the customer during the planning meetings, without getting emotionally involved. It is much easier to time-box.
5. The Perfection Game is a useful protocol for the reviews of the product at the end of the sprint. It can be used by the customer to identify what’s good about a feature, and how it could be improved in the next sprint.
6. The Check-In protocol can be used at the start of meetings (or daily in the stand-up meeting) by developers to state their emotional status. It lets everyone know how they are feeling and helps other people react accordingly.

Of course, many of these protocols can be used in different contexts. Once you get the hang of them, they tend to reduce the drama anywhere in the development process. Initially, developers may shrug off some protocols as “unprofessional” (e.g. counting to three before voting with thumbs up, or exposing emotions in a meeting), but pretty quickly everyone gets used to the efficiency and the reduced stress. To find out more, be sure to check out The McCarthy Show, a podcast discussing the protocols and team dynamics.