Roadmaps

Agile Governance

The type of roadmap you provide depends on your organization’s approach to governance. How does your organization ensure teams are working effectively and moving in the right direction?

The classic approach is project-based governance. It involves creating a plan, an estimate of costs, and an estimate of value. The project is funded if the total value sufficiently exceeds the total costs. Once funded, the project is carefully tracked to ensure that it proceeds according to plan.

The Agile approach is product-based governance. It involves allocating an ongoing “business as usual” budget and estimating the value the team will produce over time. The product is funded if the ongoing value sufficiently exceeds the ongoing costs. Once funded, the product’s value and costs are carefully monitored to ensure it’s achieving the desired return on investment, independent of the actual features delivered. When the value is different than estimated, costs and plans are adjusted accordingly.

A “just the facts” roadmap isn’t a roadmap at all, in the traditional sense of the word. Instead, it’s a description of what your team has done so far, with no speculation about the future.

• Your team’s purpose

• What’s complete and ready for your next release

• Your next release date, if you’re using predefined release dates (see “Predefined Release Dates”)

Additionally, for management roadmaps, Optimizing teams will include:

• Current business value metrics (revenue, customer satisfaction, etc.)

• Current costs

• Business model

Even if management needs a more predictive roadmap, a “just the facts” roadmap can work well for sales and marketing. The advantage of the “just the facts” approach is that no one is ever upset when your plans change, because they don’t know your plans have changed. Combined with a release train (see “Release Early, Release Often”), this can lead to regular announcements of exciting new features that people can have right now.

One well-known example of this approach is Apple, which tends to announce new products only when they’re ready to buy. It’s also common in video games, which use regular updates accompanied by “what’s new” marketing videos to re-energize interest and engagement.

Option 2: General Direction

Stakeholders often want more than just the facts. They want to know what’s coming, too. A “general direction” roadmap strikes a good balance. Speculation is kept to a minimum, so your team can still adapt its plans, but stakeholders aren’t kept entirely in the dark about the future.

A “date and approximate scope” roadmap adds forecasted release dates to the “general direction” roadmap. This reduces agility and increases risk, because people tend to take these sorts of roadmaps as commitments, no matter how many caveats you provide.

That leaves teams with an uncomfortable trade-off: either you use a conservative forecast, such as one with a 90% probability of success, and provide a pessimistic release date; or you use a more optimistic forecast, such as one with a 50% probability of success, and risk missing the date. Furthermore, work tends to increase to fill the time available, so more conservative forecasts are likely to result in less work getting done.

However, because the roadmap doesn’t include the details of each increment, the team can still steer its plans as described in “Predefined Release Dates”. Rather than forecasting when every story will be done, make a conservative forecast for the “must have” stories in your plan and treat it like a predefined release date. This will give you a forecast you can meet without being too far in the future. Then, if you end up with extra time—and, if the forecast was truly conservative, you usually will—you can use that time to add polish and other “nice to have” stories.

Optimizing teams usually don’t use this sort of roadmap. The business cost isn’t worth the benefit. However, it can be useful when they need to coordinate with third parties, such as for a trade show or other marketing event.

Option 4: Detailed Plans and Predictions

This option is the least Agile and has the greatest risk. It’s a “date and approximate scope” roadmap that also includes every story in the team’s plan. As a result, the team can’t steer its plans without having to justify the changes. This results in more conservative forecasts—meaning more potential for wasted time—and less willingness to change.

Although this is the riskiest type of roadmap, organizations tend to prefer it. It feels safer, even though it’s actually the least safe approach. Uncertainty makes people uncomfortable, and this roadmap allows them to speak with certainty.

That certainty is an illusion, though. Software development is inherently uncertain. Artificial certainty just makes adapting to changing circumstances more difficult.

Sometimes you have to provide this roadmap anyway. To do so, make forecasts that include every story, not just the “must-have” stories. As with option 3, you’ll need to decide between conservative forecasts, which are reliable but potentially wasteful, and more optimistic forecasts, which you could fail to meet.

Teams without Focusing and Delivering fluency typically have a lot of risk, which means that a properly conservative forecast will show a release date that’s too far in the future for stakeholders to accept. You’ll typically have to use a less conservative forecast, even though the date is more likely to be missed. One way to work around this is to forecast only near-term releases, if you can. “Reducing risk” has more details.

Optimizing teams don’t use this type of roadmap.

Corporate Tracking Tools

Companies will often mandate that their teams use a so-called Agile Lifecycle Management tool, or other planning tool, so they can track teams’ work and create reports automatically. This is a mistake. Not only does it hurt the team—which needs freeform visualizations that it can easily change and iterate—it reinforces a distinctly non-Agile approach to management.

Agile management is about creating a system where teams make effective decisions on their own. A manager’s job is to ensure teams have the information, context, and support they need. “Agile” planning tools are anything but Agile: they’re built for tracking and controlling teams, not enabling them. They’re an expensive distraction at best. Don’t use them. They will hurt your agility.

That doesn’t mean teams have no guidance. Management still needs to keep its hands on the wheel. But this is done by iterating each team’s purpose, providing oversight and feedback during stakeholder demos, and using the most adaptive roadmaps possible, in addition to effective and engaged team-level management.

If your team is required to use a corporate tracking tool, enter only the information required by management. Use the other planning practices described in this book for your day-to-day work, copying information into the tool when needed. If your roadmap only includes valuable increments, not stories, this won’t be too much of a burden.

If you have to include stories in your roadmap—which I don’t recommend—see if there’s a lightweight way you can do so. Perhaps you can take a picture of your visual plan rather than transcribing the cards into a tool. Perhaps managers should be more involved in planning sessions, or perhaps they’re asking for something they don’t actually need.

If they insist, though, you can transcribe stories into a corporate tracking tool. Do it once per week—or daily, if you have no other choice—and remember each story should be only a short phrase, not a miniature requirements document.

If managers need you to maintain more detail in the tool, or insist on tracking individual tasks, something is wrong. Management may be having trouble letting go, or your organization may not be a good fit for Agile. Ask a mentor for help.

When Your Roadmap Isn’t Good Enough

Eventually, somebody is going to ask you for a roadmap with a date forecast, then tell you that the forecast is too far away and you need to deliver sooner.

You can try improving your capacity (see “How to Improve Capacity”) or further developing fluency, but start by cutting scope. Those other efforts take time, and their impact is hard to predict. If they pay off, you can put the cut stories back in.

Sometimes, you won’t be allowed to cut scope. In this case, you have a tough choice to make. Reality won’t bend, so you’re stuck with political options. You can either stand your ground, refuse to change your forecast, and risk getting fired; or you can use a less conservative forecast, provide a nicer-looking date, and risk releasing late.

Before making that decision, look around at the other teams in your company. What happens when they miss their dates? In many companies, release dates are used as a bludgeon—a way of pressuring people to work harder—but have no real consequences. In others, release dates are sacred commitments.

If you’re trapped in a situation where your roadmap isn’t good enough and you don’t have the ability to cut scope, ask for help. Rely on team members who understand the politics of your organization, discuss your options with a trusted manager, or ask a mentor for advice.

Remember, whenever possible, the best approach to forecasting is to choose a predefined release date and steer your plans to meet that date exactly.

Questions

How often should we update our roadmap?

Update it whenever there’s substantive new information. The stakeholder demo is a good venue for sharing roadmap changes.

What should we tell our stakeholders about forecast probabilities?

In my experience, forecast probabilities are hard for stakeholders to understand. I provide a range of dates, but don’t go into detail about probabilities.

If teams don’t report their detailed plans, how do team-level managers understand what their teams are doing?

Team-level managers can look at their team’s planning boards directly. See “Management” for more about managing teams.

Prerequisites

Anybody can create roadmaps, but creating effective, lightweight roadmaps requires Agile governance and a willingness to allow teams to own their work, as discussed in Chapter 4.

Indicators

When you use roadmaps well:

There are many ways of presenting roadmaps, and I haven’t gone into details about specific presentation styles. Experiment freely! The most common approach I see is short slide decks, but people also create videos (particularly for “just the facts” roadmaps), maintain wiki pages, and send status update emails. Talk with your stakeholders about what works for them.

Johanna Rothman has a nice discussion about managing expectations in chapter 7 of Behind Closed Doors: Secrets of Great Management. [Rothman2005]