fog_of_war_agile.md

The Scout's Guide to Agile!

Mapping the Fog (and why it's not corporate BS).

You have a project? Cool! Do you know what you want to do next? Then don't put your hands on the keyboard yet!

Or maybe you're already halfway through one, only to realize you got lost in a big forest of what-ifs and unknowns and what-abouts and now it's gonna be a hell of a journey just to climb your way back on track.

Here's how you break down a project into tasks organically, while still affording to change directions when necessary.

First, you break down a project:

1. Your project is like a root task that's too big to be a task. Think about its components. Those, we can call topics.
2. Now, think about the very first topic you should work on to start the project.

Did that? Great! Write that somewhere. Now, does that tell you what you can do right now? Not necessarily! And if you're working on a team, divvying up that work can be a mess. So let's work smart, not hard.

1. Split each topic you identify, or at least the one you want to tackle now, into tasks.
2. For every task, try to define a 'size' for it, usually called Story Points in the industry. This isn't a strict measurement, it's more of a subjective vibe that tries to nonetheless sum up three areas: Effort, Complexity, and Risk. A good idea is to use the Fibonacci scale - 1, 2, 3, 5, 8. They aren't actual measures, but they do reflect the fact that, the bigger an effort is, the harder it is to foresee the size of the effort.
3. For any task, if the vibe exceeds 8, this task is too big and is either best fit as a topic, or should be split into subtasks. You can mark those as dependencies if you're feeling fancy.

Now that you've split your work into tasks, it is easy to digest. Notice that you actually gave yourself a few boons:

• You have sized tasks. You can pick a task accordingly to how you're feeling in a day. For example, pick smaller tasks on flu day, or bigger ones when you're well and caffeinated and oiled up for the trek.
• You also have multiple tasks. You know what they say about parallelism? You can now assign each task to a different person, as long as they don't conflict with each other or aren't blocked by another pending task! A mountainous region is most quickly discovered when each scout goes down their own mountain pass with their own binoculars all at once.

But hold up! I can see you're about to try to divvy up the entire project into a huge map of tasks from point A to point Z.

Don't do that.

You can't map the whole project now. Think of it like fog of war: the entire world is covered in fog. Except around where you are right now. This is Start, the base camp. You have an extremely vague idea of what the world looks like, but you only know well the next couple of steps forward; that's how much of the world you can see because it's near where you already trekked. As you venture into this world and work on exploring it, more areas are gradually revealed, so your initial idea of how the world looks like - which is almost certainly wrong, not because of you, but because of the fog of war - can be readjusted.

If you try to tackle the whole foggy world by how you think it looks without first mapping your surroundings, you'll end up getting lost, and probably jumping off a shoreline or something. Instead, map as you go.

This means you

1. Get the first tasks done.
2. Observe what new insights this opens up about the next stages you had in mind.
3. Now, you can rethink those next stages, if necessary, using the insight you gained by getting those first tasks done.

For example, if you start working on a game thinking it's simple enough that you won't need ECS, but then see yourself doing a lot of boring static dispatches or coupling different object types in ways that are iffy, well, and find yourself yearning for ECS, that's not a bad thing. That means you had an initial idea and you refined it through experience. The key is in being able to pivot and change plans as early as possible, because earlier pivots always involve less effort and difficulty than later ones. Or, you're working on a website, thinking you can just copy the colors of your color palette to every page, and then you realize you want to change a single color in your palette, and think to all the elements and rules you'll have to update now... uh oh. I didn't need to... paint... myself into this corner! (badum tss.)

What this usually translates to in practice is:

1. Every set period, like every week or every x tasks are done, you think back on what you did.
2. You think forward to the other topics you had planned.
3. You consider whether the original plans stil make sense, given what you learned from what you did.
4. If they don't make sense, you must feel free to completely change the original plans without guilt or shame. This is the most important part!
5. With your new and improved plans, you can start a new cycle!

Rinse and repeat until you achieve the original goals you set out with, or perhaps even an updated version of these very goals.

As for how much land you should cover on each cycle, each leg of the journey? Don't try to guess ahead of time! Trek at your natural pace, muddy as the swamps may be dragging on your feet. Once you know more or less how your usual natural pace is, that is incredibly helpful in helping you pick your future tasks by how you estimated their size, so you know you aren't trying to extend the next leg of the journey much further than you can do with the suppĺies in your backpack and overextend yourself... or burn yourself out.

In real life, usually you're not the only one who's going to be identifying pivots. You'll often be working with a client, who only has a vague idea of what what they want would actually look like, regardless of whether they're a programmer or not. This isn't because the client is dumb, this is because of the fog of war! Anyone who doesn't own a crystal ball is going to be unable to know what a project's finished state will look like exactly. This means that what they want will also evolve as the project evolves, so in the reevaluation stage, multiple inputs may need to be considered. The more often you meet to update from your own new insights and the client's, the more quickly you can pivot!

In other words it's all about being able to gradually probe the fog of war, dissipate it where you can, and, when it reveals you're starting to veer off course, adjust agilely. Hence, Agile.

A Scout's Dictionary for Foreign Exchange

In the forlorn hills of business lingo, thou mightest hear the folowing words. Here's a quick reference to what they actually mean:

• Epic - broadly speaking, a task or topic that's way too big to be done all in one go; an idea of an effort that must be split to be digested, divided to be conquered.
• Task - in Agile terminology, a task is something you can actually do in a manageable amount of time, preferably within a single day, sometimes a few, but never more than within a Sprint (see below). Usually, this amount of time is very loosely, if at all, correlated to this task's estimate of size, usually known as Story Points (see further below).
  • If you're not sure what this 'loosely' truly means, a good rule of thumb that most people follow is that a size-1 task should take about 15-30 minutes, a size-2 task can take about 1 hour, and a size-5 task can take, mm, 4-8 hours maybe. See, that's what I mean by loose and fuzzy!
• Sprint - the cycle period discussed above, which is staggered with retrospectives and adjustments. It's you updating the map after vanquishing another region of fog.
• Point or Story Point - the vague, subjective, undefined unit of measure for the estimated size or complexity of a task, relative especially to one's own disposition. While the Fibonacci scale I described above is the most common style, there's all sorts, including non-numeric ones.
• Blocker - a task that must be completed before another task can begin. Think of it like terrain traversal that requires setup, like upping a bridge or fording a river.
• Backlog - all the tasks that you've written down and are intending to do at any point of the journey. The most well efined ones are usually those pertaining to this cycle (or this Sprint - see above). You don't need to finish all of them for your cycle to be successful, and not all of them might even be the right ones to begin with! - which you'll find out as you progress. Remember, the further away somewhere is, the harder it is to map that place; such is the life of a cartographing scout.

There's probably hundreds of other crazy words out there, but if you want to learn about all of them, you should read one of those boring 200-page corpo guides anyway. Or, you can get more grounded practical information from a real guide, like the Extreme Programming guide.

But this is just a primer on a particular methodological philosophy and what it actually means without that layer of corpo BS. I hope it helps you trek through the fog without losing your mind while bogged down by the demands from your superiors. Have a safe voyage!