The Agile Transformation That Stalled
A financial services company launched an agile transformation two years ago. They adopted Scrum for all development teams, hired agile coaches, and implemented DevOps tools. However, the promised benefits – faster time to market, higher quality – have not materialised. The average release cycle is still 6 months, and defect rates have increased by 20%. A post-implementation review found that: (1) business product owners are not empowered to make decisions; they must escalate to a steering committee that meets monthly; (2) the architecture is a monolithic core system that requires coordinated releases across 12 teams; (3) testing is still done by a separate QA team after development, causing bottlenecks; (4) the definition of done does not include automated testing or security checks. The CIO wants to abandon agile and return to waterfall, arguing that agile does not work in a regulated environment. The head of engineering argues that they have not truly adopted agile; they are doing 'agile in name only'.
1. Diagnose why the agile transformation failed to deliver benefits, and evaluate the CIO's proposal to return to waterfall. Recommend a path forward.
Read the worked answer
The failure is due to incomplete adoption of agile principles, not agile itself. Diagnoses: (1) Lack of empowered product owners – decisions are escalated, so teams cannot respond quickly. (2) Architectural mismatch – a monolithic system with 12 teams requires coordination, which negates agile team autonomy. (3) Separate QA team – creates handoffs and delays, contrary to cross-functional teams. (4) Definition of done missing automated testing and security – leads to technical debt and defects. The CIO's proposal to return to waterfall would not solve these issues; waterfall would likely worsen time to market. Instead, the firm should: (a) Empower product owners with clear decision rights and budget; (b) Invest in architectural refactoring towards modular services (e.g., microservices) to enable team autonomy, but do so incrementally; (c) Integrate testing into teams (shift-left), with automation; (d) Update definition of done to include automated tests and security scans; (e) Provide training and coaching. In a regulated environment, agile can work with appropriate controls (e.g., automated compliance checks). The head of engineering is correct: they need to deepen agile adoption, not abandon it.
2. Explain how the definition of done should be revised to incorporate quality and security, and how this would address the defect rate increase.
Read the worked answer
The definition of done (DoD) should be a team-owned checklist that ensures every increment meets quality and security standards. It should include: (1) Code reviewed by a peer; (2) Automated unit tests written and passing with minimum coverage (e.g., 80%); (3) Automated integration tests passing; (4) Security static analysis (SAST) and dependency scanning performed, with no critical vulnerabilities; (5) Performance tests for critical paths; (6) Documentation updated; (7) Product owner acceptance. By including these, defects are caught earlier, reducing the 20% increase. The separate QA team should be integrated into the team to provide expertise, but the team as a whole is responsible for quality. This shift-left approach reduces handoffs and bottlenecks. The DoD should be reviewed regularly and adapted. This addresses the root cause of defects: lack of built-in quality. It also aligns with agile principles of technical excellence and continuous attention to quality.