Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Scaling Scrum

Scott is a DDJ Senior Contributing Editor and author of numerous IT books. He can be contacted at www.ambysoft.com/scottAmbler.html.

Scrum is an agile methodology that focuses on a subset of project management and requirements management. Scrum has become popular in the past few years with the rise of agile software development, and is often used to round out Extreme Programming (XP); or perhaps XP is used to fill out Scrum, I guess it depends on your point of view. Scrum is particularly suited for "agile in the small" projects due to its simplicity, but as many organizations are finding, it can be a challenge to scale Scrum to meet the complexities of their real-world environments. The good news is that over the past few decades various people have identified a wealth of techniques which we can adopt and adapt to address these challenges.

Scrum was developed by Jeff Sutherland, John Scumniotales, and Jeff McKenna in 1993 during their work at Easel Corporation. It was then popularized through the efforts of Ken Schwaber and more recently by the Scrum Alliance (www.scrumalliance.org). Although there is a lot of material available online and in books about Scrum, my favorite resource is Mike Vizdos's www.implementingscrum.com site because it not only provides real-world advice for making Scrum work in practice, it does so in a light-hearted manner through the use of cartoons.

Figure 1 depicts the Scrum Construction lifecycle, modified from the lifecycle diagram presented by Jim Highsmith in Agile Software Development Ecosystems (Pearson Education, 2002) showing the fundamentals of the methodology. Scrum teams work from a product backlog, a prioritized stack of requirements maintained by the "product owner" who is responsible for working closely with the team to represent the overall stakeholder community. At the beginning of each "sprint", a timebox which is suggested to be 30 calendar days but can be any length in practice, the team identifies the requirements that they will implement during that sprint and plans out how they'll do it. At the beginning of each day throughout the sprint the team gets together for a 15-minute "scrum meeting" where each person indicates what they did yesterday, what they think that they'll do that day, and whether anything is blocking their progress. At the end of the sprint, the team should have produced a potentially deployable version of the system that they're developing which now implements the requirements that the team committed to at the beginning of the sprint. A demo is held with relevant stakeholders to obtain feedback and commitment to fund the next sprint. Many Scrum teams, as is the norm with agile teams in general, will hold a retrospective to identify potential improvements to the process that the team is following.

The lifecycle of Figure 1 is reasonable from a high-level point of view, but it leaves out a lot of detail. Scrum doesn't provide any advice for how to go about actual implementation; that's a detail that's left up to you. Nor does the lifecycle indicate how to initiate a project, or deploy your system into production at the end of the lifecycle. Recently Scrum has been touted as a process framework, but as you'll see a more accurate way to think about it is to view it as one part of the overall process picture. It is definitely a process framework from a consultantware point of view, and we've not only seen a consulting cottage industry grow up around Scrum but even an alliance of said consultants. I've found that to scale Scrum to meet the real-world needs of IT departments, you must consider the full development lifecycle and consider the full range of IT concerns.

[Click image to view at full size]

Figure 1: The Scrum Construction Lifecycle. Deliver a potentially shippable system every 30-day sprint.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.