If you notice that your Dev Agile team is struggling to focus on a small number of tickets on the Kanban board (this is called Work In Progress), you can play Penny Game with your team.


This game has a great quality: it shows to the team that it is not good to work simultaneously on a large number of tickets. This may sound like a lot counterintuitive, but with this game, the obvious is needed. It also shows that there is a difference between the speed at which the customer receives the delivery of the deliverable of the first iteration and the speed at which the customer receives the delivery of the entire product.

Let's start by presenting the rules of this game Agile.

Constitution of the teams

To play this game, you will need some equipment. Find 20 coins (5 coins of 1 cent of euro, 5 of 2 cents, 5 of 5 cents and 5 of 10 cents).

Make up groups of 2 to 3 workers and 2 to 3 managers (1 per worker). Also designate a customer.

Announce the goal to the team: "Pass the 20 pieces from the first worker to the customer through each worker".

Now, define the roles of group members. The worker passes the pieces to the customer. The customer measures the time that the first piece has to arrive at him and the time that all the pieces put to arrive to him. Finally, the manager measures the time taken by the worker to get rid of his pieces.

Iterations

The game is played in four iteration.

Iteration 1

Announce the rules to follow:

  • Before passing a lot, each worker returns each piece one by one.
  • Use only the left hand (the right hand for left-handed).
  • Each worker passes the coins to his neighbour worker.
  • He can do it only by complete lot, that is 20 pieces.
  • It is forbidden to return everything at once.

At the end of the iteration, note the results in the table.

Organize a 5 min retro for each team to decide on an improvement.

Iteration 2

Announce the rules to follow. The rules to update from the rules of the previous iteration and the improvement decided in retro.

At the end of the iteration, if the group did not reduce the size of the batches in retro of iteration 1:

  • Add the constraint: "Reduce batch sizes from 20 to 10" (or 15).
  • Otherwise, organize a retrospective of 5 min.

Iteration 3

Update the rules to be updated from the rules of the previous iteration and the improvement decided in retro.

At the end of the iteration, this time there is no retrospective. Instead, a new rule is added: "Workers can not mix pieces of different value".

Iteration 4

Update the rules to be updated from the rules of the previous iteration and the improvement decided in retro.

Feedback

Here are the results of a game session that I animated in one of the Agile teams of which I am Agile Coach:

At the end of the game, ask the team how they feel about the game, whether they have noticed differences between the iterations, if the results have changed and if so why, if they have observed an impact of the size of the lots. The goal is ultimately that the team retains improvements for their daily lives.


This game allows the team to learn from their observations of how the game went. In particular, it can be seen that smaller batches can provide value to the customer more quickly. It can also show that the size of the lots (the batch size) has an impact on the lots: with a large size, the pressure is felt during the wait and then disappears; while with a size too small, the pressure is strong and permanent.


Pensées pour mieux produire

Soyez prévenu dès que mon livre "Pensées pour mieux produire" sera disponible à la vente !

DevOps, Agile, Scrum, Kanban, XP, SAFe, LeSS, Lean Startup, Lean UX, Design Thinking, Craftmanship, Management 3.0, ...

 

Bruno Delb

Agile Coach and DevOps, with an experience in the Medical Device software domain, Management 3.0, Agile games and development (especially on mobile) are my passion.

Search

Ads