XP can be used in conjunction with other development frameworks. XP has been successfully used with Rational Corporations RUP. This combination has been called the dX process and is also RUP-compliant (Martin, nd).

The Scrum Methodology

In the agile community is a light methodology developed by Jeff Sutherland. The name Scrum comes from the game of rugby, played by two teams of15 players with an oval ball. The ball is carried in the hand and may be passed backwards or laterally across the pitch or kicked in any direction. The opposing players attempt to halt the ball carrier by tackling him or her with their arms. Points are scored by:

Touching the ball down over the opponents goal line (a try, worth 5 points).

Kicking the ball above the crossbar and between the uprights of a large H-shaped set of posts. This may be done either from a place kick following a rule infringement (a penalty goal) or a kick from the hand, provided the ball strikes the ground before being kicked (a drop goal). Both types are worth 3 points.

A conversion, which is attempted after a try has been scored and is similar to a penalty goal except worth only 2 points.

The purpose of the scrum is to restart play quickly, safely, and fairly after a minor infringement or stoppage. From a methodology perspective, Scrum refers to the mechanism used in rugby for getting an out-of-play ball back into play. Scrum is a lightweight, agile methodology focusing on software development. Scrums two pillars are team empowerment and adaptability:

Team empowerment. When teams are given work to do, they are responsible for figuring out how to do it. The team does the best it can during each increment. While a team works, its only interaction with management is to tell management what is getting in the way and needs to be removed to improve productivity.

Adaptability. Scrum uses punctuated equilibrium. The team maintains equilibrium during each increment, insulated from outside disturbance. Increments are punctuated every 30 days so that the team and management can evaluate what should be done during the next increment; this decision is based on what the team has accomplished and what the environment dictates is the next most important thing to do.

Scrums ultimate goal is to deliver as much quality software as possible within a series (three to eight) of short time boxes (fixed-time intervals) called sprints that typically end every 30 days. Each stage in the development cycle (requirements, analysis, design, evolution, and delivery) is now mapped to this sprint(s). The traditional development stages are retained for convenience, primarily for tracking milestones. For example, the requirements stage may use

one sprint including the delivery of a prototype. The analysis and design stages may take one sprint each while the evolution stage may take anywhere from three to five sprints. Defined and repeatable processes work only for tackling defined and repeatable problems with defined people in defined environments.

Before any sprint is started, you define the required functionality for that specific sprint and then allow the project team to develop and deliver it. At the end of every 30 days, the project manager inspects the results, assesses changes in the business environment, and empirically determines what to do next. The goal is to stabilize the requirements during the sprint. Each sprint operates on a number of work items called a backlog. As a rule, no more items are externally added into the backlog within a sprint. Internal items resulting from the original preallocated backlog can be added. The goal of a sprint is to complete as much quality software as possible but, typically in practice, less is delivered.

The project manager or executive does not leave the sprint after completion; he or she remains engaged throughout until all the sprints are finalized. The project team holds daily project meetings called a Scrum in which the team quickly runs through the activities for the following day. The following items typically arise from the scrum meetings:

Potential management blockages and problem areas.

Action items for management.

Overall status of completed items to date for the sprint cycle.

Each sprint takes a preallocated amount of work from the backlog. The team commits to it. As a rule, nothing is added externally during a sprint. External additions are made to the global backlog. Blocks resulting from the sprint can also be added to the backlog. A sprint ends with a demonstration of the new functionality. Scrum meetings typically take place at the same time and place every day; therefore, they serve to build a strong culture. As such, Scrum meetings are rituals that enhance the socialization of status, issues, and plans for the team. The scrum master leads the meetings and logs all the tasks from every member of the team into a global project backlog. Scrum meetings allow the development team to socialize the team members knowledge and have a deep cultural transcendence. At the end of each sprint, there is a demonstration to:

Show the client whats going on.

Give the developer a sense of accomplishment.

Integrate and test a reasonable portion of the system being built.

Engage the team.

Ensure real progress reduction of backlog, not just the generation of more documents.

After gathering and reprioritizing leftover and new tasks, a new backlog is formed and a new sprint starts. In contrast, Scrum allows us to build softer software, so there is no need to write full requirements up front. We should recognize that it is impossible to have full requirements specified upfront or to freeze the context and environment. Requirements are written in a context. Our system transforms that context. New problems arise in the system and the new context (see Figure 4.3).

Figure 4.3: Scrum methodology. Source: SCRUM, Adaptive Development Methodology, SCRUM © 2002. Used with permission of the Agile Community.

Scrum is a knowledge-creating process with a high level of information sharing during the whole cycle and work progress. The keys to Scrum are deciding the completion date for production or release, prioritizing functionality, identifying available resources, and making major decisions about architecture. Compared to more traditional methodologies, the planning phase is kept short because we know that events require changes to initial plans and methods. Scrum uses an empirical approach to development where interaction with the environment is not only allowed but also encouraged, thereby changing the scope. Table 4.2 provides a summary of the Scrum methodology.

Table 4.2: Scrum demystified