Product Routes (AKA „Roadmaps”)

A journey planner finds one or more suggested journeys between an origin and a destination. Searches may be optimised on different criteria, for example fastest, shortest, least changes, cheapest. They may be constrained for example to leave or arrive at a certain time, to avoid certain waypoints, etc.

(Wikipedia)

The need for safety and a schedule

“Safety” many times is a very important need, followed by “the approach is to work towards delivering something relevant and useful”. That is confusing – isn’t that exactly why Agile Methods were invented in the first place? Because we don’t have safety, because we do want to deliver something useful or valuable?

If we had safety and we knew exactly what has to be delivered and when, we wouldn’t need Agile Methods. So why are we assuming that we are able to manage complexity – we all know that we can’t, especially not with the same toolkit as before.

Many times, we are thrown on a project where the plans are already decided and we have to accept them as they are. Unfortunately, those plans are mostly crap. But that shouldn’t be an excuse for not asking about real goals and value, outcome, behavioural change, to criticize linear Backlogs and unmeasurable user stories. Perhaps the customers then get a clue what Agile is all about, instead of crashing with another sunk cost fallacy experience.

How we can expect to change things that are obviously bad or have proven to be inappropriate or even wrong, if we don’t start arguing against it and instead offer different and especially better solutions? You can say they have some “bad habits” and we should help them to overcome these.

Unfortunately, customers rarely hire external consultants or development teams just hear that whatever they have been doing the last 30 years was totally wrong and that now finally they should foster transparency, trust and other agile values.

In fact, it is far better to embrace this fact than deny it and then be surprised in the end. However, as consultants we must be aware that even if there is no safety, the _need for safety_ does exist. And even more, our customers are often used to be „betrayed“ with a false sense of safety which is only unmasked at the end of a project.

Our suggestion is that we put accepting the fact that customers have the need for safety over teaching them complexity – just as we embrace change over following a plan.

We could start with explaining the trade-offs between the different approaches in a clear way so that the customer gets to choose which paradigms he prefers to adopt. Then, we could consider his plan as a first version of an agile planning process and explain to the customer the difference between a classical plan and planning as a process.

“In preparing for battle I have always found that plans are useless, but planning is indispensable” (Dwight D. Eisenhower)

“malum est consilium quod mutari non potest” – “Bad is the plan that is incapable of change“ (Publilius Syrus, 85-43 B.C., Roman moralist)

As long as the contents of the plan are aligned to the product goals (or even better: the next most promising goal), and not to some features, do have a plan. Asking the customer about its goals, impacts and how much he’d bet on success of them, won’t kill you. But maybe create some new insights and mindset switches.

Next, try to project the plan on a timeline. Not with fixed dates but maybe product increments, quarters, releases, whatever makes sense for the customer. But having a plan means more than just having goals and a good idea how to approach them. It means also having a gut feeling about whether it will take months or years to achieve them.

… and then of course: customer collaboration over following a plan. In other words: Do have a plan. Don’t follow it blindly. If the plan is adaptable, everything’s fine. If you e.g. see after 2 weeks that you are on the wrong road, i.e. your plan does not work because the produced features are crap or no one uses them, or you’ve already achieved your goals, the rest of the plan is now obsolete – and should be changed.

The danger in having a static plan is that you continue following it, ignoring the feedback loops. Agile is doing about the right things, not about doing all planned things, where you have a timeline and x possibly needed features, but no value anymore, or already are overproducing useless stuff.

An agile roadmapping process is pretty close to a car navigation system:
the goal is rather fixed and you want to reach it in the shortest possible time (or the one with the nicest view if you are on a holiday). If the system detects a traffic jam, the route is adjusted, the goal/destination stays the same, just the time to reach it might change. And of course you may want to add intermediate stops (refuel, have lunch, sightseeing) as you go. The system can at anytime predict at what time you reach which stop (and in fact, modern navigation systems are amazingly accurate about this) but it doesn’t really give you a guarantee nor does it force you to stick to your planned stops or even the route. Deviate a little bit and it will recalculate the route for you. Get stuck in a traffic jam? Maybe taking the longer way is now the quickest solution. At any time, the system recalculates the best route for you, based on the most recent information it has. Some systems even offer you multiple options and provide you with information (traffic, building sites, blocked roads) to take your decision about which route to take:

Sometimes you even have to reevaluate the destination: maybe you learned at some point that your actual goal is within a pedestrian area – so you have to adjust your route to find a nearby parking lot.

With enough delay, you might decide that I directly want to go somewhere else. I experienced a couple of times that I needed to be somewhere at a certain time but after getting stuck in a traffic jam, I decided to drive back home and work from there because „my time window had closed”.

And other times you will retrieve new information during your ride that will make your old destination obsolete: we once were on a trip visiting castles in France. We had a collection of 4-5 castles on hand with a route touching all of them but in one castle a visitor recommended a nearby castle which was not on our list, so we dropped one other castle and took that one in.

The other case would be that I got aware that the real f(x) would have been a lucky family and that just visiting the bistro nearby the castle was the real option as kids got icecream and parents were enjoying a glass of wine.

So that’s why we suggest to think of an agile roadmap more like a traveling route or journey.

Finally, here is a small checklist for a route product route:

• make your goal explicit and align your journey to reach it
• revisit your goal after a longer period (e.g. a year) to confirm if it is still the same
• figure out what is the success criterion. Possible candidates are time to market, quality, unique selling point etc.
• put your plan on a timeline. The larger the organization, the more long-termed the roadmap will be. Typically it should reach 6-12 months into the future (depending on the project/product type and the market you’re in)
• make your route accessible, visual and easy to update
• have your roadmap be accurate on shorter term and consciously fuzzy in longer terms
• make sure you revisit and update your product route regularly, typically every month
• remember that stopping the project is always an option. Don’t continue the journey just because you started it.