DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. A Flaccid Scrum is a Missed Opportunity

A Flaccid Scrum is a Missed Opportunity

Steve Smith user avatar by
Steve Smith
·
Mar. 01, 13 · Interview
Like (1)
Save
Tweet
Share
5.97K Views

Join the DZone community and get the full member experience.

Join For Free
Without the disciplined technical practices provided by XP, Scrum projects will always flounder.  A classic post from 2010.

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.

scrum agile

Published at DZone with permission of Steve Smith, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Why It Is Important To Have an Ownership as a DevOps Engineer
  • What Was the Question Again, ChatGPT?
  • The Role of Data Governance in Data Strategy: Part II
  • Taming Cloud Costs With Infracost

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: