We started a new 2017 to 2018 roadmap in April 2017.
Throughout the 2016 to 2017 roadmap we provided updates on our work, which you can read in the blog posts below:
The new roadmap structure means that time is fixed and scope is flexible to it. The structure was intentional so that we would have a greater focus on valuable delivery and finishing things (wrapping up, I don’t mean finishing in the ‘forever’ sense).
We asked our teams to understand their roadmap mission, to look at the people, skills and experience of their team, and the other commitments of the team (like support, interview panels, holiday time and so on). We then set to work on making the most valuable, finished and responsibly built improvements in the time available and given those parameters.
The year started with a 2 week blitz
We got two things from the 2 week blitz – delivery and a learning from the process.
The 2 week blitz replicated our new way of working (scope constrained by time) in miniature, and allowed us to deliver a number of things to help our working efficiency or to remove low priority, but regular, requests.
From the process we learnt that:
- we delivered a lot in 2 weeks
- we weren’t collectively great at estimating or managing scope – many things ran over or couldn’t be completed as the teams initially planned
- some people were very busy (perhaps too busy) and some felt they didn’t have enough to do during the fortnight
- it was a useful way to mark an end to the old roadmap (and call time on those missions in a final way)
- product and delivery managers would have benefitted from being able to use this time to get ahead of their mission team from a team preparation perspective
- the 2 week blitz was coupled with new teams forming, and there probably wasn’t enough focus on team building
- we’re pretty good at remote working, but we learnt that it’s important for teams to be collocated during the kick-off phase to build relationships and communicate easily
- as people largely got the choice of mission (or missions) they wanted, that meant that people working across more than one team created a complex logistical issue – it was hard to find free times for each team to meet as a whole for things like stand-ups and planning meetings (having what you want isn’t always what you really want in practice!)
In summary, these 2 weeks were a good confidence boost and important experience – reminding us what’s possible. We’d consider working like this again, if the need arose, but with some minor edits to how we did it.
And then we started our first 11 week mission phase
It’s been a steep learning curve!
Mostly this learning has been focused on scope management and operating in uncertainty.
Making decisions and managing scope
We’ve been learning how to make decisions faster to ensure teams have enough time to do the doing. The most successful teams worked in a timeboxed way within their 11 weeks and were hard on cutting down their area of focus. They gave themselves time to make improvements based on what they did know, rather than doing a lot of research to find the most important thing, then not having time to do anything about it. And this was a really important intention of the roadmap structure – to address this point.
Working with uncertainty and taking risks
Teams also had to grow their confidence as they began to operate with a higher degree of uncertainty. It’s been important for us all to remember and learn that it’s ok to always have a long list of things to do, to be constantly re-prioritising and to only do a small number of the most important.
As part of this, we’ve been learning how to take a few more sensible risks and backing ourselves. We’ve got back to properly running tests on GOV.UK for the first time in a while, which is brilliant. There will definitely be blog posts about the outputs from these tests!
Managing multidisciplinary team workloads
We’ve learnt that having a full multidisciplinary team ready to go from week one has presented some challenges. For example, we saw that some developers didn’t feel busy enough with mission work early on. We want everyone in a team to have the opportunity to be part of the discovery and planning phases, but this needs to be balanced with the ongoing work to support our platform.
We’ve learnt lots about the ebb and flow of when different roles are busy at different points through the 11 weeks. It’s ok if not every week is exactly the same in respect of involvement, but over the next 11 week mission phases teams should be better able to anticipate and respond to this.
We did identify that for product managers (PMs) and delivery managers (DMs) there was a valid need for some to use part of the firebreak (the week between missions when teams can do self-directed work, allowing them to try out new ideas, scratch an itch or release some pressure before the next mission starts) to prepare for the mission ahead. So for our first firebreak we gave PMs and DMs the choice to use the time to get ready for their new team, instead of doing firebreak tasks. However, we’re still keen that work is focused within the 11 weeks as far as reasonably possible.
We identified that PMs were very keen to have things ready for the developers in the team to do. However, as each team has products to maintain and support, we think the focus should be more on preparing platform and support tasks for the team to work on in the first few weeks while the team is kicking off, rather than trying to get ahead of the mission.
Direction and support
The programme team also learnt that on the whole the teams appreciated more direction setting and guidance. We’ve had to reflect on the balance between encouraging teams to get on (particularly relevant in a ‘seek forgiveness, not permission’ culture), and making sure they’re getting the support they need with some clear direction setting at various points. Mostly this guidance has been around progress that we think teams need to have made by various points within the 11 week time frame, and specific pointers on scope. We also needed to be much clearer than we thought about our encouragement to be bold and to risk and try more.
What we’re changing for the second 11 week mission
Well, of course we’ve had lots of retros! We’ve taken what we’ve learnt and we’re making some changes.
How we form teams
We’re changing how we form our teams. Ahead of the first mission phase we did a survey to find out what everyone wanted to be working on and, taking into account business need first, it mapped pretty well. Most people were able to work on the things they’d requested to work on. However, it created some inefficiency for the running of teams.
As different people were across different mission teams, scheduling in simple things like team stand ups or planning sessions, became very complicated. To counter this we’ve tried to minimise the amount of different teams people are on and challenged the idea that part time team members need to go to every meeting every day. We also booked all of our team planning sessions and retrospectives in ahead of time to minimise the risk of calendar clashes.
How we allocate support work
We’re also changing how we allocate support work. We initially did this by sharing the allocation of tickets via ZenDesk – the tool we use to triage queries and requests. What this didn’t factor in was support requests that a team may be getting from other sources (for example from other teams in GDS), or the complexity of the ticket – both in terms of handling a response and how much time they may consume in actually doing the thing. So we’re going to try and improve that balance too.
More direction from the programme team
We’ve also realised that we need more practical technical direction to be constantly overlayed with the product roadmap, so we’ll have more help on this front from within the programme team from the start of the second mission phase.
Training and communities
As this has been quite a new way of working for a number of people, we’re also doing more informal training in GOV.UK. So that’s things like effective time management, different agile techniques, and so on. Alan Wright, Lead Delivery Manager for GOV.UK, has also done lots of thinking about streamlining, aligning and making more of a community hour each week. So, once a week for an hour, each of the communities of practice will get together to talk about a specific thing relevant to them. Where communities have subjects in common to talk about, we can then easily combine those sessions together.
Firebreak ambitions
We also shifted our ambitions for the first firebreak. We moved offices during the firebreak week, so we knew that would have an impact on our ability to deliver during that time. We aimed to be conservative on what we committed to because, again, whatever we did in this week had to be finished, responsibly built and of value. With the office move some people found it easier to work on solo projects, and group projects were well controlled in respect of how much could really be done. There'll be a post soon about what we delivered in the first firebreak.
More to follow
In conclusion, we expect our second 11 week mission phase to be smoother and more productive than our first go at working like this. I’ll write again at the end of the quarter to share what we’ve learnt the second time around, and lots of blog posts will be coming soon on the detail of our delivery from these first 11 weeks.
Jennifer Allum is GOV.UK's Lead Product Manager. You can follow Jen on Twitter.
