If Not a Roadmap, Then What?

I've been wrestling with this question. Roadmap are so integrated in development processes that it's hard to think about processes without them.

• How do we know where we're going?!
• How will people know what's going to be worked on?
• How do we manage dependencies?

Even so, do roadmaps actually answer those questions, or do they just appear to answer them? I've not seen a roadmap ever match up to reality.

One approach is a strategy with just-in-time scheduling. The strategy provides the context needed to know what to work on. The just-in-time scheduling allows the right things to be worked on at the right time.

The Shape Up methods from 37 Signals have this same idea, at least the just-in-time scheduling.

How do we know where we're going without a roadmap?

A strategy. A strategy is defined in many ways. In this context the important parts are the vision or mission, the objectives, the values, and key performance indicators.

The vision/mission is the reason the company exists. It answers why a company does what it does.

Objectives expand on the vision to set guides on how the company wants to achieve its vision. These are high level objectives that highlight the company strengths.

The company values help people choose the best path forward for the company. There are many ways to achieve objectives, but some aren't acceptable. Values provide the context to choose a way forward that aligns with the company.

Lastly, KPIs provide a way to measure progress toward the company objectives and ultimately the company vision. This is how you know progress is being made in the right direction.

Great! But what are people going to work on!

They're working toward the vision. What else matters? Do you really need to know that a specific team is going to implement a certain feature in Q4? Have you ever seen that actually happen? By the time Q4 comes around, either the feature isn't important anymore, or more commonly, the team isn't ready to work the feature yet because of other unforeseen events prior to Q4.

Maybe. But how do we manage dependencies?

This is where just-in-time (JIT) scheduling comes into play. JIT scheduling is an idea from Shape Up that makes a ton of sense.

The idea is that you don't know what to work on next until you're almost ready to work on what's next. At that point, you can look at options for the next cycle and choose what moves the company toward the vision the most.

If you have something that is dependent on prior work, you can either wait for the dependency to be done or see if there is a better way without needing the dependency.

I know this sounds scary. But most of the time, roadmaps are just planning theater. They waste time and effort. They rarely match reality.

This won't scale to my company!

Maybe not. I don't know. One way to scale this is to create a strategy for each team that rolls up to the company strategy.

The Shape Up book has good ideas and is definitely worth the read.

Photo by Felix Mittermeier on Unsplash