We challenged the agile delivery phases, here’s what happened
How a change in approach is helping us to meet our goals
I’ve spent the past year supporting programme delivery. The work that’s been done so far has given us a better understanding of how we can, and when we might need to, adapt our approach to large capability contracts (contracts where the buyer is looking for specific skill sets to embed in their teams), and programmes (multiple teams working to a shared overarching goal). This post is part of my commitment to share what we’ve learned.
As well as considering how best to influence product portfolio strategy, we’ve been questioning whether the Government Digital Service’s agile project phases allow us to deliver value flexibly, and without unnecessary delay. Programmes of work are typically long-term, with multiple goals, branches of scope and teams. This makes it difficult to move fast, but our clients need to see a prompt return on their investment. So when we’re working as part of a programme, we have to move quickly and demonstrate positive impact as early as possible. The project phases and their associated ordering and timescales can be unhelpful and inflexible, particularly in this context.
An example
2 of the teams (now 1 team) within a programme of work had been operating for a while. The products were in beta and, at the end of summer 2023, had been in a regular cycle of development sprints.
The team felt it needed to pause and research so it could understand and validate some hypotheses and upcoming stories. This would help create confidence in the backlog of work against some iterated programme goals. Validation would take time, longer than the usual cycle of research – design – develop would allow. But the outcome would mean we could move faster and more confidently in the long run.
Our client positively challenged whether to do this. Stopping development prompted natural feelings of nervousness because the team was in beta and getting close to the end of the engagement. So there were questions around what we were proposing.
The term ‘discovery’ can be helpful and unhelpful
I used the term ‘discovery’ in the initial conversations to ensure expectations were set for what we were saying was needed – that development would mostly (but not completely) pause (although big up discoveries where we code or start to code). But I didn’t use it when we were talking about things like timescales, because I wanted to encourage flexibility. Instead I used ‘investigative phase’ or ‘research sprints’. I found that using language strategically, and not sticking strictly to certain words or definitions, helped convey that the suggested pivot was a positive and agile thing to do.
If you’re wondering whether to write things down, do
To share our thinking, and help us navigate through some internal governance, we collaborated on a recommendation paper. This stated:
- what we felt was needed
- why
- the outcome we hoped to achieve
- the risks of not doing what we recommended (these were were vital in getting the client’s agreement)
If you have a point to make, say it loud, say it plainly and have something that you can refer back to.
We’re more confident now
Before this, there had been some anxiety related to the particular part of the programme we were working on. The team and the wider programme felt like there was lots to do in a complex landscape with many unknowns, and we were getting closer to the end of the engagement. Now that we’ve run the investigative phase, we’ve validated building various features into the products that support our goals. And the programme understands where unknowns still lie and what’s out of scope.
It’s shaped a new team for the programme
With the known unknowns now surfaced, we’ve spun up a small analysis team to look at them and share recommendations. This team is actively mitigating the biggest risk the programme logged – not transitioning users away from key legacy technology, which is part of the improved user experience.
Our main takeaways
- Not following the order of the suggested service standards phases is being truly agile, and it facilitates pivoting quickly to what’s needed to deliver value. It’s enabled us to move faster, more flexibly, more confidently and make the best use of public money in the long run.
- Habits are formed and expectations set when things have been happening for a while. So you might find yourself in a situation where you need to break the mould using something that, in theory, is quite simple.
- Have the harder conversations early, so you can reach the easier conversations more quickly.
Now that we’ve dealt with the risks surrounding not reaching a key goal (which is what our client’s measure of success is for this engagement) we’re in a much stronger place. Our client’s much happier, we’re confident in our backlog, and any worries about time lost have been forgotten.