At GOV.UK, one of our priorities until the end of March is rebuilding our publishing tools. This is so that it will be easier to improve them in the future, and make them reusable for third parties.
As part of this work, we have developed a new streamlined publishing pipeline that all the 145 GOV.UK formats are being migrated to. This means we have to take each type of page on GOV.UK one by one, and change the applications that publish and display them.
In the Core formats and publishing team, we are in charge of migrating 46 formats from an application called Whitehall. It allows people in departments to edit and publish content on GOV.UK. This is a considerable task that requires a lot of coordination with other teams, and within our own team to ensure we migrate them in a consistent way.
We decided to start migration with the “World Location News Article” format (which we refer to with the abbreviation and far-fetched pun of “Walnut”). It was quite similar to another format that had been migrated already by another team, so it seemed like it would be the easiest one to start with.
Things aren't always as easy as they seem
Little did we know, one shouldn't judge a walnut until one cracks it open. As we started going through it in detail, we encountered unexpected complexity. We found stumbling blocks that required interactions with other teams, and would depend on them to resolve before we could migrate that format.
We were unsure whether these problems were limited to the first format we worked on, or whether they were shared by others. We also didn't know whether it was just the tip of the iceberg, and new unexpected blockers might surface as we started migrating our 46 formats one by one.
We felt like there were a lot of unknowns. So instead of just moving on to the next migration and hoping for the best, we thought it would be best to spend a week carrying out a high level check of all formats. The aim was to get a sense of what issues we might encounter, whether we needed other teams' help to fix them and which ones required trade-offs that needed to be discussed with other GOV.UK teams.
Enter spike week
During that week, we methodically went through all the formats, and recorded their features and potential issues in a single document that we could share with other teams.
We worked in pairs to help with sharing knowledge across the team, and to make sure there was always someone to discuss problems with. It also gives us a better chance of spotting issues. We'd then review the outcomes with the whole team each day.
We were also strict with the amount of time we spent on this task to prevent wasting loads of time or going too deep. In other words, defining what ‘enough’ knowledge for a format looks like.
Why it helped
We have summarised our very big spreadsheet into a document that lists which formats are blocked by which issue, and which formats we believe we can tackle now. This means we know where the big problems lie, we can communicate with other teams about potential solutions, and we can build our backlog sensibly.
We know how to start small, solving small bits of complexity as we find them and building on them as we go, rather than adding lots of complexity at once.
We also have a better understanding of how long migrating each format might take, and what may be out of scope. We actually uncovered a few formats we’d forgotten about. One of those forgotten formats turned out to be the simple format that we were hoping for when we started.
Last but not least, going through this spike week means the whole team has a better understanding of this vast migration project, and of the formats we own.
