ONS Digital

In this post I want to share a few of the outcomes and things we learnt from our 12-week Alpha. You may also be interested in our Discovery outcomes which preceded the Alpha and the Team Toolkit we used.

Workflow

When designing any kind of digital product it’s vital that user research, design and prototyping are carried out and tested upfront, so each user story can be validated and considered “ready” to be developed. However, a combination of a very short Discovery period and our Alpha team structure, lead to our UX Designer handling frontend development on top of design. This meant that their Sprint capacity was consumed predominantly by development activities leaving almost no time for research and design prior to development. In addition, without a clear understanding of what we would be able to build in the Alpha – the amount of design work was significantly underestimated.

Even early on, we acknowledged this was an issue, but by the end of the Alpha the whole team recognised this as a being a serious problem. It manifested itself as design being worked on after functionality had been developed (rather than functionality being built to support the design) which imposed unacceptable constraints on the design. User research also suffered as we were essentially putting UI in front of users that hadn’t had the time to be properly designed. This obviously impacted the usability of the system as we progressed, and we know this cannot continue in Beta.

This is one of our key lessons learnt in the Alpha, therefore, to address this in the Beta, we’ve added a developer with strong frontend development knowledge and experience to the team, we’re also recruiting an additional UX designer and have agreed the workflow for Stories must start with analysis, research and design prior to being ready for development.

To support this approach the developers will be focusing on the foundations for the production infrastructure at the start of the Beta (more on this later), allowing sufficient time for analysis, research and design activities to progress prior to Story development starting.

I don’t expect our workflow will stay the same throughout the Beta but we’ll at least start with something based on the lessons we learnt in Alpha, here’s a high level overview of our thinking for the Beta workflow:

eQ Beta Product Lifecycle

Sprints

Our Alpha was split into Sprints, we started with a 1-week “Sprint 0” followed by five 2-week Development Sprints and concluding with a final 1-week wrap-up:

eQ Alpha Timeline

As I wrote previously, having some time up front for laying some foundations (Sprint 0) was essential and saved effort throughout the rest of the Alpha by having numerous otherwise manual processes automated from the outset. We will be undertaking the same approach at the start of Beta (albeit longer) to put in place they key elements of the production infrastructure and delivery pipeline, this will also support the workflow improvements identified above by giving the required time for research and design prior to development commencing.

Each Sprint consisted of a planning session (around 2 hours), the actual development days and then a Sprint Review (15-30 mins) on the last day where we demonstrated what had been achieved within that Sprint (anyone could attend this, but it was predominantly key stakeholders). We then undertook a Retrospective (60-90 mins) with just the team followed by a planning session again for the start of the next Sprint and the cycle repeated.

The Sprints provided a good rhythm to the project but we did suffer one of the negative effects this can introduce,  rushing to complete something before the end of the Sprint, resulting in mistakes and introducing technical debt. We did rectify this after highlighting the problem in one of the early Retrospectives and it is something we will be careful about in Beta.

Retrospectives are an excellent route to continuous improvement, we identified nearly 100 improvements we could make in the Alpha; the team voted the top-3 to focus on each Sprint, rather than trying and tackle them all and failing to achieve any. I recommend regular Retrospectives, even if you aren’t working in Sprints.

Open Doors

Every other week we held an “open door session” where the team were available for an hour in our team room (with the door wedged open) to answer any questions or have a chat about the project. After the first open door we decided it would be good to allow some hands-on time with the product during the sessions (we set out a bunch of laptops in the team room ready to go); this worked well and was a great way to engage people in conversation about the product, their concerns and ideas etc.

Having these sessions on alternate weeks to the Sprint Reviews also meant we had an open opportunity every week for engagement. We had a wide variety of people attend from across the office; I really recommend these kinds of sessions (including hands-on time) and it is something we will be continuing with in Beta.

The obvious downside to these kind of sessions is that they aren’t very inclusive to teams and stakeholders at other sites. The ONS has three sites, Newport (where the eQ team was based), Titchfield and London. A few of the eQ team did travel to Titchfield in the Alpha and ran two open door sessions, but I feel this is something we can improve on in Beta, with more regular visits and making better use of the excellent video conferencing facilities the ONS recently installed.

Pairing

At the start of the Alpha the developers undertook a lot of pair-programming, where two developers work together at the same desk on one machine, this is a well established development technique. The team rotated who paired with who frequently and this allowed everyone to keep up to date with the different parts of the system as they were developed and share knowledge and experience. It is also generally accepted that pairing results in higher quality code, less defects and better coordination across the team, all of which counteracts the time spent having two developers working on the same problem (although it is notoriously hard to prove this either way and the subject of many a discussion).

Towards the end of the Alpha there was less pairing occurring and less rotations; we did acknowledge that this resulted in reduced understanding and knowledge of the system as a whole across all of the developers, leading to a higher dependence on specific team members to work on specific areas. We’re planning to return to more frequent pairing in the Beta and also pairing outside of just development, for example there are strong recommendations for the whole team being involved in user research, such as having a developer pair up on a research session providing them an understanding and empathy for the user that can’t easily be replicated through videos or documents.

Team Room

We had a dedicated team room with a projector & screen, glass boards, whiteboards, post-its etc. for the duration of the Alpha. The team made use of most of the wall space, using it for the living backlog (Story Map), tracking Stories through the workflow, analysis, research and design artefacts and pretty much anything else the team found useful.

eQ Team Room

The room was a place for regular team meetings (stand-up, Sprint Review, Retrospective etc. etc.) but also for ad hoc discussions, whiteboard sessions, meeting with stakeholders… most days the room was in use throughout the day for one reason or another by the team.

I consider a team room absolutely essential, somewhere the team can make their own (Star Wars posters included) and use as a space to organise and run the project. The only problem we hit was squeezing everyone into the room during some of the demos and open door sessions!

That’s all for Part 1…