Reading the map

Outcomes-orientation

What's this about?

Software project roadmaps are a powerful tool for orienting an outsider to the current state of affairs in the life of a service.

Lesson outline

• Conceptual: What kind, when? (1h, solo)
• Understanding a map (30m, solo)
• Reflecting on a map (30m, solo)
• Sharing experience (30m, small group)
• Discuss in community (1h, group)

Roadmaps are a tricky thing. They are a space where development teams can lie to leadership, vendor leadership can lie to states, states can lie to SOs, and everything can look like it is perfectly on track.

Roadmaps can also be a source of radical transparency, where something approaching the ground truth of the project can be ascertained. But that assumes that the vendor and state are in agreement around what a roadmap can and should be.

There are many kinds of roadmaps and many ways they might be implemented. As an SO, you need to have both 1) a conceptual understanding of what a roadmap is as well as 2) a practical/applied understanding, so you can either praise the work you see or demand improvements that give you better visibility into the health of a project.

As you engage in your reading and viewing, remember to make note of questions that you have about the material.

Conceptual: What kind, when? (1h, solo)

There are many kinds of roadmap. When it comes to categorizing things, I sometimes find it is good to start with a spectrum, or grid. That is, I like to find a way to “position” what I’m looking at.

Government as a stable market: When working with software in a government context, we are not really dealing with a market. That is, we’re talking about things like case management systems, which are not (sadly?) rapidly evolving tools. We’ll therefore assume that a government “marketplace” is stable.

This suggests that we might be looking at a theme-based roadmap or a feature-based roadmap.

Theme-Based Mapping

The first half of Janna Bastow’s slide deck on Agile product roadmaps (Creating Agile Product Roadmaps Everyone Understands) is a really good read.

You can either read through the deck or you can watch Janna present it.

As Janna says, a good theme-based roadmap is going to communicate:

• Time horizons (current/near term/future)
• Objectives
• Scope
• Product areas that any given work effort will cover.

Where I think her deck tells a little lie is in the second half: it suggests or implies that you can start with vision, get to goals, and somehow work your way down from there.

Done right, the team starts with user stories, and works their way up to the product vision. David Hawks has a nice article (Story Mapping 101) that captures how a team should generally go about building up a story map.

To sum up, a story map will generally suggest this kind of thinking:

But a story map should be built the other way:

I highlight this because we’re going to be talking about how the states and vendors work with real users later, and if they haven’t been, it may already start to show up in the theme map. This is all important context to understanding a roadmap when you’re handed one.

Feature-Based Mapping

A more mature product is going to be more focused on features and feature delivery. This makes sense once a team is well-gelled, communicating openly with the partner, and continuously delivering features and product on a bi-weekly basis (this is the essence of agile software development).

A feature-based map may look a bit more like either a goal-oriented product map (a GO map) or a now/next/later map. Robbin Schuurman has a nice overview of both of these kinds of maps (Tips for Agile product roadmaps & product roadmap examples) that describes these. Again, give this a read and then come back.

All The Details

Storymapping and product management is a whole set of subjects unto themselves. If you want to read more, you might browse:

• Atlassian’s Agile Coach website
• Bree Davies has a nice article on roadmaps (Product Roadmaps) that provides some additional context and background.

We don’t want to bury you in material, so if you have time, give it a go. If not, go ahead and move on. This learning will require you to revisit sources from time-to-time as you encounter new situations and challenges, so fear not… there is more to be learned than can ever be learned…

Understanding a map (30m, solo)

Timer: (30m timer)

You’ve seen roadmaps as parts of projects before.

Pull one. Go back to a recent roadmap from one of your projects and look at it. Then answer these questions for yourself in your notebook. These questions are less reflective and more descriptive in nature; they mostly question the what and how of the map.

1. What is the vision for the product or software?
2. What value does it offer?
3. How will it improve things for the end-user? The partner state/agency?
4. Why is the vendor well positioned to deliver this value?
5. Who is the user of the product?
6. What do those users care about?
7. What metrics are being used to define success?
8. Can those metrics be used over time to track progress?
9. Is the value of this solution greater than the cost of switching vendors?
10. What makes the product unique and continued investment defensible?
11. Does the implementation team have the capacity to do the work?
12. How much time and resource will each part of the map take to implement?
13. What time pressures exist?
14. Does the roadmap maximize the use of resources along the way?

These are fairly common roadmap questions.

Reflecting on a map (30m, solo)

Timer: (30m timer)

These questions are of a different nature. The previous set of questions asked you to make some judgements… but, really, they’re questions that a good roadmap should almost answer for you.

Your job as a State Officer, M.D. is to probe deeper. If you have a healthy relationship with your state and their vendors, these questions will be easy. However, it might be that the vendor is concerned about holding on to their contract, but less worried about delivering excellence and value to the state. In that case, you’re going to need to ask bigger, harder questions about the roadmap.

1. Was the roadmap written with a general audience in mind, or does it use technical terms and make things complex where they might otherwise be simple?
2. Is it up-to-date, or is the same roadmap used over-and-over, from one cycle to the next?
3. Does the roadmap over-promise? Does it magically suggest that a perfect, finished product will be delivered some time in the future? Or does it have reasonable timelines with achievable goals?
4. Does the roadmap include places where users will have input, and that input might shift the direction of the product as a result?
5. Is there any indication that all of the critical stakeholders (developers, product team, the partner state or agency, and end-users) were consulted as the roadmap was brought together?

Sharing experience (30m, small group)

Meet with your small group and connect what you learned in this lesson to situations you’ve seen with your state projects. Consult the notes you took throughout the lesson and try to link them to a story that you can tell about a particular project. It’s probably useful to do some brainstorming on this before you meet with your small group to trade stories.

When you get together with your small group:

1. Share your stories with each other.
2. Figure out which ones are the best candidates for a case study or use case that would be helpful to share with other state officers.
3. As a group, choose useful stories and write notes on how they link up with the concepts shared.
   • Include in your notes:
     • When did this story take place?
     • What were the events or background leading up to this story?
     • How did this story demonstrate an ideal or non-ideal situation?
     • What specific principles from the lesson does this story illustrate?
     • If the story shows an ideal, what were the conditions that made it work? How did it fit with the principles shared in the lesson?
     • If the story shows a non-ideal, what could have changed to make it better?
4. Share these notes with the larger group when you meet.
5. After discussion with the larger group, document these stories and their connections to the lesson to help other state officers understand how this lesson’s concepts apply to their work.

Discuss in community (1h, group)

These questions are all meant to help you get at this one dimension of the rubric:

Come together with your colleagues for a conversation.

You can click on the timers below to help keep yourselves on track.

1. Check in. (5m timer) First, check in with each-other. How is everyone doing? Take a moment to share something positive from the week, either at work or at home.
2. Understand. (20m timer) Next, take some time to discuss points where you were confused or questioned your material. Did you find yourself questioning or wanting to challenge the authors at any point? Did you want to call “bullshit” on what they were saying based on your own personal experience? This would be a great place to probe ideas; help each-other unpack why you feel this way about the readings.
3. Reflecting. (20m timer) You each had your own roadmaps you investigated and questioned; take a few minutes each to share the roadmaps you scrutinized. Focus on two things: areas where you thought the roadmap was excellent or clear, and areas where you were concerned. For each roadmap, as a group, offer suggestions for how you would like to see the state and/or vendor improve the roadmap in the next iteration. This could be in the form of questions that you want to ask, or it can be recommendations.
4. Questioning. (10m timer) For the last few minutes, take some time to expand the questions that we asked about roadmaps. You have your own experiences as SOs, and those experiences should inform your inquiry. What questions (in addition to the ones asked as part of your solo work) do you think you should be asking of each new roadmap that you see? Make sure to share those questions back, so they might be incorporated into future versions of these learning materials!

In the guides

This lesson is the beginning of a journey. If you're interested in learning more, there's material in the 18F Derisking Guide that you'll want to check out.

From the Federal Field Guide:

• Product ownership
• Empowered product owner

From the State Software Budgeting Handbook:

• Product ownership
• Beware customized commercial software

Wrapup (5m, solo)

Take a few minutes to share your reflections on this lesson.