Over a million developers have joined DZone.

Agile: Play, Learn, and Share

DZone's Guide to

Agile: Play, Learn, and Share

Martin Streve organized a workshop where people could learn about Agile through games and compare the benefits of Agile over Waterfall.

· Agile Zone ·
Free Resource

Theory teaches you through the experience of others, whereas practical knowledge teaches you through your own experience. That being said, this blog post is based on the practical learning from the participants of my Agile workshops.

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 that Agile is powerful than Waterfall and assuring them that Agile can make a big difference while building a product. I am convinced that practical implementation (data and 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 or 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 could learn the concepts of Agile through games and compare the benefits of Agile over Waterfall. I was super excited with the idea of the workshop because it was also going to be an add-on to my coaching experience. With the help of Google and YouTube, I finally came up with the workshop plan.

Time to Execute

We divided all the employees into a number of batches of 20-25 people each. Everyone had a chance to help with the teams. The HR team helped me create the batches and the admin team arranged all of the prerequisites to make sure that everything would go according to plan.

The day arrived when we started with our first batch. At 9 o'clock sharp, people joined us and took a seat. It looked like everyone needed some caffeine to get charged up, but our first team building exercise worked much better than caffeine.

Part 1: Team Building Exercise (Jigsaw Puzzle)

Prerequisites: four different jigsaw puzzles

Prize: chocolates for the winning team

I asked everyone to divide themselves into four teams. Every team had to complete the jigsaw puzzle in 15 minutes and the one who finished first would be declared the winner. But there was a trick in the puzzle of which none of them was aware. I mixed two pieces from each puzzle into the other puzzles. So, to complete the puzzle, they had to figure this out and get those two pieces back from the other teams.

As the game started, everyone was focused on building the puzzle. Initially, the game went smoothly and all of them were excited to complete the puzzle. 

Image title

After few minutes, one of the teams asked:

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

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

Then suddenly one of the team members shouted.

Image title

“Are these pieces mixed?”

“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 a 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 created the situation of cross-functional teams in which 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 is independent; otherwise, it will block your work.
  2. If still this situation occurs, then work for the end result (the common goal), not for the prize (appreciation).

Part 2: Coin Game

Prerequisites: 24 coins; table

Assumptions: coins as requirements (user stories); flipping coins is a task

This was the main session of the workshop; participants experienced the difference between Agile and Waterfall.

We formed teams with nine members each. One person acted as a Product Owner and the other eight were divided into four teams: Analysis, Design, Coding, and Testing. In each team, one person acted as manager and another as an engineer.

The game has three rounds. In every round, engineers pick the two coins, put 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 of the coins and the Product Owner will record the total time taken to complete all of the phases (analysis, design, coding and testing).

Round 1

In this round, the analysis engineer processed all the 24 coins and arranged them in 12 rows by flipping the two coins at a time. The analysis manager recorded the total time taken by an engineer to complete his or her tasks. The analysis would say “start” at the beginning of the task. Once the analysis was done, the design team started processing the coins. Similarly, the design time was recorded by his or her manager. Same goes for the coding team and testing teams. The next team didn’t start until the previous team finished all of their tasks. When testing team completed all the tasks, the engineer would say “stop.”

The Product Owner recorded the time taken to start and stop.

Image title

On a white board, the following results were recorded:

  • Analysis, design, coding, and testing individual execution times.
  • 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).
  • The difference between the sum of the individual time and the total product time.

Round 2

In this round, I asked them to make a slight change. When the analysis engineer completed the execution of 12 coins (meaning when he processed the six rows) then the design team started working on those six rows and analysis engineer kept on working with remaining 12 coins. When the analysis of these 12 coins was completed, the design team picked those six rows. The rest of the process remained same. Managers measured the total time taken by their engineers to process all 24 coins and the analysis engineer would say “start” when he began it. When it came to the testing team, the engineer would say “first iteration completed” when he completed the first six rows. Then, the Product Owner would take a lap and record that time. Once all the 12 rows were completed, the testing engineer would say “stop” and the Product Owner recorded the total time.

On a white board, the following results were recorded:

  • Analysis, design, coding, and testing individual execution times.
  • Total product execution time (recorded by Product Owner).
  • Time to market (time when the first lap was marked by the product owner; the first set of six rows completed by testing team).
  • The difference between the sum of individual time and the total product time.

Round 3

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

Image title

Observations made by the participants:

  1. The time to market reduced in round three, which means that the product started releasing to the market before time.
  2. Each team’s execution time was close to the total product execution time.
  3. The difference between the sum of the individual’s time and the total product time reduced in comparison to round one because the transition time reduced because of parallel processing.
  4. This way, we got an ample amount of time to accommodate feedback and fixing bugs, which improves the product’s features and quality.

Takeaway 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.

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. I then divided them into two teams. Out of six members in each team, one was a manager with a timer and the other five formed a circle.

How to play:

Pass a ball to each other in such a way that the ball path forms a star in the air. If the person who started passing the ball received the ball back after completing the one round, then the first task has been completed. Likewise, they need to complete 8 tasks to build the complete product. They have to make sure that ball gets processed, meaning it should travel through the air in every pass. Managers of both the teams need to record the total time taken to complete the eight rounds (tasks).

Part 1

The total time is recorded on white board.

Part 2

I asked them to reduce the time. 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 needed 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 do a great job.

It was great fun and fast learning for everyone.We got a very positive feedback from everyone on this workshop and we are getting ready to organize more workshops like this.

Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.

agile architecture

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}