Agile Games – Battleships
No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength – Generalfeldmarschall Helmuth von Moltke
This is a game I use to introduce people to iterative development. The aim is to help the players to understand that upfront large plans are pointless the minute they are created. Helmuth (quoted above), for me, was one of the first proponents of an iterative approach. He didn’t necessarily create grand plans, conversely he didn’t disregard planning altogether, but he was smart enough to plan just enough and adjust his plan to meet the changing reality. Often my experience of working on projects with large up front plans, the opposite is true and the owner of that plan tries to adjust the reality to fit the plan.
So how do you play it?
Simple, one player (Player A) is given 40-45 pegs and told to place their ships and all their planned attacks up front. The second player (Player B) simultaneously places their ships. Once that has been done, the first player reads out the 40 pre-planned attacks and is given the hits and misses. Player B then get to play each attack (up to 40-45) separately, getting feedback on hits & misses for each.
It’s pretty obvious what will happen, most of the time Player B’s turn (iterative) based play will allow him to adjust and change his plans as he scores hits. Player A (large plan) will score hits, but is far less likely to sink all the opponents ships. So player B being limited to 40 moves also may sink the whole fleet or not, typically though that player will score more hits than the other.
What does this tell us?
Predictive planning is unreliable and is akin to reading crystal balls, reading tea leaves or any other clairvoyant technique you care to mention. Ultimately you’re predicting the future based on an infinite number of possible outcomes, effects and variables. The iterative approach is empirical, each time Player B hits his opponents ships, he can instantly change plans and target nearby locations to sink it.
There are a few other parallels you can draw from it.. Player A will often score hits but not sink, this is akin to features that were developed but not tested before time or money ran out. Player B however may not hit all the ships but is much more likely to sink the ones he does hit, making it a metaphor for “potentially shippable product increments” (no pun intended).
Occasionally Player A wins, this is a bit like the fortune teller coincidentally getting something right, it’s often more luck than judgement.