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, suchas release planning, format of the Sprint Backlog, and how to best structure theSprint Planning meeting. As people used Scrum, many devised alternativepractices that are also effective. As these practices emerge and prove to beeffective, we've been removing our "starter" practices from Scrum. Thisencourages practitioners to use the most best of available practices for theirpurposes. However, that leaves no guidance other than books, training, andcoaching.We decided that a practices model, called extensions, would help Scrumpractitioners. We call the practices Scrum extensions since we are Scrumcentric. While these practices are not specific to Scrum. Scrum uncovers theproblems that result if the Scrum Teams are not competent in using one or moreof them. When used intelligently, these are practices that should increase theprobability of developing high quality, valuable software while managing riskand predictability.These practices certainly will not be perfect (what is?). However, they will bepowerful, useful and instructive. They will evolve across time. We will eitherattribute them correctly in the initial publication or later when notified ofthe correct author. We will certainly attribute planning poker to James Grenningand help people understand that the numbers in the Fibonacci set are the sum ofthe 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 andwe think are useful. We will publish and recommend them to the Scrum communityafter an edit/review process.I feel a need to state again: these extensions are not part of Scrum. They aresoftware development best practices whose need Scrum exposes. When I go into apaint store, there are pamphlets that recommend how to paint clean edges, how toremove old paint, and how to fill holes. You can paint without them, but theresults may not be desirable. The same relationship exists between Scrum andsoftware 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.