Scrum Extensions "Suspended"

Scrum extensions have been “suspended”.  That’s the most recent communication from Scrum.org on the community proposed, but controversial, new adjuncts to the scrum methodology.   Infoq’s coverage of scrum extensions started in late 2011 when Scrum.org 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.

“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 Scrum.org 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, Scrum.org will be happy to continue hosting the extensions that were proposed albeit as whitepapers, not endorsed extensions to the Scrum framework.”

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 Scrum.org control over what is, and is not, OK in Scrum. This is not good for anyone, even Scrum.org.

• 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

coaching.

 

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.