Method Overview


In terms of cycles and ceremony, Scrum classification is illustrated in Figure 7.1. Scrum is uniquely precise on the length of iterations: usually 30 calendar days, a more-or-less common length compared to other IID methods.[1]

[1] Shorter is legal, but 30-day iterations are encouraged.

Figure 7.1. Scrum on the cycles and ceremony scale


cycles and ceremony

Scrum is flexible on the ceremony scale; discussion of what and how many workproducts is outside its scope, as is how much rigor is required. As a guiding principle, the Scrum founders would say, "as little ceremony as possible." Also on a Scrum project, the whole team not a manager will decide how much is appropriate.

High levels for a medical device are acceptable, as are low levels for a casual-information read-only Web site.

In terms of scope on the Cockburn scale, Scrum covers the cells shown in Figure 7.2. Although one Scrum team should be seven or less, multiple teams may form a project. It has been used on both small projects and those involving hundreds of developers. Since Scrum practices include working in a common project room, it scales via a "scrum of scrums" where small teams work together and hold a daily stand-up meeting, and representatives from each those teams likewise meet daily. Scrum is complementary enough to other practices that it may be applied across all domains of software applications, from life-critical to more casual and it has.

Figure 7.2. Scrum on the Cockburn scale


Cockburn scale


Scrum [SB02] is an IID method that emphasizes a set of project management values and practices, rather than those in requirements, implementation, and so on. As such, it is easily combined with or complementary to other methods.

A key Scrum theme is its emphasis on empirical rather than defined process. Ken Schwaber, one of the Scrum founders, tells a noteworthy story in this context [SB02]:

empirical and defined methods

I wanted to understand why my customers' [waterfall and detailed-defined] processes didn't work for my [software] company, so I brought several methodologies to process theory experts at the DuPont Experimental Station in 1995. These experts, led by Babatunde Ogannaike, are the most highly respected theorists in industrial process control.[2]

They inspected the systems development processes that I brought them. I have rarely provided a group with so much laughter. They were amazed and appalled that my industry [software], was trying to do its work using a completely inappropriate process control model. They said systems development had so much complexity and unpredictability that it had to be managed by a process control model they referred to as "empirical." They said this was nothing new, and all complex processes that weren't completely understood [or had changing inputs] required the empirical model [and not the defined process model].

… [Ogannaike] said my business was an intellectually intensive business that required too much thinking and creativity to be a good candidate for the defined approach. … He was particularly amused that the tasks were linked together with dependencies [in a PERT chart], as though they could predictably start and finish just like a well-defined industrial process.

[2] Ogannaike has written one of the primary university textbooks on industrial process control; see [OR94].

Ogannaike's words echo Deming and Shewhart's industrial process control emphasis on cyclic Plan-Do-Study-Act for complex, changing systems and environments.

Shewhart and Deming

Agile and Iterative Development (Agile Software Development Serie. A Manager's Guide2003)
Agile and Iterative Development (Agile Software Development Serie. A Manager's Guide2003)
Year: 2004
Pages: 156 © 2008-2017.
If you may any questions please contact us: