Moving beyond mechanical agile to quality and flow at scale

Context snapshot

Organisation: Large investment bank

Domain: Technology delivery at scale

Environment: Regulated, multi-asset, multi-geography

Scale: ~250 technologists across many squads

Operating model: Scaled Agile (SAFe) implemented at scale

Leadership challenge: Move beyond mechanical agility toward real flow, quality, and continuous improvement

Executive tension

This large investment bank had successfully implemented delivery at scale.

Through a disciplined adoption of Scaled Agile practices (SAFe), supported by a large number of trained practitioners and coaches, the organisation was able to coordinate work across many teams and geographies. Core SAFe ceremonies ran reliably, and large-scale planning events helped align people on objectives and dependencies.

Yet leadership looked for something more.

Although SAFe emphasises flow, continuous improvement, and collaboration, these were not materialising in practice. Teams discussed them, synchronised on them, and scheduled time for them — but the outcomes remained limited.

Big-room planning events were effective, but extremely time-intensive. Quality was discussed frequently, yet delivery dates consistently took precedence. Technical debt was acknowledged, but rarely reduced.

There was nothing obviously broken — but it was clear that more was possible.

Reframing the problem

This was not a failure of the framework or the operating model.

The setup was diligent, structured, and well-executed. The challenge was more subtle.

Agile practices were being applied mechanically rather than meaningfully.

Key team events had drifted from their original purpose:

• Sprint planning focused on task allocation rather than shared sprint objectives

• Daily stand-ups became status reports, positioning Scrum Masters as project managers

• Retrospectives rarely translated into sustained improvement

Quality, while valued rhetorically, was structurally secondary. Governance mechanisms rewarded delivery against time and scope, while quality was under-measured and therefore negotiable. Slipping a release to address quality was perceived as a failure; compromising quality to hit a date was accepted and often went unnoticed.

The organisation did not need another transformation.

It needed to change how people used what was already in place, and rebalance the system so that quality, flow, and improvement could genuinely coexist with delivery.

How we worked

1. Work with teams as teams

We worked directly with selected teams through systemic coaching sessions, focusing on how they functioned as teams rather than how well they executed tasks.

The work surfaced:

• What was pulling teams apart

• How accountability was being avoided or misplaced

• Where collaboration was breaking down

By opening these conversations, dysfunctions were addressed naturally and teams began working more intentionally together.

2. Re-anchor the Scrum Master role as a coach

Individual coaching with Scrum Masters revisited the fundamentals of Agile team events and their intended outcomes.

This was reinforced with Lean fundamentals:

• Visualisation of work

• Transparency

• Flow concepts

• Identifying and eliminating Waste

• Meaningful measures

• Explicit focus on software quality

Over time, Scrum Masters grew stronger as team coaches, reinforcing collaboration and collective accountability on a daily basis.

3. Establish engineering leadership and quality ownership

We worked with engineering leadership to identify an engineering lead in each team and connect them into a shared community.

This group:

• Collaborated on quality standards and practices

• Established a governance mechanism around engineering excellence

• Defined a feasible and shared Definition of Done

• Developed key DevOps capabilities to support and enforce the standards

For many teams, this created a clear reference point for quality for the first time — a necessary precondition for improvement.

4. Make continuous improvement real

Many teams believed they were producing quality simply because they were working hard and meeting deadlines.

By making practices explicit and visible, teams were able to “mark to market” and see where they stood. This created a constructive wake-up call and triggered genuine engagement in improving practices to raise both quality and performance.

5. Use a crisis to reset quality expectations

This engagement provided a rare opportunity to apply Andon principles — stopping work when a serious problem occurs — in a technology context.

When a major release was at risk and unlikely to meet its date, all work across ~250 people was stopped.

Within 24 hours:

• A small SWAT team retrofitted critical compliance changes onto the last known working release

• All other teams self-organised to improve quality standards, tooling, pipelines, and monitoring

This moment proved pivotal. It made quality non-negotiable and demonstrated that continuing work when a release is already failing is pure waste.

6. Strengthen multi-geo collaboration

Given the multi-geography setup, much of the work was conducted remotely. Shared documentation and collaboration practices were deliberately strengthened—an investment that proved critical when COVID-19 forced people to work from home rather than use the bank's in-house facilities.

Evidence of movement

While outcomes were not always immediately quantifiable, the shift in dynamics was clear.

• Team collaboration improved

• Scrum Masters strengthened their role as immediate coaches of the teams

• Teams created space for continuous improvement

The Andon intervention alone generated over 160 concrete improvements, addressing build stability, testing, pipelines, monitoring, and release predictability.

Quality became visible. Build status was displayed openly in team environments, and every failed build triggered an immediate swarm to restore it before any new work continued.

From that point on, quality was no longer aspirational — it was operational.

Inviting your reflection

Many organisations have implemented Agile and scaled Agile rigorously, following well-defined templates.

Now, many are asking: what’s next?

Agility and flow are not achieved by applying a framework correctly, but by continuously evolving how work is done in context.

• So what rigid templates are you still holding on to?

• What practices are being performed mechanically rather than intentionally?

• And who is challenging you to think about your system, rather than apply someone else’s method?

The next step is rarely another framework. It is learning how to evolve what you already have.

Talk about the work