Using the Lean Penny Flipping Game to Demonstrate Lean Principles

You’ve probably heard before that if you multitask too much, you are not really accomplishing anything. This is especially true for software development teams, which often face multiple stakeholders pushing conflicting priorities—each insisting that their request is the most urgent. This sort of dysfunctional environment not only leads to low morale in delivery teams, it can also be proven that it will slow down your team if you ask them to multitask too much! 

How do you prove that working in small batches of work actually leads to higher productivity? The Lean Penny Game, also known as the Coin Flipping Game, is a time-tested way to prove this. It has been used by agile trainers and team coaches for decades. In this post, I’m going to show you how to use it for your team, too!

My History with the Lean Penny Flipping Game

When I first started AgilityFeat in 2010, it was as a one-person agile consultancy. I was traveling around the US working as an agile coach and leading agile training sessions. One of the most fun things I learned during that time was the Lean Penny Game.

This game is the most fun way I know to show how effective it is to work in small batch sizes. Over fifteen years later, I still use it in annual classes on agile methodologies that I teach at the University of Virginia’s McIntire School of Commerce. I graduated from UVa McIntire in 2010 with an MS in Management of Information Technology (MSMIT). I’ve been very honored to be invited back to lead one portion of the MSMIT program on agile methodologies, where I give students an overview of scrum and kanban methodologies.

Before I give a full explanation of the Lean Penny Game game, here’s a quick look at a team playing it in one of my classes. I always like to start the day with it as a way to get the students moving, and to immediately instill in them that the best way to work is in small batch sizes.

I first learned this game as an agile coach when I was working with Lithespeed, a leading agile consultancy based in the Washington DC area. One of the other agile trainers at the time (David Bulkin) was unable to make a client engagement on short notice. So I was taught how to run the game and got on a plane to Nashville to lead a session using it.

I don’t know who first came up with this game. It wasn’t David so far as I know, and it certainly wasn’t me. Everyone has their favorite way to run it (here’s a couple of examples here, here and here). Nearly 10 years ago on the AgilityFeat blog, we even wrote a post about making an online multiplayer version of the lean penny game. (Sorry, our website for the game itself doesn’t exist anymore. If you know of a more up to date working version someone else has made, let me know and I’ll post it here!)

Here’s my favorite way to run the Lean Penny game for the graduate students I teach at UVa. It takes about 45 minutes to an hour, depending on how much discussion we have.

Spoiler Alert: The Point of the Lean Penny Game

Each team is given an equal number of coins of various denominations. The members of the team will line up around a table, and they have to pass all the coins from one end of the table to the other in the shortest time possible.  

Spoiler Alert: The ultimate lesson of this game is that the smaller your batch size of coins, the faster you will deliver those coins to the end of the table. It’s a demonstration of a core concept of Lean theory: that smaller batch sizes lead to higher throughput of work through the system. Or stated in the opposite way, the more things you force a team to work on at once, the slower they will be at getting all of it done. More academically speaking, this concept is a part of queueing theory and is known as Little’s Law. It’s probably the most important thing for agile teams to understand, along with the importance of strong communication skills.

Even if a participant knows this basic concept of Lean theory before playing this game, they will likely still come away with a stronger appreciation for the importance of working in small batches.

It’s going to take a while to fully explain the game, but I’m going to make the effort because I think most online descriptions are short on details and may leave a newbie wondering how it works. Bear with me, this will be worth it – so let’s dive into the details!

Lean Penny Game Rules

• The team lines up in a straight line (or around a table), and you must designate the start point and the end point. For the sake of my descriptions below, let’s assume the first person is on the left (we’ll call them Person 1), and the final person is on the right (Person X, where X is the number of people flipping coins in the team).
• All the coins are put in a random pile at the first person in the team. When the facilitator says “go!”, Person 1 can start flipping the first batch of 10 coins to the same side (heads or tails, doesn’t matter, as long as it’s consistent)
• As soon as Person 1 finishes flipping that first batch of 10 coins to the same side, they pass them to the person on their right, Person 2, who can immediately start flipping them to the other side. Meanwhile, Person 1 starts making another batch of 10 coins flipped to the same side.
• As soon as Person 2 finishes their first batch, they pass it to Person 3, and so on, with each person flipping all the coins in that batch to the other side before passing it to the next person, until that batch of coins reaches Person X (the final person), who flips them all once more, and then that batch is considered done.
• Each person can only flip a single batch of coins at once, and must finish it and pass it to the person on their right, before beginning work on the next batch coming to them from their left (yes, there can be bottlenecks, that is part of the game)
• As each person flips the coins, they must use one of their hands to flip each individual coin. No tricks! I’ve seen teams try to get fancy and put them on paper and try to flip the sheet of paper to speed up the process. This is considered cheating and usually ends up falling on the floor anyways and they cheaters will end up being the slowest team because they overthought it.

I phrase it as if the teams will be competing against each other, and that’s true (just to keep it fun). But in reality, the lessons will be about how each team improves their process (primarily by reducing batch size) to deliver value as quickly as possible.

Lean Penny Game Prep

I don’t explain this to the class up front, because it’s not important they know, but I do several things before class begins to make sure the game is fair and we can compare results across the teams:

• Each team is given an equal number of coins. The total number you use is not necessarily important, but I would say 50 is a good number because you will want the teams to have plenty of coins to be passed when using the initial batch size of 10 coins (more on this later).
• I also make sure that each team has a variety of denominations of coins, but that they have the same variety of denominations. This is so no one complains that quarters are easier to flip than pennies, but also because I want each team to have an equal total value of coins because of a surprise I pull on them in the third round (more on this later, too).
• Bring hand sanitizer! Coins are kind of dirty, and you’re going to pass them around between a lot of people. People appreciate it if you have some hand sanitizer for each team so they can clean their hands after the exercise.
• Double check that you have the same total number of coins for each team! I always double check this the night before and separate each team’s coins into a different bin to be ready for the next day as it’s super important that each team has the same number of coins.

Staring the Lean Penny Game: Roles

To begin, I break up the class into three teams of equal size. Why three? Because that’s how many bins of coins I carry with me. I’ve been using the same set of coins for over a decade!

I’m usually running this with about 30 people total, so I have three teams of ten. Each team consists of three roles:

1. Timer – This is the most important role, because we need accurate times to compare the team results each round. I ask for someone who is comfortable using the Lap functionality on their phone’s timer. For each round, they will give me two numbers: The time it takes to get the first batch of coins delivered to the end of the process (by hitting the Lap button), and then the total time it takes to deliver all the coins to the end of the process (Here they just hit Stop on the timer when the last batch of coins reaches the end of the process, I don’t care about the Lap result for each subsequent batch, I’m only going to compare the results of the first batch and final batch to keep it simple)
2. Tester – This is a fun role to add, because I tell them that they need to watch over the whole process for their team, and if they see someone breaking a rule, or mistakenly not flipping all the coins in their batch before passing it, then they must have them fix it right away. A more strict implementation of this would have them pass the batch back to the beginning of the whole process and start that batch over, though I’m usually not that strict.
3. Flippers – Everyone else is just a flipper of coins who stands in a line around the table. This should be the majority of the team, and it’s very important that each team has an equal number of Flippers. So when I am usually splitting my class of 30 people into three teams of 10, that means I have one tester, one timer, and 8 flippers. Testers and Timers do not flip coins. You probably want at least four flippers to make this exercise work well.

If you have an odd number of people and one team ends up with an extra person, an easy solution is to make the odd person be an additional tester on that team. It doesn’t hurt the outcome of the game for teams to have an unequal number of testers, but it’s crucial that each team has the same number of Flippers, and the same number of coins to flip.

Lean Penny Game Round 1 Rules

In the first round, I set a batch size of 10, and put the following rules on the screen. You may notice that other articles I linked to above will start with a batch size of 20, and incorporate other rules like “only flip with your left hand”. I don’t do that, and you can run the game however you want, but it’s important that in the first round the batch size (10 in my case) is set by the facilitator, and I definitely don’t recommend starting with a batch size smaller than 10.

What Round 1 Looks Like

This seems like a lot of explanation in this blog post, but it’s easier done in person and you can show with your own hands how the exercise works. When the teams are ready and lined up around their tables, and the timers have all confirmed they are ready to start timing, then the facilitator says “Go!”

Teams should all be working with a batch size of 10 initially, and you might see them passing the coins down the table in batches of 10 like in this video (which is running faster than real time obviously):

Round 1 Results and Retrospective

Before moving on to the next round, I capture the two numbers I need from each timer. Remember that these numbers are:

1. Time To First Value Delivered – This is the time (usually just under a minute) that it took for the first batch of 10 coins to make it all the way to the end of the process (ie, Person 1 through Person X have all flipped each coin before passing the batch, and the Timer hit the Lap button on their phone when Person X completed flipping the coins of that first batch)
2. Time to Done (or Final Value Delivered) – This is the time it took for the last batch of 10 coins to make it to the end of the process, which signifies that all the value was delivered to the customer (In my teams with 8 flippers, this usually takes around 2 minutes). Depending on the number of coins you hand out, the final batch size may not be 10 coins exactly, it’s probably something less than that. That’s ok, still have the Timer stop their watch when Person X (at the end of the line) has finished flipping the last batch of coins to the other side.

The initial results may look something like this (from a real team exercise):

Now I ask each team to talk about their experiences. I try not to lead them too much in their comments, and usually as a class we come up with observations like these:

• “We stumbled a lot because it was the first time doing this, we’ll beat the other teams next time.” Possibly true, quality will improve with practice
• All teams take less time to deliver their first value than their final value (of course), but there’s usually one team that is significantly better, and one who is significantly worse, than the other teams. Often this leads to a joking discussion like “This person is a bottleneck, they dropped a whole batch of coins”

The most important observations to make though are about idle time when batch size is initially high, and so if no one brings it up, I make sure they notice that:

• What was Person X (the last person) doing at the beginning of the exercise?  Probably nothing, while they waited for the first batch to reach them. They had a lot of idle time at the beginning of the round, and all the pressure was on them in the final moments of the round as they raced to flip the last coins. This is analogous to what many software testers face in the software development life cycle. They have nothing to do at the beginning of a project, and all the pressure is on them at the end of a waterfall style project to get everything tested.
• The opposite is also true. Person 1 was very busy at the beginning of the round, but had nothing to do towards the end of the round since all the batches of coins were now being flipped by the final people in the team.

Round 2 of the Lean Penny Game

Having completed that discussion with the students, we start another round. In articles from others about the penny flipping game, facilitators may do several rounds where they require that each round the teams use progressively smaller batch sizes:  20 coins, then 10 coins, then 5 coins, etc. That is a guaranteed way to demonstrate the results the trainer wants (increasing throughput speed as batch size decreases).

I prefer to tempt fate and not lead the class to the correct answers (which is to reduce the batch size). I just ask each team to change something or multiple things for the next round and try to improve (without violating the rules we previously established about how each flipper needs to touch all the coins and flip them all individually).

I make sure to subtly say something like “you can change the batch size, or change how you line up around the table, or maybe move that bottleneck person to a different position in the line.” So I drop the hint, but I try not to emphasize it, because it’s more fun to see what they come up with, and the results of round two often look something like these (again, the same real-world team as before):

Lessons from Round 2

At the end of round 2, I ask the teams to reflect again on what went differently this time. What do you see differently about each team? For the results above, these were pretty typical observations:

1. Every team completed the exercise faster than in Round 1. Even if their changes didn’t make a big difference, practice does make you better. Even a waterfall team can get better results with practice! 
2. Almost every time they also improved the first value they delivered to their customer, except for team three in this example, which was a bit slower in their first batch, but still faster overall. Notice they still used a batch size of 10, and I don’t remember what changes they made, but it was probably something simple like moving the slowest person to a different position in the workflow where they thought it would go better.
3. Team 2 is the clear winner in this example, and while the exercise was going on, both teams 1 and 3 were annoyed to see how quickly they finished! There are typically jokes at this stage about “they must have cheated”, which is why I like letting teams choose their own batch size. But Team 2 just immediately got the concept better – Smaller batch sizes lead to faster throughput!

So we end Round 2 with a good discussion of how Team 2 chose a batch size of 2, instead of 10, and how that meant their team had less idle time and completed their first batch, and their whole set of coins, much faster than any other team. This leads to a good discussion of analogies to the software development world, where we talk about the importance of getting that first value to our customers quickly, so they can see if we are on the right path or not.

What does a team using a batch size of two look like? Check out this video, and notice how much faster they are then the same team using a batch size of 10 in the prior video. (Both videos are sped up by the same amount)

Notice a funny thing about the penny flipping exercise: The optimal batch size is two. Lean says smaller batches are better, and so a batch size of one should be even faster than two, but in this exercise it is not. Why? Because probably everyone on the team has two hands! This is why some trainers force teams to only use their left hand, so that the optimal answer will be a batch size of one. Personally I like having the discussion of why two is better than one in this unique case, so I let the class come to that realization themselves without me telling them.

Round Three of the Lean Penny Game

Now that all the teams understand from our prior round’s discussion that a batch size of two is optimal, I promise them “we have time for just one more round so that you can see who is really the best team at this!” Everybody loves a little more competition, but I have a secret up my sleeve, which I also learned from other agile trainers.

I tell them to make final adjustments to their process, most importantly use a batch size of two (or try a batch size of one if they want, whatever), and then we start the round.

Before any team is complete, but after I see that each team has completed a few batches all the way through the process, I stop the exercise abruptly and throw them a curveball that usually goes like this:

ME:  “STOP! EVERYBODY STOP!  Please put down the coins and take your hands off the table. I’m sorry, but we are not going to finish Round 3.” 

CLASS: [Looks of confusion and annoyance at me, for stopping them in the middle of their most glorious round of coin flipping yet, en route to a fantastic victory no doubt.]

ME: “I have bad news … company management just cancelled this project. You’ve run out of budget! Instead of giving me the times it took to deliver value, I want each team to count up the total dollar value of the coins that made it all the way through the process!  ONLY THE COINS THAT WERE COMPLETED! All other coins that are not “done” are wasted work unfortunately and should be ignored.”

CLASS: [Groans as they start to realize what I’ve done, and that they paid no attention to the denomination of the coins they were passing down the line]

ME: [Smiling victoriously about this cruel trick I’ve played on them]

The completed results of all three rounds might now look something like this:

Probably by sheer luck, Team 1 happened to pass some quarters first and so they won, with a whopping $1.50 of value delivered successfully before cutting the exercise short. Teams 2 and 3 likely continued to complain a bit about my surprise rules, since they through no fault of their own, were just passing any coin without thinking about how valuable it might be to the customer.

It always works this way, as long as I’ve been doing this exercise with teams for nearly 15 years now. Never once has it not worked this way! It has probably also always worked with every agile trainer who has led this exercise in the last 20 years.

Small batch sizes always deliver faster, and the teams are always surprised when I stop Round 3 and tell them to think about value delivered, not just the speed at which it was delivered.

The Real Value of Agile Methods

At the end of this game, I always tell my students that they have learned two of the three most important lessons of Lean and Agile methods:

1. Small Batch Sizes will always improve overall throughput – You will get more done when you focus on a smaller number of items, and don’t spread yourself thin. Finish something before moving on to the next task. Scrum teams should not commit to more work than they can finish in a sprint. Kanban teams should keep their Work In Progress (WIP) limits low, so that they get work items done before moving on to the next ones.
2. Prioritization is crucial, because you can’t predict the future – Working in small batch sizes is not enough on its own, you also have to prioritize your work so that you work on the most important items first. Because you never know what’s coming next … Management might cancel the project, or the work might take longer than you expected and so you run out of time or budget! In those cases, you want to make sure you give the customer the most important items first. As I’ll say at the end of the coin flipping game, “Who cares if you don’t get all the pennies flipped, as long as you flipped the quarters first?”  Customers will ask you to build lots of things, but they don’t value them all equally.

Since I run this exercise at the beginning of a day of classes, I often joke: “As long as you learn that small batch sizes and prioritization are the key to agile methods, you’re welcome to tune out the rest of the day. You’ve learned two of the three most important things about agile methods!”

What’s the third most important thing about agile methods? It’s communication. In my opinion, everything else about Kanban or Scrum or any other agile methodology is just about how to improve communication (and visibility) of work in the team. Any agile method should give you a framework for working in small batch sizes (and delivering it in small batch sizes), prioritizing your work, and enforcing strong communication techniques. Without those three things, it’s not particularly agile.

Parting Words on the Lean Penny Game

I hope you found this detailed explanation of how I lead the lean penny game to be helpful!  These are other ways to do it. Just like I don’t know who invented this game, I won’t pretend that I have the magic formula for how to lead it. This is just how I do it, and I’ve gotten very good feedback from my students about it. 

By the way, if you’re a future student in one of my classes – please forget everything you read here! Or at least stay quiet if you see me lead this exercise in person and let the others learn from the experience. Please don’t spoil my surprise in Round 3, it would crush my mischievous little heart. 

Finally, I should note that if you loved this game, but don’t have a software development team to play it with, I can help with that too! My company AgilityFeat is no longer an agile consultancy, but for well over a decade we have been building agile nearshore software development teams in Latin America for our US clients. 

We have placed thousands of developers with hundreds of clients over the years, and I’d be happy to help your company build and grow your team with the best technical talent in Latin America. If you have extra compliance concerns or just want more control over your team, we can even help you set up your own subsidiary in Latin America, using our Build-Operate-Transfer (BOT) model, in which we take all the up front legal and financial burdens of setting up a subsidiary, and then transfer it to you!