Roadmaps in an agile team

A colleague and I recently discussed the role of roadmaps in an agile context. He pointed to some books and sources, saying roadmaps are useless or unimportant. This also plays into the #NoEstimates movement.

Specifically, my colleague pointed to the book “Inspired” by Marty Cagan. I hadn’t read the book myself, but I went through the chapters on roadmaps. Here’s a relevant quote:

The issue is that anytime you put a list of ideas on a document entitled “roadmap,” no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment.

- Cagan, Marty. Inspired (p. 111). Wiley. Kindle Edition.

He has also written about this online, such as here. His point is that roadmaps with defined features and deliveries, reduce the team to a feature factory. There’s no leading by context.

I agree with this, but I still do believe and experience that having an idea of what happens when, and being able to communicate this, is necessary in most organizations. The success of the roadmap in any context, depends on what it looks like and how it’s communicated. In general, I find it useful to have a roadmap that gives teams and stakeholders an idea of:

1. The overall business strategy and goals for your product (i.e. context)
2. What are we working on right now, and how that links to goals and strategy
3. Clues as to what problems are going to be addressed in the next iteration or time-box, based on that context. The clues might be suggestions for the OKRs to work on in the next iteration.

In some cases, it also provides and idea of when that iteration/time-box is, approximately

This does not have to be as rigid and difficult as one might associate with a roadmap in a traditional sense. A list of “doing now” and “up next”, with some business context for each item, might do the trick if stakeholders have a product-oriented understanding and mindset.

For this to work, the roadmap must be:

1. Updated continuously, i.e. be a living document
2. In a position where it receives continuous feedback from users and stakeholders, and make sure they “buy in”

When building the first roadmap for a new team or context, I’ve found the approach described in this article really useful. It also adresses how to identify the context your team operate in, which in turn will help you tell the story about why the current work items are the current work items.