On 28th February, GOV.UK released a second beta – INSIDE GOVERNMENT.
So, six weeks later, what have we learned? From the benefits of ‘storytime’ to the real value of precocious developers, Pete Herlihy outlines some of the things the team learned delivering this release.
On April 11th, we completed the six week beta period of the INSIDE GOVERNMENT section of GOV.UK. Although it’s by no means a complete product, it is still an important step in the GOV.UK journey. It is the culmination of five months of effort between GDS, @freerange and many others from inside and outside government. I want to share a few of the most important things that we learned from delivering INSIDE GOVERNMENT, based not on what we actually delivered, but how we did it.
I think we learn more from the mistakes we make than the things we get right, so I learned a lot of things on this project! If you’re interested in finding out more about the way we work, Jamie Arnold has blogged about this in the past.
1 – If it’s hard to write a user story, it’s probably not as important as you think
At GDS, we don’t write monolithic requirement lists. Instead our approach is to focus on user needs, and user stories are the best way to achieve this. That means projects are built on a set of prioritised user stories which are typically expressed in the same format:
“As a <user>, I want to <see/do this>, so that <I can do that>”.
If we struggled to come up with the ‘so that <I can do that>’ part of the story, it was typically because we had assumed a need or it was overly prescriptive of the solution. On many projects, writing the ‘so that <I can do that>’ part is seen as a chore and skipped, which is a really bad idea. It’s the definition of value, so without it, it is difficult to know when you have delivered the story. Right at the outset of the project, we sat down as a team (actually, we probably stood up) and discussed how the stories should be written. This was really useful as this shared understanding made sure we weren’t limiting our options for the solution.
I don’t know a single developer who would prefer to be given tasks to complete over problems to solve.
2 – If it’s important you will remember it
When running a sprint backlog, it’s a huge temptation to move everything that you don’t want to focus on at that time into an icebox (a ‘holding area’ for stories that you don’t want to prioritise or work on just yet). Stories that need further input are no longer the next priority, and seeds of ideas that haven’t even been written into stories yet can easily find themselves moving to the icebox.
At one point, our icebox topped fifty stories so I decided to delete the whole thing. It had become a liability to the backlog and had to go. The mantra we had in the team was ‘if it’s important you will remember it’. Living by this mantra was actually quite liberating!
3 – Investing time preparing stories before sprint planning paid big dividends
We were constantly reviewing the upcoming backlog stories as we went through a sprint. But a few weeks into the project, when our sprint planning started to take far too long, we decided to have a separate session to go over the stories each week, ahead of the sprint planning session. The product owner, delivery manager and a developer (on rotation) met and ensured that every story was well written, prioritised and importantly, that the value of the story was clear.
It wasn’t uncommon for stories to be ‘iceboxed’, or even dropped completely if we weren’t convinced of their value or we weren’t able to turn them into an effective story.
I recently noted this practice actually has a name – ‘backlog grooming’, although we just called it ‘storytime’.
4 – Avoid the temptation to make the newest story the most important
This is something I was definitely guilty of. Often new stories emerged and promptly entered the priority charts at number one, not because they were the next most important thing, but with hindsight, they were the most salient.
It’s an easy mistake to make, indeed, probably human nature, but there is merit in challenging yourself if you ever find a new story slotting in atop the list. Our story grooming sessions were a really good way of challenging this behaviour.
Having a precocious development team, who weren’t averse to raising eyebrows and using the word ‘seriously?’ was a great way to help us step back and rationalise the real priority of new things.
5 – Make sure you can tell when your objectives are met
I’m used to having project objectives to deliver against, but rarely are they truly measurable. It was an incredibly useful tool on INSIDE GOVERNMENT to have these objectives clearly defined, understood and crucially, on display on our walls. It is a bit more effort to capture measurable objectives, because you need to think about how you will actually make those measurements but the return is well worth the investment.
One of our objectives for the beta was to deliver a publishing platform that met 80% of the shared publishing needs of the departments that were involved. Once we knew that we had achieved this, we were able to focus on enhancing existing features rather than being distracted by adding new functionality.
6 – Running our project in the open wasn’t a scary thing
I’ve never run a project as open as INSIDE GOVERNMENT before. We started the project deploying all of our code to a public github account, so there was already significant transparency about what direction we were heading in. However, we also decided to open up our sprint backlog so that people could see exactly what were were doing on a sprint by sprint and even a story by story basis.
I’d love to claim that we pre-planned this out of a great desire to share and be open, and ultimately we did do it for these reasons. However, the trigger was something that many others will have faced – the expiration of the free period on our backlog management tool (Pivotal Tracker).
I’m really glad we did this, but developing in the open like this meant we had to avoid sensitive details like user credentials or passwords being contained within stories and bugs. Also, as a result of @pivotaltracker tweeting that we’d gone ‘public’, we received numerous requests from members of the public to be added as contributors to the Pivotal account!
This is by no means an exhaustive list. I always find reading about how others work and what they learn in doing so, as interesting as what it is they’re building. I’m looking forward to a lot more learning (and sharing) as we move towards the launch of INSIDE GOVERNMENT.