In early April we kickstarted our new 2017 to 2018 roadmap with a 2 week blitz period. As we formed new teams centralised around the roadmap missions, each team was given a single ‘must do’ task. They covered some known problems we wanted to solve and some improvements to our delivery efficiency that would otherwise not feature on the roadmap. The tasks also meant we could get well acquainted with working on a fixed time but flexible scope basis, which is how we will continue to work for the rest of the year.
For some, it was their first experience of working in a multi-disciplinary team and the fortnight was a good opportunity for all of us to get to know each other and our preferred ways of working. We also hoped it would be a time to recharge batteries before we got stuck into the first of our four quarterly 11 week missions - although this may have been wishful thinking. The time was not a buffer to finish overrunning 2016 to 2017 roadmap projects or a firebreak, the objective was clear and we were eager to start.
What happened next
All the work we wanted to do was written up and submitted to the Programme Team on Trello cards with a user story and some acceptance criteria already defined. They were then prioritised and ordered. In total we had 12 ‘must do’ cards assigned to different teams, the details can be viewed on our Trello board.
There were no hard and fast rules on what the teams did next. We had one additional requirement which was to measure our work. There is a large emphasis on measurement across our entire roadmap this year, and it was essential for every team to be able to understand the impact of their efforts.
Alongside the blitz work we also continued to support business as usual and any urgent support requests that came up. There were also some additional cards, ready to pick up if we completed our ‘must do’ work early. This served as a good stretch goal for the ambitious ones amongst us!
My teams' blitz work
My 2 teams were working on the comprehensive link checking and emergency banner cards. There was very little, if any, preparation or planning around the work before we started and that was intentional. We wanted to kick this off together and work out how best to tackle the problem and measure it as a team.
The link checking task had well defined acceptance criteria, but they didn’t really relate to the user story. This caused some confusion within the team early on, so we re-wrote the user story and communicated this back to the Programme Team to make it clear what we were trying to achieve, and to make sure the goal was realistic for the time frame.
All the blitz work was technical, requiring our developers to be full-time on the project (alongside support commitments). Early on we worked out how best to utilise the whole team’s expertise - including input from our content designer, user researcher, analyst and policy and engagement specialist. On both the emergency banner and link checker this worked really well and meant we added even more value to the result.
We made changes to the emergency banner to make deployment quicker and easier. We also created an extensive journey map of the incident process that leads to the banner being deployed, which will be useful documentation to be shared internally. We also made accessibility improvements and updated our content guidance to aid the drafting and reviewing of the banner text - a task which is likely to happen under pressure.
For the link checking task our content designer and designer worked with our developers to draft user friendly error status messages. Checking links more comprehensively meant we had new warning states to communicate and we also improved how we display errors within the Local Links Manager interface.
How it went
As we all know, like any best laid plans, things can go awry. In the middle of the first week our office building was evacuated due to an electrical fault and it remained closed for an entire week, re-opening 2 days before the blitz ended. This was a great test for our disaster recovery systems, which promptly got everything back up and running. Although it did cause some problems and a bit of disruption to most teams’ work, it encouraged us all to fully embrace remote working.
Our work is never done and I think it’s fair to say all the cards had the possibility of increased scope which went beyond what could be achieved in 2 weeks. It was a good lesson for teams on addressing their scope and reducing it when necessary to finish work in a fixed time period. We’d be lying if we said we didn’t find this hard and we did still have work to do to wrap up our blitz cards after the 2 weeks had finished.
For the Link Checking team this involved reviewing some next steps and recommendations as well as getting our changes live. For the Emergency Banner team it involved publishing the new guidance and testing the new process for the next couple of weeks with our 2nd line support team. Once we were confident it was working well, we removed the old code and documentation.
Where tasks were completed there may still be further work or maintenance required. For example the improvements made to documentation also set out a new process for our 2nd line team to keep it well maintained going forward.
What we delivered
By the end of the 2 weeks, GOV.UK’s teams had delivered improvements on:
Checking URLs that GOV.UK links to
This is a big task for us, so we made an incremental benefit that will help decrease risk and flag suspicious content, while also letting us know about broken links.
Our redirect functionality
We want to make it possible for content designers to implement redirects without assistance from a developer. This will decrease the amount of time that incorrect content might be shown, and make a significant efficiency saving too. We’ve made progress towards this. We still need to design and test an interface for this tool before it can be used.
Webchat component
Our original webchat implementation could only be used by HMRC. We made changes so that other departments can now have webchat on their contact pages if they want to.
Developer documentation
GOV.UK’s developer documentation needed a bit of a tidy up, so we’ve done that. We now have a more logical structure that will help us avoid silos of knowledge and should increase our pace of development.
Analytics
We made some improvements to the analytics available to our teams so we can better account for our performance and the value we’re adding against our roadmap objectives throughout the year.
Emergency banner
Our emergency banner deployment process on GOV.UK was relatively slow often taking up to 30 minutes. Whilst the banner was up, other deployments were blocked or more difficult to do. We’ve made improvements so the time to deploy is now shorter, the process is simpler and the banner no longer blocks other deployments.
Content training environment
We made some steps in the right direction to provide our content trainers with a more stable environment for training purposes. This was a large piece of work so there is more work to do here.
What we learned
Whilst we didn’t complete all the initial acceptance criteria for the blitz tasks, adjustments to scope were expected and overall our delivery output was good. This reminded us how much can be done in a small timeframe, giving our teams confidence on what could be achieved in the upcoming 11 week mission.
It was a great exercise to kickstart working with new people in a new way, but we didn’t get to enjoy as much team bonding as we would have liked. Fortunately, straight after the blitz we had a GOV.UK away day and this was a great opportunity to down-tools, do some team bonding and have some fun. Each team also gave a 5 minute lightning talk to show everyone what they’d done in the 2 weeks.
Where work remains on some of the blitz activities it has either been backlogged for a future firebreak period or added to an existing product support board to be picked up when possible.
Antonia Simmons is a senior product manager on GOV.UK. You can follow her on Twitter.
