Restoring delivery confidence on a delayed regulatory programme
When Scrum revealed the real delivery constraint
A UK building society asked Adaptavis to help because a critical regulatory delivery looked, at first, like a delivery-method problem. Scrum had been introduced, more than 30 sprints had passed, the backlog was still growing, and the team still could not demonstrate a meaningful end-to-end member journey.
Scrum was the visible concern, but the bigger problem was how work was moving: too much was being started, defects were being found too late, and management responses were adding load rather than improving flow.
Adaptavis helped the building society see where work was queuing, feedback was delayed and defects were being created, and where well-intended responses to delivery risk were making the initiative harder to stabilise.
On time
Regulatory deadline met. The building society delivered in time for a significant regulatory commitment.
0%
Reduction in quality issues entering the constrained release and test loop, following earlier collaboration between testers and developers.
Reduced
Avoidable rework. Business analysts, developers and testers built shared understanding before development started.
Restored
Business engagement. End-to-end journey slicing gave the business something meaningful to review, test and respond to.
Rebuilt
Confidence. Trust and confidence with senior stakeholders and the regulator were restored.
Client context
The building society needed to deliver a secure two-stage authentication journey against a fixed regulatory deadline.
Visible problem
Around 60 people were involved, sprints were running, the backlog was still growing, and no meaningful end-to-end journey had been delivered.
What Adaptavis made visible
Rising work in progress, release constraints, delayed feedback, late defect discovery, unreliable evidence of progress, fragmented collaboration and the absence of end-to-end user outcomes.
What changed
The building society put more attention on finishing work already underway, testing it earlier and giving the business something meaningful to review. Fewer quality issues reached the slowest part of the release and test process, feedback loops shortened, and confidence in delivery returned.
Most relevant where
Delivery feels slow or hard to trust, backlogs keep growing, defects are found late, progress is hard to evidence, or leaders are carrying delivery risk on a critical commitment.
The business reality
This was a regulatory delivery commitment, not a low-risk experiment with a new way of working.
The building society needed to strengthen online member login through a secure two-stage authentication journey. The deadline was fixed, the consequences of failure were real, and the work mattered because it affected how members accessed online services securely.
The building society had chosen Scrum because it needed working software sooner and wanted a more iterative approach. It was the organisation’s first agile project, delivered through internal capability, so it was reasonable for leaders to question whether the method was working.
It also meant that when progress faltered, none of the familiar instruments applied. The traditional tools that would normally steer a programme through trouble did not fit the new way of working, and the experience to replace them had not been built yet, so when delivery became unstable there was little to navigate by.
The method was not the main reason progress was hard to evidence. Analysis and design had largely happened up front. Stories had been broken down in advance. Developers developed, testers tested afterwards, and work was moving between sprints without being genuinely finished.
After more than 30 sprints, delivery confidence was still low. The backlog was still growing. Defects were increasing. The business had started to disengage from demos because there was no meaningful end-to-end journey to review.
Why the obvious fixes made delivery harder
When delivery risk rises, adding people, reporting and control can feel like the responsible move. But if the constraint is feedback, quality, release flow or too much work in progress, those responses can increase the load on the very part of delivery they are trying to improve.
That was the pattern at the building society.
The people involved were working hard and making choices that made sense from a conventional management point of view. When delivery was not moving quickly enough, the organisation added more developers. When that did not solve the problem, more programme management was added, bringing more reporting, more updates, more meetings and more control. Senior people were also pulled from other work because the project was regulatory and the organisation was understandably risk averse.
None of those responses were irrational. They are the kinds of responses organisations reach for when the work is late and the risk is rising.
In this case, they added to the problem.
More developers created more work for a constrained release and test process. More programme management created more induced work: reports, updates, meetings and coordination activity. More pressure encouraged the organisation to start more work rather than finish what was already in progress.
When the extra people did not move the dates, attention turned to the estimates. Every piece of work already running late was stopped so it could be re-estimated, in case better numbers would help. That, of course, prevented anyone from finishing the work being estimated.
Contractors were brought in to recover the delivery. They were recruited by the people who were already behind, and they would take three to six months to get up to speed, coached by the same people, who were already behind. The attempted recovery increased the demand on the people and process already under the most pressure.
People were working hard. The problem was that more work was being started than could be finished, tested and reviewed.
What Adaptavis helped the building society do
01
Make the delivery work visible
Adaptavis helped the building society see how work was actually moving through the programme: where it was waiting, where it was blocked, where defects were being created, and where the boards and Jira data were not giving leaders enough confidence about reality.
The conversation moved away from whether the delivery method was working and towards the harder issue: whether work could move from analysis to development, test and business feedback quickly enough.
02
Stop starting more than the team could finish
Leaders and teams moved away from the logic of keeping every specialist occupied and concentrated attention on finishing the work already underway.
That meant limiting work in progress, focusing on blocked and unfinished work, reducing the overload created by starting too much, and treating collaboration as part of delivery rather than an interruption to it.
03
Shorten feedback around quality and user outcomes
Testers and developers began working together before work entered the constrained release and test loop. Business analysts, developers and testers built shared understanding before development started. The team also changed how work was sliced, moving from component progress to meaningful end-to-end member journeys the business could review.
Those practices mattered because they changed how work moved. The point was not to introduce more process; it was to reduce the amount of avoidable rework entering a release and test process that was already under pressure.
What Adaptavis made visible
Adaptavis helped the team look at the work from member need through to tested software, rather than through sprint ceremonies, specialist roles and status reports.
Five delivery conditions changed what leaders and teams could see, decide and improve.
Five conditions made visible:
- the release process was a real constraint, and avoidable rework was making it worse
- the team was starting more than it could finish
- defects were being discovered too late
- handoffs were creating avoidable rework
- component progress was not enough to restore business confidence
Each mattered because each changed what leaders and teams could see, decide and improve.
What changed in practice
The headline outcomes were visible at the top of the case. The operating shifts underneath those outcomes are what made them possible.
Leaders and teams could see where work was waiting, blocked, reworked or trapped in the constrained release process. More attention went to finishing work already underway, testing it earlier, and giving the business something meaningful to review.
Limits on work in progress and clearer collaboration policies helped reduce overload. Testing moved closer to development. Business analysts, developers and testers built shared understanding before work was committed. Work was sliced around end-to-end user outcomes rather than component progress.
The business re-engaged because it could see meaningful progress against a member journey. As stress reduced and collaboration improved, confidence began to return.
Operating shifts
01
More visible work
Leaders and teams could see where work was waiting, blocked, reworked or trapped in the constrained release process.
02
Earlier feedback
Testing moved closer to development, and business analysts, developers and testers built shared understanding before work was committed.
03
More meaningful review
Work was sliced around end-to-end user outcomes, giving the business something useful to test and respond to.
Adaptavis maintained delivery whilst transforming our ways of working, and always focused on the data. They worked with the most senior stakeholders but made time for the most junior members of the team. Adaptavis turned around a challenging delivery, and that is the thing that sets them apart.
Delivery Lead, UK Building Society
What other leaders can take from this
A delivery method cannot compensate for unclear work, late handoffs, delayed testing, poor evidence of progress or heavy governance.
Scrum did not create the queues, delayed feedback, testing policies or overloaded work in progress. It made them harder to ignore.
If an organisation rewards utilisation, starts more work whenever someone appears free, separates analysis from development and testing, discovers quality late, measures testers by defects found and treats management reporting as the answer to delivery risk, a delivery framework will not magically create flow. It will reveal the assumptions already shaping the work.
The building society did not need people to be blamed for the situation they were in. It needed the work to become visible, the constraint to be understood, and the policies around collaboration, testing, work in progress and slicing to change.
A method can provide cadence and visibility, but delivery confidence comes from more basic things: clear work, fewer handoffs, earlier testing, less partially finished work, and evidence the business can trust.
Could this apply to your organisation?
This kind of work is most relevant when leaders can see lots of work in motion, but still cannot trust delivery dates, progress evidence or the amount of rework in the system.
It may show up as growing backlogs, repeated carry-over between sprints, late defects, too much work in progress, low confidence in delivery dates, disconnected business demos, overloaded testers, unclear definitions of done, or more reporting and governance being added without improving flow.
The useful first step is not to blame the framework or push people harder. It is to understand how work is moving, where feedback is delayed, and which policies are causing work to queue, return as rework, or take longer than leaders expect.
If delivery feels slow, unpredictable or hard to trust, the Product Delivery and Flow Evidence Review gives leaders a fast, evidence-informed view of where work is being delayed, blocked or reworked, and whether the data leaders are using to make delivery decisions can be trusted.