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.
Community comments
My comment about Mike Cohn
by George Dinwiddie,
Re: My comment about Mike Cohn
by Mark Levison,
Whitepapers still exist
by Mark Levison,
Scrum has always been a pattern language
by Jeff Sutherland,
My comment about Mike Cohn
by George Dinwiddie,
Your message is awaiting moderation. Thank you for participating in the discussion.
My comment about Mike Cohn was taken from a discussion on the scrumdevelopment list (tech.groups.yahoo.com/group/scrumdevelopment/me...). It was not intended to cast any aspersions on Mike Cohn. Instead, it was offered as a possible reason why the scrum extension under discussion was called "Planning Card Game" instead of "Planning Poker."
The quote here, taken out of that context, is easily misunderstood. My quick email in response to Laurent's speculation was not edited for clarity, as I would have done for an article. I don't even know why those two quotes are included, as the name of the particular extension has no bearing on the creation or suspension of "Scrum extensions."
By the way, Mike Cohn assures me that he has no intention of preventing others from using the term "Planning Poker." His trademark was a protection against someone else, with less pure intent, gaining a trademark first.
Re: My comment about Mike Cohn
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
George - what quote I can't find the reference.
Cheers
Mark
Whitepapers still exist
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
Chris - you close the item with the question: "Still I’m left with this question: did the community lose a chance to augment and evolve Scrum". No. Scrum.org has promised to publish whitepapers. This seems like the right level - it makes clear that these are ideas can be useful in Scrum. However it also makes it clear that they're not required.
Cheers
Mark Levison
Certified Scrum Trainer | Agile Pain Relief Consulting
agilepainrelief.com/
Scrum has always been a pattern language
by Jeff Sutherland,
Your message is awaiting moderation. Thank you for participating in the discussion.
Scrum was a pattern language before the Agile Manifesto existed. See Pattern Languages of Program Design 4 (Software Patterns Series) by Neil Harrison (Editor), Brian Foote (Editor), Hans Rohnert (Editor) Addison-Wesley Pub Co; ISBN: 0201433044, 1999. Mike Beedle led the effort and Ken and I were coauthors of the Scrum pattern language paper. You can download it for free at jeffsutherland.com/scrumpapers.pdf
The extensions were an attempt to do something similar but was fraught with controversy. In addition, the few extensions proposed were not reviewed by scrum experts using the patterns process which has been developed over the last 20 years. This requires extensive review by both scrum and patterns experts and face to face editors workshop with these experts before anything would even be considered for publication. Mike Beedle and I have been working with Jim Coplien and scrumplop.org for years in workshops on updating and extending the Scrum pattern language. Scrum.org participated in our last workshop in May in Denmark along with many other companies, government organizations, and universities.
The patterns process for software is owned by the Hillside Group and scrumplop.org is an effort that is fully sponsored by the Hillside Group with two of the founders of the patterns movement assuring that a very rigorous process is followed involving a global group of Scrum experts. Having written several of the published Scrum patterns that I use regularly in my Scrum training, I can say that pattern writing requires a lot of work, is a community effort, involves a lot of critical feedback by experts, that cause writing and rewriting the pattern multiple times before it can even see the light of day.
There will eventually be a book on Scrum patterns similar to Organizational Patterns of Agile Software Development by James O. Coplien and Neil B. Harrison (Jul 26, 2004). It will take about seven years to write this book and we are only about two years into it. This kind of effort requires a global consortium of leading experts in the field over a very extended time period.
It should be noted that a pattern is not an extension to Scrum. It is a complex of problems, forces, solutions, and effects that must be seen in action is at least three different organizations. A pattern proposes a solution to a commonly seen problem and may or may not be useful to anyone doing Scrum. If they have a specific problem, they might try a proposed solution that has reliably worked on multiple occasions in multiple organizations. See hillside.net/patterns/ for a description of all things you would ever want to know about patterns.