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.

How to scale agile service delivery

View fullsize

Download as pdf or svg

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 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.

Everyone loves a roadmap

In agile programmes people prefer to talk about roadmaps rather than plans. This post is about the reasons behind this and the benefits of using a roadmap rather than a gantt chart to manage pure agile, or mixed methodology programmes.

Peoples' Front of Judea

Plans can be a cultural battleground between the traditionalist and agilistas. They needn’t be. Both camps need an artefact to guide them towards a longed for future and a roadmap provides something for everyone to cling to.

Managers and stakeholders often ask when something will be ‘done’; What are the milestones? Are we on track? What are the dependencies? What is the critical path? These are natural questions to want to ask. Waterfall and agile methodologies answer them in different ways with very different artefacts.

The Waterfall-istas reach for MS Project or equivalent gantt tool to make sense of the world. The agilistas use a backlog, prioritisation, continuous delivery and feedback loops to make sense of theirs.

Agilistas will say “we love planning… just not plans”. They hate gantt charts because they offer only false certainty and often do not sufficiently accommodate change. In the wrong hands they will stifle learning and continuous improvement, as teams switch the focus from delivering outcomes to keeping to ‘the plan’.

Continuous, adaptive planning is an awesome part of agile. Good, informed prioritisation, that factors in the cost of delay, risk, business value and dependencies is perfect for wholly agile teams, but it’s not for everyone.

Not everything is software or agile

My particular experience is in the delivery of digital public services for government. Mostly these programmes of work are not just about digital. They may include a change to an organisation’s operating model, training, buildings, telephony… Often the (least lean) bits of service delivery that many agile teams sometimes consider as “the business-y bit” – bywords for “waterfall” and “dealing with the non-converted”.

Traditionalists charged with managing these types of programmes see no alternative but to add agile sprints to the large MS project plan. In the past, for example, I’ve been asked to provide themes by way of labels for six months of two week sprints and this is not good — for anyone.

They get frustrated with agile's lack of plan and I understand their concerns. I’ve seen agile planning ceremonies used as a smoke screen for short-term planning only. That’s being über agile, right? Yes it is, but sticking with that mindset can alienate stakeholders and co-deliverers who demand a better picture of the future.

A roadmap is the droid you are looking for...

A roadmap bridges the gap between worlds.

• Something for everyone - it is an artefact that traditionalists recognise enough as a 'plan' and agilists recognise as 'not a gantt chart'.

• Focuses on outcomes not deliverables -it promotes the right sort of strategic conversations within teams and with stakeholders.

• Provides stability but evolves - it sets a clear, stable sense of direction but I find teams and stakeholders feel more comfortable discussing change resulting from iterative delivery and learning.

• Promotes buy-in -good people will feel out of control and disengaged when deliverables are dictated up-front and/or from above. Self organising, multi-disciplinary teams love to own and be empowered to meet outcomes in creative ways.

• More coherent - it allows you to knit all aspects of your programme together (e.g. software, infrastructure, ops, policy, security, estates, human resources, procurement) without freaking out any horses or doing up front requirements specs or giving false certainty.

• Better performance metrics -outcome based planning allows programmes to more easily measure the evolution of a service through early stage delivery into full blown operation and iteration. Some metrics will be a constant throughout, others will only have relevance in later stages. This approach keeps you iterative and chasing incremental improvement. It also makes for joyful dashboards.

• Better governance -roadmaps work well with time-boxed or target-based governance gates -- you choose.

There's something for everyone to like about a roadmap.

In my next post I'll talk how to put one together and how language can be used to find common ground.

Crowdsourcing Christmas

I left my present buying to the last minute again.  Usually we share Christmas wish lists but this year we didn't. I was stuck for present ideas and the prospect of browsing around the shops for inspiration was filling me with dread.  So this year I crowdsourced ideas for presents from my team mates.

As a bit of fun at our last stand up meeting of the year, I said I was blocked on present ideas; today I was running a Christmas workshop and all fellow hopelessly organised people could join to get some ideas together.  Phil whacked on the Christmas tunes, Sarah got the coffee pot and off we went to a white wall.

People with presents still to buy put the name of their gift-less recipient, age, relationship, a budget and a list of  'likes' on a big yellow post-it and stuck them on the wall.  It was great fun and you learn loads of funny stories about your team mates' families.

Next, everyone had 5 mins to jot down ideas for other peoples' gift-less friends and family and stick them on the wall.  Within minutes we had loads of great ideas that we'd individually not thought about. Like, BRILLIANT STUFF!

Next year I will try and do it sooner than the last Friday before Christmas. And I'm banking on Dad not reading this before Christmas or else it will ruin the the surprise of his Dad Rock inspired present.