Overview

The WordCount simulation revolves around WordCount, Inc., a fictional company that makes a word counting system.

Participants in the simulation each choose a role, whether Product Manager, Tester, Developer, Computer (channeling their inner robot), Interoffice Mail Courier, or Observer.

Each group starts with an initial set of artifacts. The Product Managers have notes from their fictional predecessor’s conversations with the customer, the Developers and Testers have an initial set of requirements, the Developers and the Computer have version 0 of the code, and the Testers have an existing set of tests.

When the simulation begins, the participants must follow a pre-defined process that resembles a very traditional organization with groups working in silos and very constrained communication. The process explicitly defines responsibilities and communication paths by specifying things like “Communication between Developers, Testers, and Product Managers occurs only through Interoffice Mail,” and “Only Developers may create or modify Code.”

Product Managers define the product, interact with the Customer (played by an instructor), and write requirements on blue index cards. (As you can see in the picture to the left where Dale Emery is playing the role of Customer, the Customer sometimes wears a funny hat.)

Developers turn those requirements into executable instructions (“code”) on green index cards. They install the code in the Computer Lab where the participants playing the role of Computers use the instructions to process input and return output.

Testers design test cases on yellow index cards and execute them against the code by submitting input on white index cards to the Computers, receiving output, also on white index cards, and comparing their expectations with the actual output produced by the Computer.

Of course, not all input can be processed. If the Computer cannot process the input, it throws a catastrophic error on a purple index card. This usually prompts the Testers to write a bug report on a red index card.

The lone Interoffice Mail Courier (there can be only one) delivers messages and Project Artifacts between groups.

Observers watch interactions and take notes of things they saw and heard that they think may be of interest to the rest of the participants.

Throughout the simulation, we work in rounds. So we work on the simulation for 15 minutes, then pause to hold a mini-retrospective in which we reflect and adapt the process to increase Agility. During these mini-retrospectives, the Observers notes help the participants see events from another perspective and unravel mysteries ("how did that happen?").

After the each round, the participants reflect and adapt, changing the process to improve using Agile characteristics as a guide including: Communication, Collaboration, Feedback, Visibility, Alignment on Shared Goals, Reduce Waste, Focus on Value, and Deliver Early & Often.

The end result is a full Agile transformation accomplished in a matter of hours. Yet despite the short timeframe, all the same kinds of issues arise in the simulation as in real life. That's the power of simulating: it gives us the opportunity to practice identifying and addressing issues within a microcosm and see the results of our choices quickly.