How Your Agile Approach Became the Symptom, Not the Cure
Three years into a transformation, a government agency had real results — 40–50% cost savings, lower defect rates, certification passed. Yet something was blocking momentum that no process adjustment could fix. The research revealed why.
The situation
A mission-critical government agency operated a Command and Control system built on a sequential development approach. Requirements changed constantly; the system was slow to evolve, expensive to maintain, and inadequate to operational need. International security standards added further constraints.
Leadership made the decision to transform. Six teams were formed, sprints tailored to mission cycles, and over 40 developers, product owners, team leads, and senior managers brought into the initiative. The transformation would run for three years.
What nobody knew at the outset was that the transformation’s deepest barriers were not technical. They were organizational and human — hiding inside the decisions that seemed most obvious.
Developer skills — technical proficiency combined with the ability to work effectively with others — predict transformation success roughly four times more strongly than the effectiveness of process leadership roles. Yet these are the people organizations typically invest in least.
The approach
Researchers were embedded in the organization for the full three-year duration. They observed team dynamics in real time, conducted in-depth interviews at every level — developers, team leads, product owners, and senior management — and reviewed project documentation, contracts, and budgets.
The patterns identified were then tested through a separate survey of 190 software engineers who had participated in large-scale transformations, confirming the findings held across industries and organizational types.
What the research found
- The transformation delivered real results. 40–50% cost savings per line of code compared to the baseline. Defect rates dropped significantly. All functional areas passed certification. By conventional measures, it succeeded.
- Developer investment is the highest-leverage variable. The skills that determine whether a transformation succeeds live primarily with the people writing the code — their technical depth and their ability to collaborate under pressure. Organizations consistently underinvest here while overinvesting in process oversight.
- Management support works differently than assumed. When senior leaders simply announce a transformation, adoption stalls. When they actively remove impediments week by week and stay operationally involved, their impact — though indirect — is substantial. Announcement-level commitment is effectively no commitment.
- The patterns are not sector-specific. Validation across 190 engineers confirmed these dynamics appear equally in mission-critical and commercial contexts. They are structural, not situational.
If your transformation has stalled, the cause is almost certainly not the approach you chose. It is organizational. Specifically: where you are investing in people, how management is actually engaging day to day, and whether your developers have the environment they need.
Stop optimising process. Start optimising for developer capability and collaboration. Ensure managers are removing impediments weekly, not annually. Measure what matters — cost per function delivered, defect rates, cycle time — not ceremony adherence.
Does this describe a problem you are facing?
If your transformation is delivering process without culture change, or investment without results, a diagnostic conversation is the right place to start.