Tired of fortnightly sprints? We’re trying something different

We’re trying something new on the Design System team at the moment. A move away from traditional fortnightly sprints to a 3-week delivery cycle with a reflection week at the end. I’ll talk in this blog post about why we did this and how the first cycle panned out.

The pretext

Throughout 2023, myself and Steve Messer (former senior product manager for the GOV.UK Design System) had been tweaking the team’s delivery setup trying to find a way of working which best suited the individuals we have on the team and the work we do. We had some successes such as strengthening team show & tells, introducing no-meeting days, and establishing more support for epic leads on the team (a role I’ll talk about in a future blog post). However we were still routinely missing sprint goals and carrying things over to the next sprint.

Looking at these missed goals in more detail, we could see a pattern emerging. Initial investigations and scoping took longer than expected leaving us little time to actually get something meaty finished. I started to think about alternate ways of working which could give the team more time for exploration but also ensure we continued to work at pace.

Fixed time, variable scope

Extending the length of a sprint was an easy conclusion to come to, but we wanted to establish something different — a clean break from sprints. We started using different terminology such as “cycle” to describe the timeframe, and “briefs” for the work itself. We also initiated an expectation that the team deliver something shippable or showable at the end of a cycle.

We agreed that for the first few cycles, the briefs should be written by the team leads so the team had clear direction whilst they adapted to a new way of working. In future iterations of the model we’ll aim for brief writing to be more collaborative and create space for the team to submit briefs for consideration in prioritisation. The briefs themselves have an objective we task the team with delivering. They roughly follow this format:

[Action + Outcome / Output + For User Type + To Solve User Problem + By Deadline]

It’s then up to the team to decide how they’re going to deliver the brief.

Flexible squads

For the last couple of years, we’ve had two fixed squads on the team — Frontend squad and Design System squad. The Frontend squad had been established to focus on delivering version 5 of GOV.UK Frontend which was complex and extensive, whereas the Design System squad was focused on the website itself — delivering new components and patterns, iterating existing ones, and community work. Shipping v5 naturally posed the question of whether we needed two squads anymore.

Oliver Byford (our lead frontend developer) suggested the idea of flexible squads which spin up around a brief. The team leads would suggest which roles were needed to fulfil a brief and then the team members could choose what to work on. Given the first few cycles would include some ongoing work from our previous ways of working, we felt it didn’t make a huge amount of sense to change up who was leading particular work streams. So we decided to determine the squad members ourselves to ensure there was continuity and knowledge transfer could happen with new folks in the squad. In future though, we’d like to move towards a more self-select model.

Delivery autonomy

The team is very mature and most individuals have been working together for a while now. They know each other well, and know how to work together to get something done. We wanted to honour that maturity and give the squads autonomy over how a brief will be delivered. This includes scoping the work, defining done whens, and deciding how they want to work together. Squads can decide the cadence and format of their stand ups, and choose when to work synchronously or asynchronously.

The cycle planning session gives the squads time to interrogate the brief, re-scope it if needed, and build a high level task list which is later converted to issues on the team GitHub board. This ensures there is visibility of each squad’s work and as leads we can monitor the progress of the work and report upwards.

Reflection week

One of the things we were keen to build on from the coaching programme the team took part in last year was active reflection. The tools and techniques shared by our coach Stefan Powell have helped us build more deliberate reflection into our ways of working, bolstering retros and scaling team learning and development (L&D). I wondered if we could build on this further and have a whole week dedicated to reflection after a cycle.

It made sense for reflection ceremonies such as show & tell and retro to happen during this week, however, what else could we use the time for? We looked at the things that often get overlooked during sprints — skills sharing, blog writing, documentation / decision logs, space for experimentation and team building activities. With a brief delivered, the team would have space for these types of activities.

The model

Thanks to Chris Ballantine-Thomas for putting this graphic together.

The first cycle

I’d say our first run of the cycle was mostly a success. The team delivered 3 out of 5 of the briefs, but unexpected absences and support demands arising from a recent release hindered progress. Without these blockers I’d expect the achievement rate to increase in future cycles. We also felt we didn’t quite get the scope right in one of the briefs and this made it difficult to fulfil. A good learning for us leads when drafting briefs — they need to be more collaborative with the epic leads.

There was some useful feedback from the team also about the new way of working. Most team members enjoyed working in smaller, focused groups and having autonomy over how they deliver their work. The big takeaway though was folks saying they didn’t know what to work on at times when they could not progress their brief.

As leads we’d flirted with the idea of bringing in “small stories” during the first cycle but decided to keep it simple for the first run and just have the team focus on the briefs. However we can see now there is space for smaller pieces of work that can be chipped away at during a cycle. So for cycle 2 we’ve built a small backlog of stories from across our repositories. We emphasised that these should never be prioritised over brief work and that we’ll monitor this during the cycle.

We used our first reflection week to lay the groundwork for future reflection weeks. Imran Hussain (our community designer) and I ran a ‘team superpowers’ session where team members expressed what they’re skilled in and areas where they’d like to build more confidence. The idea is that we can enable peer-to-peer learning and create future skills sharing sessions.

Up next

I’ll write again in a few months time about how it’s going and how we’ve iterated the model. In the meantime, if you have any questions about the model, either add a comment to this blog post or message me on LinkedIn.