Co-evolving agile and engineering in retail banking

Context snapshot

Organisation: Large UK retail bank

Domain: Engineering, Agile transformation, workforce capability

Environment: Legacy-heavy, large-scale, multi-stakeholder, multiple consultancies

Strategic initiatives:

• In-sourcing and in-shoring of engineering capability

• Agile transformation organised around value streams

• Engineering transformation to build in-house capability

Executive tension

The bank was embarking on two major modernisation initiatives at the same time.

On one front, it was in-sourcing and in-shoring engineering development after many years of outsourcing and off-shoring — a fundamental shift in capability, culture, accountability and leadership.

In parallel, it was rolling out an Agile transformation, restructuring the organisation around value streams and new ways of working.

Individually, both initiatives were strategically sound.

Together, they created significant tension.

Multiple change programmes were running in parallel, each with its own objectives, language, and governance. Engineering modernisation, Agile ways of working, and organisational redesign were progressing largely in isolation.

The risk was not lack of intent. It was fragmentation and confusion — with teams asked to absorb profound change without a coherent narrative, aligned capability development, or clear leadership expectations.

Reframing the problem

This was not an execution or commitment problem.

It was a co-evolution problem.

The bank was attempting to:

• Redesign its operating model

• Rebuild internal engineering capability

• Change how teams and leaders worked

— all at the same time, but without a shared frame connecting them.

Agile was being deployed as a way of working.

Engineering capability (DevOps, modern software practices) was being rebuilt as a technical programme. Skills and leadership development sat largely on the periphery.

What was poorly understood — and increasingly painful in practice — was that these elements could not succeed independently.

Agile ways of working without strong engineering foundations would stall.

Modern engineering without an aligned organisational design would fragment.

In-sourcing without deliberate capability and leadership development would overload teams and leaders.

The challenge was not to lead the transformation programmes, but to create coherence between them — particularly where the “intangible” aspects of skills, leadership, and ways of working were hardest to grasp and easiest to underestimate.

How we worked

1. Act as an intermediary between change programmes

We worked across the Agile transformation and engineering modernisation initiatives, helping surface misalignments and implicit assumptions.

The focus was on ensuring that:

• Agile ways of working were grounded in real engineering and DevOps capability

• Engineering practices were designed to support value-stream flow, not just technical excellence

• Conversations moved from abstract models to practical implications for teams

This helped reduce the contradiction between programmes that were nominally aligned but operationally disconnected.

2. Connect Agile and engineering capability development

A key part of the work was clarifying how Agile and engineering needed to co-evolve.

Rather than treating DevOps as a tooling or platform topic, we helped position it as:

• A core enabler of Agile delivery

• A leadership and team capability, not just a technical one

• Something that had to be learned through practice, not policy

This reframing helped teams and leaders understand why Agile adoption was stalling in places — and what needed to change underneath it.

3. Shape skills and leadership development with HR

We then worked with HR and programme leadership to bring structure to skills and leadership development — an area that was acknowledged as critical but poorly defined.

This involved:

• Designing training curricula aligned to the actual change journey

• Connecting engineering skills, Agile practices, and leadership expectations

• Making explicit the capabilities required at different stages of in-sourcing and transformation

The aim was not to create generic training, but to support people through a demanding transition with clearer expectations and progression paths.

Evidence of movement

The intervention helped create coherence across initiatives that were previously moving in parallel.

Agile deployment became better aligned with real engineering capability, reducing friction between intent and execution. Leaders gained clearer insight into how Agile, DevOps, and organisational design needed to evolve together, rather than being treated as separate tracks.

Skills development moved from an abstract aspiration to a more structured and practical capability journey, giving teams and leaders a clearer sense of what “good” looked like during in-sourcing and in-shoring.

While the work did not lead the programmes, it played a stabilising role — helping clarify blind spots, reduce confusion, and strengthen the bank’s ability to absorb multiple, simultaneous changes.

The bank began its in-sourcing journey with a more grounded understanding of the capability and leadership shift required after years of outsourcing and off-shoring.

Inviting your reflection

If your organisation is:

• Running multiple transformation programmes at the same time

• Treating Agile, engineering, and skills development as separate initiatives

• Underestimating the leadership and capability shift involved in in-sourcing

the challenge may not be pace or ambition.

It may be whether your change efforts are designed to co-evolve, or left to collide.