A Flaccid Scrum is a Missed Opportunity

Martin Fowler wrote a prescient article two years ago about the rise of Flaccid Scrum. Having recently worked on an agile project that could act as Exhibit A for Flaccid Scrum, I have hardened my opinion on Scrum to the point where I believe that Scrum cannot succeed without XP-style technical practices.

Flaccid Scrum is described by Martin as a scenario in which a Scrum team “adopts the Scrum practices, and maybe even the Scrum principles” but “after a while progress is slow because the codebase is a mess”, because “they haven’t paid enough attention to the internal quality of their software”. It is postulated that this occurs because Scrum is management-oriented rather than engineering-oriented, and this slight on Scrum is not an unknown unknown to the Scrum community.

Scrum is an agile management methodology, and deliberately omits all mention of engineering practices. Mikael Boman over at the Scrum Alliance talks of recommending technical practices to Scrum Product Owners – namely version control, continuous integration, automated testing, refactoring, simple design, and collective code ownership – but while these are enforced by XP, they are implicit in Scrum.

Stephan Schmidt has neatly encapsulated my reservations about Scrum in a single article, by asserting that “Scrum creates self organized teams. They organize themselves, they organize their quality. They organize their tools. They organize their engineering practices (TDD, pair programming)“, and that “often quality and craftsmanship are organized by a level of done agreement in the team“.

On the latter point, I disagree that a Definition Of Done checklist is the correct place for a team to agree upon its technical practices. A Definition Of Done details a shared understanding of what the phrase “production ready” means to a team. Technical practices are a method of implementing that shared understanding, and should be captured in a separate working agreements document.

On the former, the idea that a Scrum team will immediately and automatically self-organise is illusory, and shows the inherent flaw in Scrum’s reliance upon implicit inference of technical practices. An agile team evolves to be self-organising once it is comfortable with its own process and a sustainable cadence of successful delivery has been established. Until that tipping point, I believe there is far more opportunity within a Scrum team than an XP team for well-meaning developers to misinfer, misinterpret, or miss altogether a technical practice.

Having worked on Exhibit A, I would agree with all of Martin’s points and say that a Flaccid Scrum is a missed opportunity for the business and all team members involved. Exhibit A is a Scrum project with buy-in from the business, well-intentioned team members, and an established sprint planning/review/demonstration cycle. However, its underlying codebase is shockingly bad, with every imaginable type of TechnicalDebt exhibited at the architectural and the component level. The lack of enforced test-driven development or pair-programming frequently introduces further quality problems, and the project as a whole is an unhappy example of a Gumption Trap.

In the future, when applying for Scrum-based roles I will have to work harder to identify upfront if the project is in fact an irretrievable Flaccid Scrum on the scale of Exhibit A. As well as asking general process questions to assess the level of agile maturity in the organisation, I will also have to explore the size and permanence of the disjunction between the Scrum principles and underlying technical practices. Hopefully this will prove to be an effective early warning system against Flaccid Scrum.