Roadmaps

Introduction

Roadmaps are one of the most useful tools in a company. Part planning tool (both short and long term), part communication tool, they’ve always proved their worth. Here we’ll cover their benefits together with some guidance as to good practices and how to extract the most value from them.

Roadmaps

When you think of roadmaps, are you thinking of vague broken promises from a product pitch? These aren’t the form of roadmap we are covering here. The roadmaps we’re looking at here are internal planning tools.

Working without a roadmap is like walking without a map. Blindfolded. Into a minefield. With buried treasure to be found.

From a product management perspective, it’s essential to have an idea of what the future holds, some aspects may be set in stone, others unclear or unknown - dependant upon the outcome of earlier versions or decisions elsewhere. It’s easy to become lost, confused or forgetful and this is where a roadmap helps.

Clarity is especially important when expanded beyond an individual to a team, an organisation or even outside parties. It’s not good enough for plans to be in someone’s head - everyone should have visibility of the roadmap as there are often cross-dependencies. Changes can take many months of planning - being forewarned is critical to avoid delays.

A given feature can be developed with an eye to the future - but only if the future is known. For example in the field of authorisation, are users individual - or grouped under a company with different capabilities? Knowing what’s in plan speeds up future development by avoiding unnecessary changes and possibly bringing features forward if it makes sense to tackle several related changes at the same time. Conversely, explicitly marking aspects as out of scope or far down the line gives the developer freedom to delay decisions or take shortcuts. This is why my mantra is “Plan for version 2”.

Whilst issue trackers are essential tools for tracking development, they can be overwhelmed with feature requests and other improvements. A roadmap can be useful here to gather all ideas and possibilities together into a single place and group them by area. These may link to actual tickets if known but it’s certainly not required.

The path

Of all the benefits that roadmaps bring, one of the most useful is showing the paths ahead. Most changes and improvements are made in small steps. A roadmap makes it easy to ensure that those steps are in the right direction towards the (moving) goal. It’s too easy for small improvements to be in the wrong direction - fixing something in the short term but creating additional work in the long term. You might be well aware that you need to re-architect a component, this shouldn’t stop gradual improvements in the current implementation as long they don’t impact the following steps. For example, moving a datastore from a flat store to an MSSQL database would be a bad idea if you wish to later move the service to a Linux server. However, moving it to a PostgreSQL instance would make sense.

Devouring pachyderms

Eat an elephant one bite at a time

When you have a big-ticket item it’s best if you can tackle it in steps. It’s good for morale to show progress by delivering continuously rather than in one big chunk after a large silence. Your manager will also appreciate seeing progress rather than promises. Potential show-stoppers will also be uncovered earlier.

Sometimes big-wins result not from a single large endeavour but a serendipitous collision of other improvements. For example at one company, we supported several applications, some of which were not valuable in themselves, only as technical test-beds for other, more valuable applications. By improving our ability to rollout and isolate changes to those valuable applications (via improved testing, feature flags and cohorts) we could then decide kill off the unimportant applications, freeing valuable development time, reducing costs and increasing the overall quality of the portfolio. The roadmap was very helpful towards achieving this - whilst the dramatically improved testing capability was the “big ticket” item, the roadmap allowed for early discussion about decommissioning the orphaned applications (and the small amount of work there being scheduled). Planned work on “updating” the orphaned applications was cancelled as they no longer served any purpose.

Infrastructure roadmap

As a DevOps team lead, I always have an infrastructure roadmap. This is useful for longer-term planning (e.g. quarterly kick-off meetings), to spot quick-wins, cleanup/deprecated projects, blockers, “shiny” projects (perhaps for hack days) - keeping employees happy is very important.

One approach I’ve used is to have a roadmap on the wiki as an indented list (for grouping), linking to tickets if applicable. Example groups may be:

• Security
• Scaling
• Costs
• Efficiency (of the team)
• Monitoring
• Cleanup
• Deployment
• More specific items (e.g. around Kubernetes, Apache Spark)

The wiki is very lightweight, editing takes seconds and we don’t clutter up any task or project tracker with lots of “maybe” tickets.

As a team, we select the important and near-term items to be tackled this quarter. NB: This is not saying that we will do these - it’s essentially going to feed into our Scrum/Kanban planning. We highlight these items in bold in the wiki.

When planning a sprint or performing periodic Kanban updates (perhaps scheduling some work to be done), the roadmap can be consulted - it’s often useful as a guide and memory-jog. As items are complete, we -strike- them out of the roadmap (leaving them visible).

At the end of each quarter, we perform a review, moving all the completed sections to a new section below the roadmap for historical reference (helpful for performance reviews and to remind yourself of how much was accomplished). We then update the roadmap and repeat the selection process.

Updating the roadmap

Everyone should be able to contribute to a roadmap with ideas (and challenges), the whole team should be included, this is not a tool for the exclusive use of an aloof architect or team lead. After all, it’s normal not only for the company to have an overall roadmap, but for individual teams to have their own - and often these roadmaps will depend upon, (un)block or influence one another.

Whilst roadmaps should be actively updated at least each quarter, they should be opportunistically updated as well - perhaps as the result of attending a conference, or a discussion whilst grabbing a coffee. Often it’s these cross-team “random chats” that make the biggest difference to a company. PS: I strongly encourage making these cross-team chats less random and more deliberate, perhaps go for lunch together more frequently.

Summary

The roadmap is a great tool for improving clarity within companies and teams. With an improved view of the future, planning is more efficient, work more structured with clearer goals and waste avoided. They set a framework for any planning conversations as well as making reviews of progress more straightforward. Most importantly they improve communication between teams and prevent people feel like they are being led into the dark by someone who may (or may not) know what they are doing.