Scrum Process
Scrum ProcessScrum is an EmpiricalProcess (as opposed to a DefinedProcess) that uses two InspectAndAdapt cycles to manage product development. Scrum is great for software projects. Scrum software teams produce working software every 30 days. However, Scrum can also be used for non-software projects.
KenSchwaber and MikeBeedle, two of the creators of Scrum, have written the ScrumBook, a powerful introduction to the process.
To learn more about Scrum, take a look at the ScrumOverview, or visit some of these Scrum links:
People who are certified in Scrum are called CertifiedScrumMasters. The ScrumMasterCertification program is the best way to learn Scrum.
ScrumIsNotAnAcronym: please use Scrum or ScrumProcess instead of SCRUM. (Even if JeffSutherland does it on his SCRUM log)
The starting point on Wiki for Scrum used to be ScrumMethodology. The authors of Scrum call it the ScrumDevelopmentProcess. The author(s) of this page prefer the word process as well, because it avoids the MethodOrMethodology debate.
Content moved from ScrumMethodology:
One of many AgileProcesses, Scrum focuses on Project Management without dictating Software Development practices, although it has been very successfully used in conjunction with ExtremeProgramming (see http://www.xbreed.net).
The ScrumProcess is a formal RAD method especially suitable for quickly developing enhancements to an existing system which is experiencing frequent shifts in requirements. Its name derives from the "Scrum" (yes, from Rugby), which are <30 day "all in" development periods during which requirements DO NOT CHANGE and managers (by definition not part of the Scrum team) act only to remove obstacles. (called "ScrumSprints") It was developed and is taught by a consultant house. See the home page at http://www.controlchaos.com/ . -- MarkSwanson
All right, I'm going to give into the temptation to ask this here instead of going immediately to the tome, but I'm lazy and didn't want to get off track (just read a pattern about that somewhere here...)
Alexander says that interesting requirements emerge from within the system itself as it takes shape, which is one explanation of why purely requirements-driven methods falter. This realization came to him during his work on BaRt?? (as in BayAreaRapidTransit??), and was one of the transforming ideas that took him from a misfits philosophy to a pattern philosophy.
I'm not blaming Scrum as being one way or the other, but want to ask a clarifying question that may be open-ended:
During the one-month interval, does Scrum shut off only changes in external requirements, or does it ignore the requirements that emerge from within the system itself, too?
Whatever the answer, what is the rationale for treating these two cases as is done?
I've heard a lot about Scrum (the best kind of compliments - "oh, that's just my idea X by another name" - the sure sign of a good thing) but the above characterization, if true, worried me a bit.
-- JimCoplien
Great question, Jim. Scrum shuts off only changes to external requirements but **strongly** encourages resolution of the "generated requirements" for the scheduled functionality.
Therefore, it encourages the resolution of forces through customer feedback for a given functionality to the nth degree - as much as the time-box allows.
-- MikeBeedle
One reason this happens is explained in this example: A ProductBacklog item X was "guesstimated" at, say, 40 hours, and the team holds that SprintBacklog items should be <16 hours. So during SprintPlanning, ProductBacklog item X will be scinded into 6 separate SprintBacklog items X1 to X6. And, while discussing this, a new item Y is discovered (that should have been, but was not, on the ProductBacklog).
Eschewing BigDesignUpFront, Scrum acknowledges that it's more efficient to allow such items to emerge during SprintPlanning. Now, if item Y is estimated at 300 hours, and it's essential to the SprintGoal, I'd guess the ScrumMaster would call for ScrumSprintAbnormalTermination. On the other hand, if it's 300 hours and not essential, I believe Y could be pitched back onto the ProductBacklog.
-- DebHartmann July 7, 2003
I think this is one of the great strengths of Scrum, specifically of the ScrumSprint. It allows you to ignore the chaos from outside ("changes in external requirements") and focus on the chaos from inside ("requirements that emerge from within the system itself").
The above description of Scrum is a bit simplistic. Actually, Scrum is a collection of many practices (not just the one mentioned above) that seem to fit well together. A PatternLanguage maybe?
Rugby players scrum when they surround the ball and move it forward together. The word has been borrowed to describe a collective form of software development that is claimed to be distinctly different from traditional processes including waterfall, spiral and iterative development.
A scrum is a set play where the two teams forwards pack down and attempt to shove each other off the ball. Surround the ball to move it forward is mauling - generally one player takes the ball, burrows through or around a few paces, turns and sets so that his colleages can bind around him, then another player takes the ball and so on. Mauls generally end in one of three ways - the ball goes to ground, turning it into a ruck, the ball is passed out to the backs who run it (or not), or by some kind of infringement of the rule (offside, not joining the maul properly, etc, etc, etc).
Quite how this maps to software development, I'm not quite sure.
In Canadian politics a scrum is when a senior minister leaves the House of Commons and is surrounded in the hallway by the news media shoving their microphones forward and shouting out their questions. It is quite chaotic and unlike the structure Q&A found in a press conference.
There certainly is a scrum-like style of software development that is used successfully in developing a lot of open-source software like FreeBSD, Linux, the Apache webserver, and so on (see TheCathedralAndTheBazaar). It often ends up with one or a few people dominating the process and giving structure to the process but this structure is self-organizing out of chaos, not imposed from above.
I would have to say that this is definitely quite unlike the managed processes characterized by the waterfall, spiral and iterative processes.
I see some echoes of ExtremeProgramming here. My understanding is that ExtremeProgramming was not a designed methodology but one that emerged from the personal experiences of a few people applying some techniques which were known to work. I know that I have been using some of the techniques of ExtremeProgramming for a number of years such as TheSourceCodeIsTheDesign and YouArentGonnaNeedIt in developing business applications using a 4GL RDBMS environment called Progress. -- MichaelDillon (In fact, some of XP was derived from Scrum.)
This method does appear to some value (daily 15-minute meetings, adaptable, etc) on smaller, enhancement-type projects, but clearly would not work on multimillion dollar, highly complex, cross-functional, mission-critical custom development projects. These kinds of projects require the process-centric controls provided as part of PMI's PMBOK, IEEE's SWBOK, etc. -- RickWoods?, MBA, PMP, CCP
"Multimillion dollar, highly complex, cross-functional, mission-critical custom development projects." Which are like, 1% of all development projects? -- PaulEipper?
Having worked on a ScrumProcess project which certainly was multi-million dollar, more complex than the engineering team on staff could handle, and was positively cross-functional, and with great success, I call into question Mr. Woods' (MBA, PMP, CCP, and whatever other credentials he feels like waving around) thesis. I would have preferred if we used ExtremeProgramming instead, but I'll take what I can get, and Scrum has definitely vindicated itself. Without a precise definition of what each of these terms mean, in full isolation of each other, his statement is nothing but a troll. This is particularly true for that omnivacuous term, MissionCritical. --Samuel A. Falvo II
I used ExtremeProgramming (the real thing, not lip service) on a multimillion dollar, highly complex, cross-functional, mission-critical custom development project to rewrite, improve and integrate the entire police service and courts systems with one country to another. We delivered far more functionality than originally required and several months earlier than the deadline. It was a resounding success and the specs changed more times than you could count. I doubt using Scrum instead ExtremeProgramming would have killed the project, I bet it would be just as good. We of course didn't tell the client about pair programming or he would've flipped.
See: ScrumWebTool | ScrumMethodology | ScrumMeetings | ScrumStudyGroupRegistry
Contributors (of this and incorporated pages): MikeBeedle, DebHartmann, MichaelIvey
EditText of this page
(last edited September 12, 2012)
or FindPage with title or text search