Agile and the Fog of War
By: Grace Ke
Tags: Agile Methodology, Agile Development, Agile, Software Development

Fog of war represents the uncertainty or lack of situational awareness experienced when assessing an area of conflict. My husband often plays first person shooter games that employ a map, used to depict the fog of war. The map gives you a general idea of what’s out there, but until you get to the marked locations- no specifics are revealed until you go there yourself or send a scout. As you clear an area, that part of the map is revealed. As you tackle and conquer more locations and place the map into clear view, eventually, you win the game.

Photo from https://www.polygon.com/far-cry-5-guide/2018/3/26/17164422/map-weapons-fangs-for-hire-challenges-perks-helicopter-stealth-arcade

I recently spent time observing my husband play Far Cry 5. I often took for granted these game plays and the time my husband spends strategizing which areas to go into first, especially in games with very open worlds. However, as I thought about the way he approaches game play, especially with games that involve the fog of war, I now see a lot of parallels with that strategy and how Agile works.

Agile is a software development, delivery and management methodology that consists of short iterative cycles so that incremental value can be delivered to customers. It echoes the sentiment behind the question- how does one eat an elephant? The answer is one bite at a time. Instead of trying to determine all the requirements, all at once, software teams perform discovery over a small scope and deliver based on those discoveries. Code changes are designed to be small, with the intention to discover failures early in the process, so that teams can adjust and take another path.

This, to me, is no different than the game play strategies employed when dealing with the fog of war.

Weigh all your options

At the beginning of these first person games, you’re typically given a simple weapon (or sometimes, just your wits), and there’s no ammo, transport, allies, etc. In order to build your arsenal and resources, you have to decide what is most important and which route allows you to collect those things. Sometimes, you decide to attack an outpost even though the fight is hard, and there is a huge risk to life and limb, but you know the supplies you will gain there will be worth it.

Photo by Jens Lelie on Unsplash

In software development, there are often multiple ways to solve the same problem. Some are costly, but allows you to deliver software in a shorter amount of time. However, some tried and true paths may take longer, but offer higher consistency and reliability. It all depends on what the most important goal is for the team, at the time of the decision.

2. Gather as much data as possible- within reasonable times

In first person shooter gameplay, it’s sometimes possible to send out a scout to see the scope of the area and the risks associated with it, that may previously have not been known to you. In the Agile methodology, development teams can often perform what is known as a SPIKE — this is a discovery process, often time boxed, to determine and potentially, test, feasible solutions and understand the objective or requirements better, if not well-defined. Time-boxing is key here — only spend the minimum amount of time to get the data you need, and then get out.

3. Don’t take on more unnecessary risks than you have to

After weighing your options based on data you gathered, you still will encounter risks along the way, as you tackle an enemy area or as you’re developing a solution. For example, you can decide to roll with a single instance versus multi-replication data storage solution. The question to ask is, what am I willing to deal with, if my decision turns out to be inadequate? What do I lose, and am I willing to accept, or can I afford, that loss? If the possibility of the risk is low, and/or can be mitigated with little or no cost, then the risk may be well worth it, in order to realize rewards sooner.

Photo by Michael Shannon on Unsplash

4. Fail fast

Sometimes, games will offer side missions to allow the player to gain experience, or it offers the player a short distraction from the larger objectives of the game. The mini-quests are often easy to get into and out of, and sometimes can offer up a preview of more things in the future. However, these short adventures also can pave the way for players to try out things, with limited scope, and allow them to fail fast, due to the nature of these quests. In Agile, the idea of failing fast is important, in that, the earlier we discover problems with our original implementation, the easier and less expensive it is to cut your losses and pivot to another solution. Time and again, research has shown that discovering bugs late in the development cycle, especially once the software is generally available, is costly to an organization in terms of money and reputation. The goal of failing fast is to create very short and tight feedback loops, so that we can learn and carry these lessons forward in our next endeavor. If the lesson is missed, then failing fast just creates unnecessary noise and angst for development teams, and can easily destroy morale.

I now have a better appreciation of my husband’s methodology in game play and realized that certain Agile ideals can find their way into everyday life, and can offer us lessons in how to generally approach problems.