Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Scrum Extensions "Suspended"

Scrum Extensions "Suspended"

This item in japanese

Scrum extensions have been “suspended”.  That’s the most recent communication from on the community proposed, but controversial, new adjuncts to the scrum methodology.   Infoq’s coverage of scrum extensions started in late 2011 when announced they would accept context aware modifications to the original scrum process defined by Ken Schwaber and Jeff Sutherland.  Since that time InfoQ has kept regular quarterly updates on  ( 2011 4th Quarter Update, 2012 1st Quarter Update ) on the evolution of Scrum extensions.

The news of the suspension was sudden and beckons the question “why?”.   Officially, according to the website:
“Organizations new to Scrum or struggling in adopting agile practices can benefit greatly from the wisdom and guidance of more experienced agile practitioners. Scrum extensions were proposed as a mechanism for delivering that guidance through community-vetted documentation of proven effective practices.
Although we at recognize the demand for such guidance, we have learned that extensions are not the desired way to provide it. We are grateful to those who proposed extensions to the community. Accordingly, will be happy to continue hosting the extensions that were proposed albeit as whitepapers, not endorsed extensions to the Scrum framework.”
But there can be little doubt that controversy enveloped the idea of scrum extensions from the outset.  The yahoo message boards covering the proposed extensions contained one poignant debate over the “Planning Card Game”, a proposed Scrum extension, which may have been the catalyst for the eventual downfall of Scrum extensions.   Some excerpts covering that conversation, featuring many prominent agile coaches and practitioners, including Ken Schwaber, are copied here.  
Mark Levison voicing his opinion on scrum extensions:
I'm deeply troubled by all these proposed extensions to Scrum. It feels like we're going down the path of RUP. I.E. here is a list of great practices, tune to fit your needs. The problem is that RUP novices tend to do many/most of the practices. Whereas the idea was to do a few. When I teach Scrum - I say early on: "Scrum is Simple and Incomplete". I go on to mention User Stories and Estimation (as per Mike Cohn etc). However I don't think they need to included in "Scrum" even as extensions. It seems like we're starting to tinker with a successful simple system. Here there be dragons.
Ron Jeffries echoing Mark’s sentiment:
I strongly object to the "Scrum Extensions" effort, but for somewhat different reasons. My reasons include:
The Extensions notion is clearly intended to give control over what is, and is not, OK in Scrum. This is not good for anyone, even
So far at least, the Extensions have not given credit to the original sources, nor to the many people who have been doing them for years. They often seem, in addition, to have been written up by people who have never really used them. This is a unique combination of disrespectful and ineffective.
To be successful in Scrum, teams need to do many things that are not specified by Scrum. The fundamental assumption of Scrum, self-organization, is that teams must, can, and will figure out what is best for them. The Extensions notion is in direct conflict with self-organization and is therefore damaging to the Scrum concepts and practice.
By blessing certain activities as "Extensions", other activities are at least implicitly not blessed. Yet there are many activities that are important and far more valuable than, say, this ripped off notion of card planning. The Extensions idea is more likely to stultify teams than it is to help them.
I like planning and estimating with cards, if one must estimate. (I do think estimation is usually a bad idea in actual practice.) I don't think anyone needs a Scrum Extension to try it nor to succeed with it. So far, all the proposed Extensions are like that: well known ideas that are better described elsewhere.
Ken Schwaber:
When Jeff and I first published Scrum, we put a number of practices in it, such
as release planning, format of the Sprint Backlog, and how to best structure the
Sprint Planning meeting. As people used Scrum, many devised alternative
practices that are also effective. As these practices emerge and prove to be
effective, we've been removing our "starter" practices from Scrum. This
encourages practitioners to use the most best of available practices for their
purposes. However, that leaves no guidance other than books, training, and
We decided that a practices model, called extensions, would help Scrum
practitioners. We call the practices Scrum extensions since we are Scrum
centric. While these practices are not specific to Scrum. Scrum uncovers the
problems that result if the Scrum Teams are not competent in using one or more
of them. When used intelligently, these are practices that should increase the
probability of developing high quality, valuable software while managing risk
and predictability.
These practices certainly will not be perfect (what is?). However, they will be
powerful, useful and instructive. They will evolve across time. We will either
attribute them correctly in the initial publication or later when notified of
the correct author. We will certainly attribute planning poker to James Grenning
and help people understand that the numbers in the Fibonacci set are the sum of
the prior two numbers (1,2,3,5,8,13,21,34 ...).
These will be practices that we and people in the Scrum community have used and
we think are useful. We will publish and recommend them to the Scrum community
after an edit/review process.
I feel a need to state again: these extensions are not part of Scrum. They are
software development best practices whose need Scrum exposes. When I go into a
paint store, there are pamphlets that recommend how to paint clean edges, how to
remove old paint, and how to fill holes. You can paint without them, but the
results may not be desirable. The same relationship exists between Scrum and
software development practices.
All of have observed that our profession needs help, every bit that it can get.
I thank everyone for attributing good intentions to this effort.
In the end it appears that those against Scrum extensions convinced the leadership.  Brett Wortman’s comment probably typified the perspective of  many:  “The charm of Scrum is its simplicity and its incompleteness. That's why it works so well.”.   Still I’m left with this question: did the community lose a chance to augment and evolve Scrum or was it best to kill this experiment before it took flight?  And even further…how will this decision affect emerging ideas like a scrum pattern language?


Rate this Article