That’s not a Road Map
Have you ever been presented with "road maps" meant to explain business and engineering plans? What did they look like? I’ve encountered my fair share of those, but I haven’t seen a single one that’s actually what it claims to be. Many were little more than a complete waste of time.
The thing is, I believe road maps are extremely useful and are absolutely necessary for proper development planning. I'll show you how they fit right in and can help with being truly agile, making decisions, addressing technical debt, and aiding in communication. Disagree? Maybe you're thinking of those from the opening paragraph? I'm not. Read on.
The worst I’ve seen
This is my "favourite" bad example. These "road maps" portray where the business is meant to be in financial terms over time. I say "meant to be" because this isn’t about forecasting based on the present state. That’s the actual “plan”. Here’s another way to phrase this: “We’ll be rich.” I could create lottery-winning road maps this way. Typically, these don’t provide much (or any) information about how to achieve those "goals". I guess that’s left out for others to figure out.
This is not a road map; it's wishful thinking. Not only does it fail to indicate what needs to be done, but it also implies control where there is little or none of it.
Typical “Road Map”
Does this appear better than the previous one? It illustrates what needs to be done. Allow me to emphasize a word in “road map”:
Road Map
Do you see it? I emphasized the word “map”. Does this example resemble a map to you? A map of roads? No? It doesn’t, does it? At best, it resembles a chosen route or path.
Now this is a road map!
Work maps
In software development, we don’t travel on real highways. Our journeys involve keyboards and mice. Their lengths aren’t measured in kilometers or miles but in work, the effort required to accomplish something. While units of time (duration) might seem commonly applicable, we're usually not traveling just from “A” to “B” with a single vehicle. Our engineers do multiple things concurrently, aiming for multiple accomplishments.
We have "states" (referring to "conditions," not "territories") instead of cities, towns, and other places.
We have "work" indicating possible ways to transition from some states to others. It's important to note that certain destination states might require multiple different types of work to be done simultaneously, resulting in multiple incoming "work" lines. These lines don't represent distinct options but rather required combinations.
We use units of work to express (estimates of) how much work we're discussing. If applicable, we can additionally or alternatively use the "cost" of doing that work, including financial considerations.
"Hey, that looks just like a workflow!" you might say. You'd be right! It does. However, there is one important difference. Workflow diagrams focus on the work to be done, and the states in between are not necessarily desired. Here, we care about both. Specifically, product and business leadership understand and value the states, while engineering focuses on the work's details. Both groups are concerned about the amount of work and the associated costs.
Where can I get those?
Well, that’s the issue. They don’t create or sell them. We're all on a mission to explore strange new worlds, to seek out new problems to solve and new markets, to boldly go where no one has gone before. Making those maps is not easy:
You can only map as far as you can see.
The farther away something is, the less accurately you can map it, or even see what it is.
Nobody has ever been where you are now, so even if they may be heading in a similar direction, they can’t help you much. Even if they could, they probably wouldn’t volunteer to do so.
Nobody, not even you, cares about where you’ve been and how you got to where you are now. What you mapped in the past is irrelevant.
The "world" is constantly changing. New "roads" and "cities" are continually being built and demolished. Some routes may become faster than ever before due to new vehicles and road improvements, while others, abandoned, may become slower.
Is that too challenging? Well, perhaps. What you need to consider is how extensive your map needs to be, how much detail it requires. Obviously, attempting to create a comprehensive map of everything is impractical, as the world will change significantly multiple times before you even finish conceptualizing what your map has yet to become.
However, we don't need that level of detail, do we? We only need enough of a map to choose the best route(s) toward our general destination. It's acceptable if we are uncertain about distant matters – we are willing to take some risks. This is about managing those risks and not aimlessly wandering, hoping that random turns will eventually lead us to our desired destination.
Example
In this example:
Blue circles with thick outlines represent the current state(s).
Green rounded rectangles represent the states we are considering as possible "destinations."
Pink/red non-rounded rectangles represent work that could be done, with each having a cost/effort included in its bottom right corner. Since this is only an illustration, I don't need to specify the units I had in mind; you can use your own. Values are somewhat arbitrary but are based on actual or past experiences.
Arrows represent possible "routes." Note that they are unidirectional, not bidirectional.
Small solid circles represent junctions that require all incoming route arrows to be completed. In all other cases, any one route is enough to reach the desired state.
In this case, I used shading to indicate increasing uncertainty ("fogginess") based on how distant the future is. While not strictly necessary, it proved to be a helpful visual aid. If shading isn't available, relevant boxes could be marked with an increasing number of question marks or similar decorations.
Notice that there are multiple paths (options) leading to various destination states. If you attempt to add up the numbers, you will see that different paths will require different amounts of work and bring other destinations closer or farther away — making them either more easily reachable or not.
This is a complex but comprehensive example. It appears very busy and may not be suitable for all audiences. If detailed work information is not necessary for the discussion, a simplified version can be easily (even automatically) created with work estimates rolled up (combined):
What was that about tech debt?
What technical debt? Did I forget to include it in the above example? Maybe I did, maybe not. What exactly is technical debt? It could involve some desired tasks. What effect would it have? Would it speed up development, open up possibilities, or improve quality? All of these require effort and result in specific outcomes, which we can illustrate on a "work map." There is no distinction between technical debt and other tasks. They are presented equally and made equally visible, not hidden under a rug. The consequences of addressing this work (or neglecting it) become immediately apparent and aid in the planning process.
Parting words
Planning a journey requires at least some idea of where we want to go. Making the right decisions requires considering more than one option. Making the right decisions in the face of knowing our direction requires us to evaluate options not only based on immediate effects but also on those that follow. This is where roadmaps, or “work maps,” come into play. They organize and facilitate clear, honest communication between stakeholders. Yes, they do require effort, but it's the effort you'd have to put in anyway if you wish to be diligent. You don’t have to map out the entire universe; just enough to manage risks. They aren’t plans, they allow agile planning and readjustment of those as necessary.
I highly recommend using them.