One of the biggest impediments in the adoption of lean and agile is gaining intellectual commitment of rank and file developers (e.g., architects, programmers, etc.) on the one hand, and of management on the other. Sure, the passion of a change agent may rub off temporarily on others, though the newly converted may not be able to verbalize why they are “going agile.” That’s where the “Penny Game” comes in – it’s a powerful tool to simply and effectively illustrate certain core virtues of a lean process. It’s a “Kool-Aid”, in that it can help you to win converts with a fun, clear and logical exercise – and it only requires twenty pennies and a little time. Any converts will not only connect with lean at an emotional level, but they’ll also be able to understand and articulate its value.
One of the key features of lean processes is the rapid flow of value to customers, and this has become central to scrum. Flow can be enhanced by reducing the size of objects within a process, such as the number or scope of product features within a software development process. However, development and management communities, particularly those more familiar with waterfall techniques, may not recognize the value of developing smaller features within short, time-boxed development sprints. Instead, waterfall-based teams generally work on larger sets of features for a longer period of time, and then deliver them in a larger, less frequent releases.
The Penny Game isn’t really a game, but is more of a simulation of, or a metaphor for, a business process. It lends itself well to relatively small groups of people, and could conceivably be conducted with as few as four participants. However, it can also be adapted to larger groups by changing it into a true game with multiple teams, each doing the same exercise, who compete for the shortest end-to-end cycle times.
Nine participants are necessary for the form of the Penny Game described here. Three of these represent a hypothetical software development team consisting of a Designer, a Developer, and a Tester. The products of their simulated development are presented to a fourth role, the Customer. Four are Timers for each of the development team members and the Customer. Finally, a Scrum Master manages the exercise and records times in a data sheet. See Figure 1 for a diagram of the roles and methods and Figure 2 for a data sheet.
Figure 1. Roles & Method. Click to enlarge.
In this stripped-down version, the simulation is run only three times, and each run is called a “sprint”. Within each sprint, the 20 pennies are divided into groups or batches: Either one batch of 20 pennies (no division), 4 batches of 5 pennies, or 20 batches of 1 penny. Within the sprint, the Designer turns over each penny in a batch with their preferred hand, and when all pennies in a batch are flipped, slides the batch to the Developer. The Developer, does the same, turning over each coin in the batch with their preferred hand, and then slides the batch to the Tester. Similarly, the Tester also flips the coins (again with their preferred hand), then slides the batch to the Customer. The Customer does nothing other than accepts each batch as it is handed to them. This process is repeated, batch by batch, until all pennies have been received by the Customer. Note that the flipping of the coins represents the work done within a business process; In our case, it represents designing, developing, and testing software.
Within each sprint, Timers measure the amount of time that the Designer, Developer, and Tester flips coins (Amount = Time last batch pushed to the next person – Time first coin is touched), the time that the Customer receives the first batch of pennies (“Customer First” = Time Customer Receives first coin – Time Designer touches first coin), and the time the Customer receives the last batch of pennies (“Customer Last” = Time Customer Receives last coin – Time Designer touches first coin). At the end of each sprint, the Scrum Master enters all the times into a data sheet. See Figure 2 for a sample data sheet, where each column represents an individual sprint with a given batch size.
Figure 2. Data Sheet. Click to enlarge.
The simulation should be repeated for the three batch sizes shown in the data sheet. For best results, use the largest batch sizes first, then progressively smaller ones. The entire exercise, with background, instructions, three sprints, and a review of results with their interpretation, requires only 15 – 25 minutes.
Results & Interpretation.
One of the best things about the Penny Game is its robustness – you’ll likely see the same results every time you try it. Better yet, the trends are instructive, and speak to the value of a lean development process. In particular, you’ll likely see the following patterns:
- Value is delivered faster with lean flows. In the data sheet, the time in “Customer First” is likely smaller with smaller batch sizes. This is probably the most important learning from the exercise, and it illustrates the value of lean development as compared to waterfall. In addition, the development process gains an advantage from a flow process, in that opportunities for feedback from “downstream” groups emerge earlier in the lean process.
- Development is completed faster with lean flows. In the data sheet, the time in “Customer Last” is likely smaller with smaller batch sizes. Not only is the initial work delivered to the customer faster with a lean process, but the entire body of work is completed more quickly with smaller batch sizes. That is, aggregate development proceeds more rapidly with a lean process.
- The devil doesn’t like lean flows. As batch size decreases, the the amount of time each Designer, Developer, and Tester spends flipping coins increases – their work is spread further across a sprint, leaving less idle time on their hands. This is primarily due to the increased transaction time — the increased number of “slidings” of the smaller batches from one person to the next. Combined with the first two patterns, this result also demonstrates the trade-off from optimizing individual performance (espectially as observed for larger batch sizes) versus optimizing end-to-end system or process performance (especially as observed with smaller batch sizes).
Collectively, the results demonstrate the impact of leaner flows within the Penny Game, and by extension, within software development processes. Processes with smaller batch sizes provide value faster to the customer, support faster feedback to the rest of the team, and speed completion of overall development, but at the expense of increased transaction costs. Faster feedback means that a team can increase the quality of product more quickly.
The implications for a software development process are clear – build smaller chunks of functionality over shorter periods of time, and you can deliver high quality code more quickly.
Conclusion & Notes.
So there you have it, a pitcher of Kool-Aid – it’s tasty, intellectually nutritious, and it costs only 20 cents! You might not be thirsty for it, but your colleagues might benefit from a drink. Share it generously to gain knowledgeable lean partners!
In a follow-up post, I’ll review variations of the Penny Game which are helpful in special situations, or which help to demonstrate other important agile or lean principles. In addition, we’ll examine the relationship between batch size and WIP size, as well as Little’s Law.
Though I have modified the Penny Game to more closely resemble a Scrum software development environment, I have borrowed other aspects from a variety of sources on the internet. Thanks to my colleagues in Sprint’s Agile Center of Excellence for their support and feedback.