GOV.UK is relied on by millions of people every day to access vital services and information. Material published on GOV.UK can move financial markets. GOV.UK is a vital part of our national infrastructure.
But GOV.UK differs from most other pieces of national infrastructure in one respect: we built it and we run it using agile. GOV.UK has been live for more than 5 years and we’re constantly iterating and improving it based on feedback. GOV.UK has always been – and will continue to be – agile at scale.
But being agile doesn’t mean simply installing a methodology and then religiously sticking to that methodology. It means adapting what we do based on what we’ve learned. And this includes adapting our ways of working.
A little while ago we learned that we had a few challenges with GOV.UK delivery. So we had to adapt our approach. Here’s what we did and what we learned.
Moving fast and accruing debt
We built GOV.UK very quickly. It launched in 2012 and just over a year later it was hosting all the content for 24 ministerial departments and 330 organisations. By 2015, it had replaced the sites of 1,882 government organisations.
But doing all this had come at a cost. We had accrued a lot of technical debt by building things quickly that might cause challenges later down the line. And the number of people working on the programme had fluctuated, meaning that there wasn’t much stability.
As the programme matured, it was time to step back and review our ways of working. By the beginning of last year, we noticed 4 problems that were affecting delivery:
- as deadlines could be flexible, sometimes work wasn’t stopping
- greater clarity was required on the most important problems
- research effort wasn’t always reflected in delivery
- we had too many potential single points of failure
So we put in place a new way of working to deal with these.
A new way of delivering
We put in place 4 new principles to help improve delivery on GOV.UK:
1. Spend only 3 months per mission
We wouldn’t commit to any mission – or piece of work – that lasted longer than 3 months. That was because every 3 months we wanted a genuine re-evaluation point where we could say: “Do we definitely want or need this work to continue? What is the compelling proposition for another 3 months on it?”.
We kept the time period short because we wanted to build in the flexibility so that we could change direction, if we needed to. Time was fixed and scope could be trimmed.
2. Measure stuff with numbers
We would use metrics to see how we’re doing. But proper metrics, not fluffy key results.
Teams were tasked with defining how they would undeniably be able to show that their 3 months of time had been a good investment.
3. Have firebreaks
Between each 3-month mission we would have a 1-week firebreak. This would be a chance for teams to work on anything they wanted.
Doing this would remove any possible build-up of pressure, make more space for learning, foster creativity and allow time for team reconfiguring.
4. Prioritise sustainable building
Sustainable building would be a must – we need to have less problematic technical debt.
You can read more in this blog post about our 2017-2018 roadmap.
Putting this into practice
This new way of working would be quite a big change for the people working on GOV.UK. It would mean that they could be moving across missions and teams every 3 months. So we took a number of steps to introduce it carefully.
Firstly, we mapped our planned missions against the headcount, to make sure we had the right number of people and the right skills.
Then we sent out a survey to all staff asking them what teams they would be interested in working on or had any relevant experience in.
Before we announced the teams, we also ran drop-in sessions for people to come and find our more about the new model. And we met lots of people individually to talk about their preferences and development opportunities.
We’ve been running this model on GOV.UK for just over a year now. And it’s also being used by other parts of GDS.
What we’ve learned
This model can be successful
When we first started working in this way, most teams faced challenges with incremental delivery, delivery at pace, sustainable building, doing things with data and responsiveness to change. Now we are starting to excel in these areas.
We achieved this through extensive training for teams, strong messaging and support from programme leadership, moving seniors into broader roles where they can oversee the work of several teams, and lots of sharing of best practice between teams.
Large programmes can be made more manageable
With 168 people across 24 teams, GOV.UK was a relatively large programme. As a management team, we found it difficult to effectively manage at this scale.
To counteract this, we’ve split our work into a handful of objectives, with each objective containing 3-5 related missions and about 40 people. Most people are assigned to teams, but some people are assigned to specific objectives so that they can help out on each mission as needed.
This move towards working in smaller groups rather than one big group helped teams to become better at self-organising and more adaptable to change. Having senior team members leading objectives gave them the space and context to help out with long-term thinking and coach best practice to more teams.
Stopping things is hard (but it gets easier)
We are all very passionate about our work, and it's hard to stop doing something when it looks like there is more to do. But it’s best to do less and do it well rather than to be too ambitious and have no slack for the unexpected.
When we did decide to pause work on missions, there was an initial and negative emotional reaction from team members. However, in the longer term, the reduction in work in progress was a relief as it allowed us to do what we did to a higher level of quality.
We need to provide clear direction to teams
It took us some time to get the balance right between giving teams clear direction and the autonomy to solve problems.
Over the year, we’ve learnt that good missions need 3 things:
- a clearly defined problem for the team to solve
- clearly articulated measures of success and definitions of 'done'
- a steer on the expected scope/direction (if leadership have a view on this)
The team should be free to challenge any of the above, but it is critical to have a shared understanding of the purpose of the mission from the very beginning.
Varying mission lengths can avoid dysfunction
Initially, we decided missions should be 3 months long. But some pieces of work need a guarantee of longer than 3 months – otherwise it could create dysfunction in the way the team members prioritise work.
Now we are experimenting with missions of variable lengths. Smaller missions or exploratory work could be 6 weeks in length, and more clearly defined work could be 12, 18 or 24 weeks in length.
The model needs to work for part-time team members
In a perfect world, team members are dedicated 100% to their team. However, this is not always realistic and some roles have to be shared.
We have found a number of ways to help part-time team members:
- reduce the need for people to be split across multiple teams by reducing the number of teams
- group part-time team members by objectives and allow them to work with the senior delivery manager on their objective to decide how they should allocate their time between the missions
- give part-time team members a primary team, and allow them to consult with other teams as required
It’s important to measure from the start
Our measures of programme performance became much better as we progressed through the year. We also started running a regular survey at the end of the first quarter to give us quantitative data on people’s satisfaction and productivity.
However, if we could do this again, we would invest heavily in establishing and baselining programme performance measures right at the beginning, and implement the change once effective measurements were in place.
Staying agile
This new way of working on GOV.UK affirms our commitment to agile. It means we can move quickly and respond to learnings or changing circumstances, and reduce the cost of any changes.
We're making better use of taxpayers' money by more frequently delivering improvements that will make GOV.UK better and improve users' lives.
Follow GDS on Twitter and don't forget to subscribe to this blog.
5 comments
Comment by Pav posted on
What does mission means?
Comment by GDS posted on
We use the word 'mission' to describe the programme of progressive work that a product team pursues. A mission might be equivalent to an epic, or a larger problem statement that's prioritised for a team to work on.
Comment by Shane Quigley posted on
Great Article! And thank you for sharing your experience and leading by example.
Comment by Kate Streatfield posted on
As ‘scaling ‘ is one of the big issues facing agile in government, this is a very interesting and helpful blog.
Would be interested to know how you define ‘programme performance ‘.
Comment by GDS posted on
Good question. Programme performance covers things like our delivery velocity, our performance against our service level agreements, the analysis of the types of work we're doing, the balance between our support and mission work, and so on. Knowing this sort of information really helps us plan our work better, and is an area we're looking to become increasingly sophisticated in.