To improve our focus on delivery and the flexibility to sensibly reprioritise our work throughout the year, we’ve moved to a new way of working in the GOV.UK team.
We blogged about our old roadmap and explained how – despite the fact that we thoroughly reviewed progress and adjusted our roadmap every quarter – missions felt protracted and delivery was hard to show. We needed to improve that.
Our new approach is a better way to focus our energy. It also allows enough flexibility to change direction if needed.
As we’ve done since the beginning of GOV.UK, teams will continue to work in an agile way. However, work is now organised into quarter-long missions, each with a specific goal.
The scope of the mission is flexible but the length of the mission is fixed. No mission is longer than 11 weeks. It might be the case that a theme extends over the course of the year, but we want iterative and complete delivery every 11 weeks, in case we need to change direction or stop. This will also help us to continually deliver value.
We believe this length of time is sufficient to deliver the most value. We feel this structure allows us to build and develop products to a stable state, in a responsible way.
Product managers share what it’s like to manage and change scope to deliver in a fixed timeframe.
Luke Malcher, Product Manager, GOV.UK Benchmarking
When the mission started, I was quite new to the organisation. However, this new approach meant it felt like everyone was starting afresh.
It took some time to familiarise ourselves with the benchmarking mission, which is all about addressing challenges that users face with common user journeys on GOV.UK.
We were perhaps a little too cautious at the start when it came to agreeing what was valuable and achievable, but this will improve with experience.
We know that we'll get better at assessing this with every mission.
For example, we agreed to ship something small – an A/B test. We started to test our assumptions with real users. In benchmarking we realised we could get A/B tests shipped and completed quickly. This shaped the mission and made it easier to work out what we could do in time left.
I’m looking forward to taking our experiences and lessons learned into the next quarter.
Humin Miah, Associate Product Manager, GOV.UK Publishing Frontend
This was a completely new way of working for the team. We adapted by focusing on delivering the minimum viable product or improvement. We did this to maximise our learning opportunities throughout the mission.
We knew that the quickened pace might put pressure on the team. As a result, we implemented two methods to reduce this.
The first method is to use the 80/20 rule in our sprint backlog. 80% is mission-related work and 20% is non-mission work. The 20% includes upgrades or design changes we’ve been wanting to make for a while. This reduces scope and boosts team morale.
The second thing we do is we talk every month about our attitude to the mission. Discussions focus on specific categories, visualised with the team. These focused on the mission and the work we were doing.
It’s a great method to address concerns and adjust scope to keep the team strong, happy and committed to the work.
Mark McLeod, Product Manager, GOV.UK Search, Custom Formats
We spent the first 2 weeks of the mission trying to understand the challenges of measuring search performance. We then discussed and agreed what our goals should be for the mission.
By the third week, we developed a team roadmap of how we would achieve our goals in the remaining 8 weeks.
Our roadmap comprised a series of 2-week sprints. We accepted that this was only a best guess. We accepted the roadmap could change in size as we learnt more about the size and complexity of the work.
We learned at pace. For example, we wrote up stories with acceptance criteria for the first sprint. These were only high-level ideas of what we planned to work on in the final sprint.
We reviewed our roadmap, and adjusted our scope at the start of each sprint to better manage it throughout the mission.
Generally, this meant reducing the scope of what we had planned.
For example, we planned to measure both internal and external search. We soon realised that this was too ambitious and reduced the scope to focus on internal search.
We’ve learned that the scope must be flexible. We know we won’t get it right at the start of a mission and the scope will change. We will get better at refining this with every mission. Working in this agile way makes it easier to manage changing scope and deliver value to users early and often.
Does your organisation deliver in a fixed time frame? What have the challenges been for you? What’s worked well? Comment below.
