Penny game simulation
The lean/agile penny game has become a standard way to demonstrate the benefits of small batch sizes in a production flow. However, as a demonstration of the effects of agile transformation on a software development team it is woefully inadequate. In this article we describe the classic penny game as played in much agile training, critique its accuracy as a model for agile software development, and provide a simulation that you can run yourself, showing what will happen if the software developers are not supported in adopting the practices of Extreme Programming.
A series of blog posts.
The simulation below consists of three production lines or teams. Each team executes the same process in exactly the same way, but each has been configured with parameter values that represent different software development processes:
- This is the classic penny game played with a batch size of 20 coins. It is usually intended to represent a "waterfall" project lifecycle, although there is no representation of legacy code etc.
- This is the classic penny game played with a batch size of 5 coins. It is usually intended to represent an "agile" project lifecycle. Again, this simulation does not represent the effects of legacy code or legacy coding practices.
- This production line is configured to reflect what often happens in "agile adoption" projects. Everyone works with a batch size of 5, except the developers. The developers begin with a batch size of 10, and this increases by 1 after the completion of each batch of tasks. Development tasks also take 3 clock ticks, to simulate the fact that developing a story usually takes much longer than analysing it.
The configuration parameters are:
- Batch size
- The batch size used by each worker in the team. The larger initial batch size used by Development in the "Scrum" simulation is intended to reflect the fact that many development teams find it difficult to work in small increments, without the up-front design to which they are accustomed.
- Batch size increment
- The amount by which a worker's batch size grows after delivering each iteration. Intended to reflect the effects of coupling and legacy code. Paradoxically, this effect is often magnified by asking the developers to forego up-front design without supporting them in adoption of something like the XP practices.
- Task size
- The number of clock ticks required to complete any task. The larger task size for Development in the "Scrum" simulation reflects the fact that creating production software often takes longer than writing requirements. Also (for now) reflects the time lost due to interruptions such as defects.
To run all simulations, press the play button below. You can pause at any time, or use the reset button to start again from an empty project. The "sliders" button displays the configuration parameters used for each team, and shows how these values have changed during the simulation run.
Please note that this simulation requires a good deal of computing power, so it may slow up after a couple of hundred ticks. Enjoy!