Agile – Play, Learn and Share

Play is the highest form of research”

Albert Einstein

Well this is true, theory teaches you through the experience of others whereas practical knowledge teaches you through your own experience. And this blog post is based on the practical learning taken by the participants from my agile workshops.

Lots of theory done !!! Lots of notes taken !!!

Now it’s time to experience the actual difference between waterfall and agile.

As a Scrum Master I have been coaching people through training and presentations on Agile, convincing them why Agile is powerful than waterfall and assuring them through words that Agile can make a big difference while building a product. But clearly I am convinced that practical implementation (data or facts) has more impact than words, specifically for those who are new to agile. An experienced person can easily relate to the significance of Agile over waterfall by comparing his/her previous involvement in waterfall projects with the current Agile project.

To make Agile learning more interesting, I thought of organizing a workshop where people will learn the concepts of Agile through games and they can compare the benefits of agile over waterfall. I was super excited with the idea of workshop because somewhere it was going to be an add-on to my coaching experience also. With the help of Google and YouTube, finally I came up with the workshop plan.

Workshop Plan –

Total duration 1 hr 12 min

  • Team building exercise – 20 min
  • 2 Agile games (30 min)

  • Short funny video (2 min)

  • Discussions during the workshop (20 min)

Time to execute 😀

We divided all the employees into a number of batches in such a way that every batch had 20-25 people and everyone got a chance to get involved in the games. HR team helped me in creating the batches, admin team arranged all the prerequisites to make sure that everything goes as per the plan.

The day arrived when we started with our first batch. At sharp 9:00 am people joined us and took a seat. It looked like everyone needed some caffeine to get charged up. But thanks to our first team building exercise, it worked much better than caffeine to charge them up.


Part 1: Team building exercise – Jigsaw puzzle

Prerequisites– 4 different jigsaw puzzle Prize- chocolates for winning team

I asked everyone to divide themselves into 4 teams. Every team had to complete the jigsaw puzzle in 15 minutes and the one who finished first would be declared winner.

But there was a trick in the puzzle to which none of them was aware. I mixed 2 pieces from each puzzle to the other puzzles. So to complete the puzzle they had to figure it out and get those 2 pieces back from the other teams.

As the game started, everyone was focused on building the puzzle. Initially the game went smooth, all of them were excited to complete the puzzle. After few minutes one of the team asked-


Team : “Are these pieces correct.? We can’t match these 2 pieces with our puzzle.”

Me : “Try to figure it out on your own, you can solve this. Chocolates are waiting for you.”

Then suddenly one of the team member shouted.

Team Member : “Are these pieces mixed?”IMG-20160303-WA0028

Me : “I don’t know” 😉

They started approaching other teams to confirm this thing and they came to realize that pieces have been mixed. It created ruckus in the bay and everyone was running to find their puzzle pieces. It was challenging for them to get their pieces back from other teams because everyone wanted to win this game and they were trying to hold the pieces back to block other teams. This way it created the situation of cross functional teams, where each team was blocked by other teams. This usually happens during the product development cycle when teams depend on each other to achieve a common goal.

After a lot of effort one team managed to win the puzzle. Subsequently an open discussion on the challenges they faced to complete the puzzle, led to these learnings-


  1. Make sure every task should be independent otherwise it will block your work.
  2. If still this situation occurs, then work for the end result (common goal) not for the prize (appreciation).

Part 2: Coin Game

Here comes the main session of the workshop, where participants experienced the difference between Agile and Waterfall.

Prerequisites – 24 coins, table to play this game.


  • Coins as requirements (user stories)
  • Flipping coins is a task

Formed 9 members team in which 1 person acted as a product owner and rest 8 persons were divided into 4 teams – Analysis, Design, Coding and Testing. In each team one person acted as manager and another as an engineer.

How to play the game :-

It’s a game with 3 rounds. I will share the differences in rounds further in this article but before that let me share the basic rules that will remain same in all the rounds. In every round engineers will pick the two coins from both the hands, one coin in each hand, flip them (executing task) and place them back on the table in one row. Likewise they need to process all the coins in 12 rows. Managers will record their engineer’s time taken to process all the coins and product owner will record the total time taken to complete all the phases (analysis, design, coding and testing).

Round 1

In this round analysis engineer processed all the 24 coins and arranged them in 12 rows by flipping the two coins at a time as mentioned above and analysis manager recorded the total time taken by an engineer to complete his tasks. When analysis engineer started the task he said “Start”. Once the analysis was done, design team started processing all those coins and similarly design time was recorded by his/her manager. Same goes for coding team and testing team. Next team didn’t start until the previous team finished all their tasks. When testing team completed all the tasks, engineer said “Stop”.IMG-20160303-WA0021

Product owner recorded the time taken to start and stop.

On white board following results were recorded –

  • Analysis, Design, Coding and Testing individual execution time.
  • Total product execution time (recorded by product owner)
  • Time to market (time when it first released to market – it is similar to the total product execution time)
  • Difference between the sum of individual time and the total product time.

Round 2

In this round, I asked them to make a slight change. When analysis engineer completed the execution of 12 coins, meaning when he processed the 6 rows then design team started working on those 6 rows and analysis engineer kept on working with remaining 12 coins and when the analysis of these 12 coins was completed design team picked those 6 rows. Rest process remained same, managers measured total time taken by their engineers to process all 24 coins, analysis engineer said “Start” when he began it. When it came to the testing team, engineer said “First iteration completed” when he completed the first 6 rows, that time product owner took a lap and recorded that time. Once all the 12 rows completed, testing engineer said “Stop” and product owner recorded the total time.

On White board following results were recorded for 2nd round-

  • Analysis, Design, Coding and Testing individual execution time
  • Total product execution time (recorded by product owner)
  • Time to market (time when first lap marked by product owner- first set of 6 rows completed by testing team)
  • Difference between the sum of individuals time and total product time.

Round 3

In this round I asked the team members if they could help me to get the best results. They quickly came up with the idea to start parallel processing right after the single row. Now I believe they knew the reason of doing this. They executed the plan and this time first lap was taken when single row was processed by the testing team.IMG-20160303-WA0029

Observations made by the participants

  1. Time to market reduced in round 3, which means product started releasing to the marketbefore time.
  2. Each team’s execution time was close to the total product execution time.
  3. Difference between the sum of individual’s time and total product time reduced incomparison to round 1, because transition time reduced due to parallel processing.
  4. This way we got ample amout of time to accommodate feedback and bugs fixing, whichimproves the product’s features and quality.

Take away from this exercise-

  1. Divide your task into smaller chunks so that they are independent, negotiable, valuable, estimable, small and testable.
  2. Reduce transition time, start parallel processing.
  3. Keep on releasing a build to the QA team on completion of user stories.

Part 3: Ball Game

Prerequisites – 2 cricket balls.

For this game I asked 12 people to step forward, priority given to those who didn’t get chance to participate in the coin game. Divided them in 2 teams. Out of 6 members in each team 1 was a manager with timer and other 5 formed a circle.

How to play :-

In this game they need to pass a ball to each other in such a way the ball path form a star in the air. And the person who started passing the ball, received the ball back after completing the one round then it means first task completed and likewise they need to complete 8 tasks to build the complete product. They have to make sure that ball should get processed, means it should travel through air in every pass. Managers of both the teams need to record the total time taken to complete the 8 rounds (tasks).

Round 1 – Total time recorded on white board.

Round 2 – I asked them to reduce the time. And to do so, I asked them to retrospect the previous round and come up with a new strategy for the next round. By that time they were already clear with the concept that to reduce the total execution time they need to reduce the transition time by doing parallel processing.

Teams came up with very different formations to reduce the time and they really managed to reduce the time.

It was great fun and fast learning for everyone.

We got a very positive feedback from everyone on this workshop. Now we are getting ready to organize more workshops like this.

You might also like