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

Enterprise Concerns

Most IT departments have numerous systems in production, many currently in development, and many more under consideration. The implication is that to be truly effective you need to take the cross-system IT lifecycle into account, not just the system lifecycle. Yes, letting your architecture evolve over time is a great concept, but wouldn't it be great to take advantage of a common architecture and reusable assets? Yes, we want to implement requirements in priority order to achieve the highest return on investment (ROI) possible for that system, but wouldn't it be nice to work on the most important projects to begin with? Yes, it's nice that we can mock out access to data sources, but wouldn't it be great to easily work with existing data sources so that we don't have to create yet another silo database? Yes, retrospectives are great ways to identify potential improvements for a team to adopt, but shouldn't we have a mechanism to share those findings with other teams? We need to look beyond the needs of single project teams; otherwise, we've merely found ways to more efficiently create silo application, contributing to the overall maintenance burden within your organization.

You can, and should, be as agile as possible at these activities, and yes, you can choose to do so. A few years ago, I wrote The Enterprise Unified Process (Pearson Education, 2005) with Mike Vizdos, which described how to address the range of enterprise-level issues in as agile a manner as possible. The goal of these enterprise activities should be to support the overall organization as well as to enhance the efforts of project teams. The good news is that we're seeing greater focus on enterprise-level issues within the agile community. The bad news is that we seem to be reinventing the wheel. We don't need to because there's a lot of great material out there if we only choose to leverage it. The EUP clearly takes a lightweight, collaborative approach to enterprise activities, and the Information Technology Information Library (ITIL) v3 provides even greater detail if you're interested. You can find out more about the EUP at www.enterpriseunifiedprocess.com and about ITIL at www.itil-officialsite.com.

[email protected]

There's a lot more to software development than the construction lifecycle of Figure 1. Let's not get fooled by marketing rhetoric and let's not think that we need to reinvent the wheel just because we have a new generation of methodologists who are in the process of figuring things out yet again. There's a lot of value in Scrum, but we need to approach it with open eyes and recognize that it's only one part of the overall IT process solution.

Normalizing the Terminology

Scrum uses some strange terminology, a strategy that has its advantages and disadvantages. The primary advantage is that it helps people new to agile development to break out of their preconceptions as to how things should work. Yet this comes at a price. People initially find the terminology to be confusing because it really doesn't make much sense. For example, nobody "sprints" through a long-distance race. The term "Scrum Master" instantly evokes thoughts about someone wearing leather who whips people if they don't do what they're commanded, the exact opposite of what the role is really about. The term "Scrum meeting" makes no sense whatsoever to people who aren't familiar with rugby, and arguably "team huddle" or simply "daily stand-up" meetings are better terms. Worse yet, anyone who has ever played rugby will tell you that scrums are only fun up until the point that you get elbowed in the face. In short, more accurate terminology would be:

• Iteration or Time Box instead of Sprint.

• Coach or Team Leader instead of Scrum Master.

• Daily Stand-Up Meeting instead of Scrum Meeting.


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.