Agile Transformation

A delivery practice change focused on planning, feedback and shared language rather than adopting a named Agile framework.

Situation

Multiple software delivery teams were operating with different planning cadences, estimation practices and definitions of done. Stakeholders received inconsistent progress updates, and cross-team dependencies were surfaced late. The organisation wanted a more consistent approach to delivery without mandating a specific methodology.

Problem

Process change becomes ceremony unless it helps people make better decisions about real work. Introducing a standard framework by name would create the appearance of consistency without addressing the underlying communication gaps between teams and stakeholders.

Constraints

The approach had to respect existing team autonomy, delivery commitments and varying levels of experience with iterative practices. Teams could not be disrupted mid-delivery cycle.

My remit

I led the delivery practice change, working with teams and stakeholders to establish shared planning and review cadences, consistent progress language and practical feedback mechanisms that each team could adapt to their context.

Key decisions

The work focused on three structural changes: regular planning and review cycles visible to both teams and stakeholders, a shared vocabulary for describing delivery progress and risk, and explicit dependency-tracking across team boundaries. Deliberately not done: mandating a specific framework, standardised estimation or tooling, which would have undermined team ownership of the change.

Outcome

Teams gained a more explicit basis for discussing delivery progress, risk and improvement. The shared cadence and language reduced the effort required to understand cross-team dependencies and provide stakeholder visibility.

Lessons

Process earns its place when it changes the quality of decisions made by the people doing the work, not when it standardises their terminology.