Scale

Motivation

Deployments and Disasters is a tool for educating medium to large engineering teams about incident management techniques and procedures. Its usefulness grows with the size of the team. For example, in a 5 person team a new procedure will be communicated easily and all team members will be on board with it quickly. Contrast that with a 100+ people engineering division. At that scale communicating the existence, let alone the details of, a new procedure becomes challenging.

In that context it becomes important to insure that an educational tool like Deployments and Disasters game scales well. That includes:

  1. Maximizing number of team members that go through the education.
  2. Maximizing the impact on the company that each individual education session has.

Measure

Consider sending all players a poll after the session. It should contain questions like:

  • “Would you recommend the game to a colleague?"
  • “Would you like to help out with organizing a next session?"
  • “Do you have any ideas for creating new incident scenarios?"

From answers you collect you can both see how well the individual session was received and create a list of people willing to help the game scale. Involving more people to host sessions and contribute with new incident scenarios is key to setting up a sustainable education program.

Implementation ideas

There are a few main problems to scaling a tabletop role playing game intended to improve incident management. Some company employees may be scared off by the gameplay mechanics. This is why Deployments and Disasters only uses a few D6 dice. Ubiquity of D6 makes it less intimidating and more accessible.

Creating incident scenarios takes a lot of time and effort. Since Deployments and Disasters sessions are one-offs it becomes important to re-use scenarios. This still limits you to playing one session per scenario with the same team of players. However you can replay the scenario many times with different teams of players to amortize the cost of creating it.

Number of players in a single session is another limitation. You will not be able to squeeze more than 10 players in a single game (with optimal number being closer to 5). You can remedy this by playing a session in front of an audience. The session might have a lower impact on those just observing it, but some gain might be achieved.

These are just some ideas for dealing with scaling issues. You may devise some new ones specific to your situation. Others still can be found in the rest of this documentation.