On leaving the Civil Service

Last week I left Government Digital Service and I'm now no longer a Civil Servant.  I had great fun so I thought I'd capture my highlights and share some pictures that sum it up for me.

Here's the things I enjoyed most:

1). Building and being part of the team that launched GOV.UK - from a blank sheet of paper through to 1 billion visits and a £60m saving for UK tax payers each year. I had so much fun disrupting the status quo, helping to establish an agile service delivery culture across government. Agile is now the new normal for service delivery in government and that's a little bit to do with starting the alpha version of GOV.UK, forming an incredible team that showed the art of the possible and which exemplified a culture of delivery.

2). I'm proud of the part I played helping reset Universal Credit, the UK's welfare reform programme. It's a sensible policy, with cross-party buy-in but it was in a bit of pickle in 2012/13. I helped form the cross departmental, multi-disciplinary team that will deliver a future welfare system, designed to be fairer, a little more human, a lot more agile and responsive to feedback from users. That's totally a win for the Civil Service and the UK - against many odds.

3). Getting to work on briefs like this - and I'm paraphrasing: "Imagine it's 10 years from now...  Without messing with democracy ('cos we like that), how would you build a natively digital state ('cos the current system is mostly 19th Century!) and make services so simple..?". Such fun was had, working with some of the most incredible minds. I learned so much and once seen it cannot be unseen.

4). At times I was shocked at the sheer bonkers-ness of it all but also there were many moments of awe. Seeing the system of government up close was fascinating and never again will the news headlines read the same. There's things I'd change but there is a lot to be thankful about our system of government and its administration. I loved walking into my local pub and playing up the jibes about paperclips and civil servants, but the truth is it is packed with talented, public spirited, hard working people. Properly talented. We are lucky people, us Britishers.

I've shared some more pictures that capture some of this on Flickr.

Seven questions to build a roadmap

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 them these questions*:

  1. What are we trying to prove or learn?
  2. Who are the users?
  3. What are we operating?
  4. What are we saying?
  5. What are our assumptions?
  6. What are the 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.