Jeff Sutherland's Object World '96 Tutorial

SCRUM is an Organization Pattern

From: Michael A. Beedle
Date: Wednesday, December 03, 1997 1:01PM
To: Organization Patterns (e-mail)
Subject: SCRUM Revisited

Context

You are engaged in an activity that is difficult to control because its predictability is limited. For example, the activity may require constant change in directions, it may add new tasks as it unfolds, or it may require unforeseen interactions with many participants.
Activities such as scientific research, innovation, invention, architecture, engineering of any kind and software development typically exhibit such behavior common to "creative tasks".
As such, you may be a "knowledge worker", and engineer, a writer, a research scientist, a software developer or an artist; or a coach or leader that is overseeing the activities of a team such as a Coach, a Team Leader, a ScrumMaster, a Manager or a Firewall in a development team, etc. (From: Case Team,
Developer Controls Process [OrgPatt])

Problem

What is the best way to control an empirical and unpredictable
process such as software development, scientific research, artistic
projects or innovative designs?

Forces

Project plans in medium to large software projects typically fail
because estimates for assignments are hard to come up with. (There are
many sources for this uncertainties, for example: a) requirements are not
well understood, b) architectural dependencies are not easy to understand
and are constantly changing, c) there may be unforeseen technical
challenges with the technology, etc.)

Estimation is important. One must be able to determine what are the future tasks within some time horizon.
Planning and reprioritizing tasks take time. Using too much of the knowledge workers' time in planning meeting deceases productivity.
Architectural management leading to reusability is important.
Delivery of Customer driven software units such as Use Cases, must be driven to completion.

Solution

Meet with the team members for a short time in a daily SCRUM meeting. A SCRUM meeting is a 15. minutes meeting where each participant only answers the following 3 questions:

1) What they worked in the last 24 hrs. The ScrumMaster logs what tasks have been completed and what remains undone.
2) What blocks if any they found in performing their tasks within the last 24 hrs. The ScrumMaster logs all Blocks and later finds a way to resolve the Blocks.
3) What they will be working in the next 24 hrs. The ScrumMaster helps the team members choosing the appropriate tasks to work on with the help of the Architect. Because the tasks are schedule in a 24 hr basis the tasks are typically small (Small Assignments).

The SCRUM meetings typically take place at the same time and place every day. The ScrumMaster leads the meetings and he logs all the tasks from every member of the team into a global project Backlog. He also logs every Block and he resolves each Block while the developers work on the new
assignments.

SCRUMs can also be held by self-directed teams, in that case someone is designated as the scribe and also logs the completed and planned activities of the Backlog and the existing Blocks. All activities from the Backlog and the Blocks are then distributed among the team members for resolution.

The format of the Backlog and the Blocks can also vary, ranging from a list of items on a piece of paper all the way through software implementations over the INTERNET/INTRANET [Schwaber97]. The Scrum cycle can be adjusted according to needs but typically does not exceed the 48 hr. cycle or decreasing lower than 2 hrs.

SCRUM meetings not only schedule tasks for the developers but can and should schedule activities for everyone involved in the project such as integration personal dedicated to configuration management, architects, ScrumMasters (Firewall/Coach), etc.

Scrum meetings allow knowledge workers to accomplish mid-term goals typically allocated in Sprints that last for about a month.

Rationale

Because it is very easy to under- or over- shoot an estimate, that either leads to idle developer's time or to delays in the completion of an assignments respectively, it is better to sample frequently the status of small assignments. In other words, processes with a high degree of unpredictability cannot use traditional project planning techniques only, such as Gantt or PERT charts because the rate of change on what is being analyzed, accomplished or created is too high. Instead, constant reprioritization of tasks offers an adaptive mechanism that provides sampling of "systemic knowledge" over short periods of time. SCRUM meetings help also in the creation of an "anticipating" culture [Weinberg97], because they encourage "productive values":

increase the overall sense of urgency,
promote the sharing of knowledge,
encourage dense communications and
facilitate "honesty" among developers i.e. everyone has to give a daily status.

Simultaneously, this same mechanism, encourages the team members to socialize, externalize, internalize and combine technical knowledge on an ongoing basis, thus allowing technical expertise to become "community property" for the community of practice [Nonaka95]. SCRUM is therefore a ritual with a deep cultural transcendence.

Seen from the System Dynamics point of view [Senge94], software development has "scheduling" problem, because the nature of programming assignments has a rather "probabilistic" nature and estimates are hard to come by because:

1) inexperienced developers, managers and architects are involved in making the estimates
2) there are typically interlocking architectural dependencies that are hard to manage
3) there are unknown or poorly documented requirements, or
4) there are unforeseen technical challenges etc.

And therefore software development becomes a chaotic "beer game", where it is hard to estimate and control the "inventory of available developer's time", unless increased monitoring of small assignments is implemented [Goldratt90], [Senge90]. In that sense SCRUM meeting become the equivalent of a "thermometer" that constantly sample the new team temperature [Schwaber97-2].

Example

At Nike Securities in Chicago we are using SCRUM meetings since February of 1997 to run all of our projects including BPR and software development. Everyone involved in these projects receives a week of training in SCRUM techniques.

Resulting Context

A structure such as Case Team or Developer Controls
Process (using Form Follows Function) is jelled into a highly adaptable and
hyperproductive team structure.

References

[Goldratt90] E. Goldratt, Theory of Constraints, North River Press, Great Burlington (MA), 1990.
[Nonaka95] I. Nonaka and H. Takeuchi, The Knowledge Creating Company, Oxford University Press, New York, 1995.
[OrgPatt] Org Patterns web site
http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?ProjectIndex
[Schwaber97] K. Schwaber's, SCRUM web page, http://www.controlchaos.com
[Schwaber97-2] personal communication.
[Senge90] P. Senge, The Fifth Discipline - The art and Practice of the
Learning Organization, Doubleday/Currency, New York, 1990.
[Sutherland97] J. Sutherland, SCRUM web page,
http://www.tiac.net/users/jsuth/scrum.html
[Weinberg97] G. Weinberg, Quality Software Management - Vol 4., Anticipating Change. Dorset House, New York, 1997.

Other SCRUM patterns (not included here) - ScrumMaster (FireWall, Coach), Sprints, Backlog (Queue of Work), Small Assignments, Pigs and Chickens, etc.