Navigation

Introduction

The Traditional Waterfall Approach

Agile Methodologies

Conclusion- Choosing the Right Approach for the Task

Bibliography

Scrum

The term Scrum has its origins in Rugby, where it is an abbreviation for scrummage, which is a way of restarting a game after a penalty or after the ball has left play ("The Laws of Scrummaging", n.d.). It is a fitting term, as the Scrum methodology makes heavy use of stopping and restarting the project after short phases. Scrum's roots are in object-oriented development, and its focus is on short development cycles, often lasting 30 days or less. At the end of each of the development cycles, a deliverable is created (Jonasson, 99). Two fairly concise rundowns of Scrum are introduced in Figures 5 and 6, below.

Figure 5:

(Shojaee, 2008)

Figure 6:

(orionsweden, 2008)

Scrum was first proposed in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka (Schwaber, n.d.). The process was designed with the assumptions that requirements are not typically well understood early on in the development process, and they are likely to change. Furthermore, the software development process has been found to produce frequent surprises. (Jonasson, 2008).

Based on these assumptions and observations, Scrum was designed to be broken down into a series of small, manageable tasks, each with their own deliverable. These tasks can last anywhere from a few days up to 30 days. Furthermore, Scrum recommends a daily "stand-up" status meeting, so called because people are less likely to waste time if they are on their feet. During these meetings, project members communiciate their status, and the overarching plan is made visible to the team members and stakeholders. (Jonasson, 2008)

The team's facilitator is called the ScrumMaster. It is his or her job to run the stand-up meetings, remove obstacles from the paths of team members and provide a productive work environment free from distractions. He or she fills the Project Manager role by doing so. (Jonasson, 2008)

Scrum places a heavy emphasis on development, and significantly less emphasis on requirements. This is due to the assumption that requirements will evolve over the life of the project. Scrum practitioners believe that this emphasis of development over requirements leads to less wasted time (Jonasson, 2008).

The processes of Scrum can best be shown in chart form. Figure 7, below, provides a great example of the flow of the Scrum process:

Figure 7:

Scrum process

(mountaingoatsoftware.com, n.d.)

As you can see from the chart, you start with the Product Backlog, which is simply the list of requirements. You then break that down into separate Sprint Backlogs, which last 30 days or less and result in a deliverable. From there, you have a meeting once per day, for the life of the Sprint. Once the Sprint is complete, you end up with a deliverable, which is considered a product increment that is potentially ready to go.