In my last post I wrote about why roadmaps are for everyone. This post is about techniques for building one and how the use of language can help align your pure agile or mixed methodology programmes.

In government service delivery programmes there's always a mix of methodologies between agile and waterfall. Some of this is cultural, some of this is for practical reasons. The techniques I describe below fit within this context.

The prerequisites

The prerequisites for a good roadmap are good leaders and clearly articulated goals. If your future is driven from above by preconceived thinking or your teams don't emotionally buy-into the programme's goals it's not a happy place.

Good leaders set and articulate goals that inspire you.  They allow teams to challenge the seemingly sacred.  They empower them to come up with creative approaches to achieving strategic goals.  If you don't have these then your roadmap could end up as an exercise in group-think.

Ask 7 simple questions

Gather the team and your subject experts (e.g. ops, legal, security, policy, HR) and ask yourselves these questions*:

1. What are we trying to learn or prove?

2. Who are the users?

3. What are we operating?

4. What are we saying?

5. What are our assumptions?

6. What are our dependencies?

7. What capabilities do we need?

A timeline is not dirty

The Waterfall methodologists feel comfortable with long timelines.  They typically work 'right-to-left' from a desired delivery date;  the agilists prefer to work iteratively, 'left-to-right' as much as, and where possible.  Whatever your preference, timelines are important and an inescapable part of delivering.  A timeline is not a dirty concept.

I start this conversation by sticking post-its across the top of a wall with time intervals running left to right. I use 3 or 6 monthly intervals over 1 or 2 years, but whatever is right for you. Choose a timeframe that creates some discomfort for your colleagues to think beyond the immediate "deadline" in everyone's head and to get them to think strategically.

Place known, real or imagined, time constraints and events across the top too, maybe on a smaller or more muted colour post-it so they don't become the only focus of conversation.

You get better roadmaps by asking questions

The language you use is important. Asking everyone to answer questions is good for finding common ground and helps get better inputs. Asking "What are we trying to prove or learn?" for each time interval helps people think about the evolution of your service and grounds it in iterative delivery.

The agilists are used to thinking about learning and value-based incremental delivery. They feels comfortable with it.  The waterfall methodologists typically think more about deliverables. That's OK, you can easily ask what are the outcomes they want from it? What will it prove when we deliver it? What will we learn from delivering it?

Ask how we measure stuff and set some sensible targets. These be your performance indicators (KPIs) and a step towards an awesome dashboard for your programme.

Who are the users? Everyone wants to deliver for users so no controversy.  No one is itching yet.

"What are we operating?" gets people thinking about the service as a whole and how it will work and evolve over time.  Talking about it with everyone helps. It gives teams focussed on digital a feel for challenges of the Operations folks (e.g. in the job centre, in warehouses, on the service desk) and Operations get to say how they want to rollout and operate it.

Capture assumptions and dependencies whenever they come up in conversation.  That always helps bonding.

A roadmap can write your comms plan for you. By asking "what are we saying?" (to your organisation, your users, the press) for each time interval you are telling the story of your evolving service.  The Comms folks are now itching but I think it is excitement not concern.

Capabilities are to do lists for everyone

Finally, "What capabilities do we need?" (to operate the service). I find everyone gets the word capability after a gentle nudge (e.g. pay, inbound-telephony, search, dispatch, training). Add a description and an owner to each one if you can. Describing them and giving them a label is hard but both the agile and waterfall camps understand the word and can come up with a sensible list of them.

The agilists, especially the architects, can begin to see the beginnings of their systems, the epics and minimum-viable features within their backlogs. The waterfall folks can imagine their gantt charts and what needs doing by when.

Show it off. Get people talking about it

These techniques give you a holistic view of the service from a near standing start. This exercise does not answer everyones' questions. There's still uncertainty and no one feels 100% comfortable with the unknowns, but you have the backbone of a strategic approach. One that is grounded in user centred, iterative delivery and provable outcomes.

Everyone can take something away with them and use it to inform their own planning activities - whatever they are. Turn it into an illustration if you like. Present it to important people. Keep pointing at it, talking about it and improving it.

This is your roadmap.

* I want to credit Richard Pope who came up with some of these questions on the hoof when I did this for the first time. I've run with them and tweaked.