The Agile game I would like to introduce today is called "Battleship". This game is generally used to experience the difference between the waterfall design process and the agile process. It introduces people to iterative development and explains the concepts behind it, the idea is to get people to understand that up-front, large plans are just not recommended!

Description of the game
Split the group into two teams: the Grand Plan team (Team A) and Frequent Feedback team (Team B).
The game is run in a single round during which each team will take 30 shots.
To score the game, each team gets 1 point for a hit and an additional 2 points for each ship sunk.

Each team starts by laying out their ships on the grid.
Team A is told to place all their planned attacks up front.
Team B plans and takes one shot at a time.
Once Team A has determined all 30 shots, they inform Team B of their shots. After Team A has shared all of their shots, Team B lets Team A know which shots were hits and if any ships were sunk. After Team A completes their turn, Team B responds. Team B takes a single shot, gets feedback from Team A (Miss / Hit / Sunk), and decides their next shot. They do this 30 times.

For the basic game, the win is usually quite clear with Team A scoring much less than Team B. The learning point is that responsiveness is vital to success, the tighter we make the learning feedback loop, the more successful we can be.

Variation
In this variation, split the group into two teams: the Small Releases team (Team A) and Continuous Delivery team (Team B).
The game is played in 4 rounds of 8 shots each.
To score this variation of the game, each team gets a single point for a hit, an additional 2 points for each ship sunk, and 2 bonus points for each ship discovered and sunk in a single round.

Each team starts by laying out their ships on the grid.
Team A still pre-plans the 8 shots per round and executes them all at once, receiving feedback after each round.
Team B still takes a single shot at a time for 8 shots, getting immediate feedback.
Mark shots with the round number in which they were taken. This will not only help keep track of the activity per round, but will help with the scoring.

In the variation game, the difference on score is smaller, but still present. The learning point is that too fast a feedback loop is not always better than a small batch; having a pause to consider what we’re going to focus on next and designing a short term strategy for it ensures that there actually is a strategy.

I suggest to give it a try, the Agile games build a safe-to-fail environment and let participants get a first hand experience of new concepts.

Source:
This post was inspired by https://onbelay.co/articles/2019/2/6/agile-game-battleship