Scrum Methodology - Agile Software Development

Scrum is a process for developing products such as software and quickly getting the products to the customer. Scrum is based on empirical controls through inspection and adaptation.

These controls are implemented through five basic practices:

1.        Iterations – All work is done in short iterations, usually lasting thirty days. Inspections occur at the end of every Sprint. The development project cannot proceed in the wrong direction, or in no direction, for more than one Sprint.

2.        Increments – An increment of working functionality is produced every Sprint. At the end of the Sprint, this increment is inspected. Artifacts and abstractions are not inspected, only the reality of the results of the Sprint.

3.        Emergence – Complex systems emerge unpredictably across time. Their end-state can be anticipated, but cannot be predicted. It is useless to try to predict their end-states, and any such predictions can be dangerously misleading. Scrum de-emphasizes traditional definitions of the requirements, architecture and design of the system. These factors are allowed to emerge across time and have successfully done so on thousands of agile projects.

4.        Self-organization – There are many unpredictable factors in software development, ranging from technology to personnel. Given this unpredictability, it is important that management and teams be are given full authority to plan and organize their work as they go, using their intelligence and creativity to deal with the unexpected. They rely on their experience. They also use any of the documented, defined development approaches (e.g. object modeling techniques, PERT charting techniques, use case requirements capturing) that they deem helpful.

5.        Collaboration – The prior control, “self-organization” works only if everyone collaborates freely and openly with each other, contributing based on their capabilities instead of their roles. The practices and working environment of agile processes facilitate collaboration, such as the open working environments and paired programming practices.

 A person trained in Scrum, called the ScrumMaster, is responsible for setting up all of the Scrum meetings and ensuring that all Scrum participants follow Scrum’s practices and rules. Scrum consists of iterations called Sprints. Each Sprint is thirty calendar days in length. During the Sprint, a development team (or team) builds an Increment of potentially shippable product functionality. To initiate a Sprint, a Product Owner meets with the Team for a 1-day Sprint Planning Meeting. At this meeting, the Product Owner reviews the top priority requirements on a Product Backlog, which is a prioritized list of all requirements that are known for the product or system at that time. The development team selects that top priority Product Backlog that it believes it can turn into an increment of potentially shippable product functionality (increment) within the next Sprint. Once the Product Owner and the development team have agreed on what Product Backlog to select (team selects the amount of top priority Product Backlog), the team develops a list of tasks needed to build the functionality. This list of tasks emerges throughout the Sprint and is called a Sprint Backlog.

The Sprint starts immediately after the Sprint Planning Meeting. Every day, the ScrumMaster meets with the development team for a short daily status meeting called the Daily Scrum. At the end of the Sprint, the development team, ScrumMaster, Product Owner, and other stakeholders (customers, users) meet at a Sprint Review Meeting. At this meeting, the development team demonstrates the increment of functionality that it developed during the Sprint.

The Scrum Process

The Scrum process consists of the following:

Sprint – a thirty-day iteration of work that results in an increment of product functionality;

Daily Scrum – a standup meeting where status is exchanged, progress is observed, and impediments noted and removed;

Product Backlog – an emerging, prioritized list of user requirements that originated in the product definition;

Sprint Planning Meeting - where each Sprint is planned;

Sprint Review Meeting - where the results of the Sprint are reviewed;

Sprint Backlog – a list of tasks that the team completes to turn product backlog into a product increment during a Sprint;

Increment - an increment of potentially shippable product functionality that a team builds every Sprint.

Key stakeholders:

Product Owner - the person responsible for maximizing the value of the product to the customers, users and    stakeholders;

Development Team - one or more small teams that develop the system or product;

ScrumMaster - the coach of the teams that is responsible for the Scrum process and the productivity of the teams;

These cycles are implemented through the following steps:

1.  A Scrum project starts with a vision of the system. The vision may be vague at first, stated in market terms rather than system terms. The vision will become clearer as the project moves forward. A metaphor of the system may also be defined to help guide development and to provide a tangible communication model between users and developers. An initial vision and metaphor can be usually created in a shortened Sprint.

2.  The Product Owner, ScrumMaster and development team define and prioritize an initial product backlog focusing on short-term requirements and releases that will extract the most value from the vision.

3.  The development team works during the Sprint to create an executable increment that contains the top priority requirements. The team selects as many requirements as it can build during the Sprint. They only build the architecture and design needed to deliver functionality for these requirements.

4.  The Product Owner continues defining requirements that will deliver value. They are added to the prioritized Product Backlog. The Product Backlog changes during the project as the business conditions change and as users respond to product increments.

5.   At the end of every Sprint, the Product Owner (and customers, users, and stakeholders) review the working system increment with the development team to see if it delivers the expected value, and – if not – what changes need to be made. These changes are added to and prioritized within the Product Backlog.

6.  When the Product Owner wants to realize the value achieved to date, he or she can request that product increments built to date be released. One or more Sprints will be used to polish and implement the system into a releasable product.

7.  Coordinating Scrum of Scrums are established to synchronize the work of the multiple teams

Multi team or Offshore development

When it is necessary to use more than one team, each team should select from the Product Backlog and work on areas that are as highly cohesive as possible and as loosely coupled to any work other teams are doing as possible. That is, each team’s work should be as independent of any other teams work as possible. The coordination required should be minimized.

As the teams begin their Sprints, each team coordinates its own work with Daily Scrums. If multiple teams are utilized, their work should be coordinated also by Daily Scrums, sometimes called Scrum of Scrums. These higher level coordinating Daily Scrums are held after the lower level Daily Scrums, are attended by one member of each of the teams to be coordinated, and operate exactly as any Daily Scrum - except that teams rather than team members are being coordinated.

In some projects, several coordinating levels of Daily Scrums are required. When this is necessary, the frequency of coordination can diminish in the higher level Daily Scrums (or bi-Daily Scrums, or Weekly Scrums), because the level of interaction diminishes.

When multiple teams are used, the project is still started by using one team, as follows:

1.   The Product Backlog is constructed so that important architectural, environmental, and infrastructure elements are at the top of the Product Backlog - along with some user functionality that will demonstrate the architecture in operation.

2.   A single team starts work on the Product Backlog and persists until a stable enough architecture, environment, and infrastructure is in place for more than one team to begin operation.

3.   The initial team is broken up and used to seed the multiple teams that begin Sprinting.

1.  The Business Architecture is divided into packets of functionality that are highly cohesive and have as little coupling between each other as possible. Each packet is named for its primary functionality.

2.  The Product Backlog has another column added to it for describing the business functionality packet to which each Product Backlog item belongs.

Each of the multiple teams chooses work for their Sprints from the Product Backlog that is as orthogonal to that of other teams as possible, that is, Product Backlog from the same packet of business functionality.

3.  The teams begin Sprinting, coordinating the work within teams using the standard Daily Scrum..

4.   Coordinating Scrum of Scrums are established to synchronize the work of the multiple teams.

The following diagram tries to summarize the previous paragraphs: