Scrum Values and Scrum Processes

Introduction 

SCRUM is a loose set of guidelines that govern the development process of a product, from its design stages to its completion. It aims to cure some common failures of the typical development process, such as:

• Chaos due to changing requirements – the real or perceived requirements of a project usually change drastically from the time the product is designed to when it is released. Under most product development methods, all design is done at the beginning of the project, and then no changes are allowed for or made when the requirements change.

• Unrealistic estimates of time, cost, and quality of the product – the project management and the developers tend to underestimate how much time and resources a project will take, and how much functionality can be produced within those constraints. In actuality, this usually cannot be accurately predicted at the beginning of the development cycle.

• Developers are forced to lie about how the project is progressing – When management underestimates the time and cost needed to reach a certain level of quality, the developers must either lie about how much progress has been made on the product, or face the indignation of the management.

SCRUM has been successfully employed by hundreds of different companies in many different fields, with outstanding results.

You will find many similarities between scrum and Extreme Programming, but one of the major differences is that scrum is a fairly general set of guidelines that govern the development process of a product. For this reason, it is often used as a “wrapper” for other methodologies, such as XP or CMM (Capability Maturity Model) – that is, it is used to guide the overall process of development when using these other methodologies.

ScrumValues

 The scrum values are derived from the Agile values of software development.

• Individuals and interactions over processes and tools – processes and tools are helpful, but they will do you no good if the team does not communicate and collaborate in a constructive fashion.

• Working software over comprehensive documentation – documentation is important, but what’s most important is to have working software.

• Customer collaboration over contract negotiation – you are not just looking to get a contract and get money that way – you are solving the customer’s problem.

• Responding to change over following a plan – if the requirements or perceived requirements changed, so should the plans and design.

The Scrum Process

General Scrum Process

The scrum process has 3 main phases.

Planning

In this phase, the project is planned and high-level design decisions are made.

Sprint Cycle

The sprint cycle is an iterative cycle of about 3-4 weeks, in which the actual development of the product is done. It starts out with a Sprint Planning Meeting to decide what will be done in the current sprint. Then the development is done. A sprint is closed with a Sprint Review Meeting where the progress made in the last sprint is demonstrated, the sprint is reviewed, and adjustments are made to the project as necessary.

The sprint cycle is repeated until the product’s development is complete. The product is complete when the variables of time, quality, competition, and cost are at a balance.

• Develop the product further – implement, test, and document.
• Wrap up the work – get it ready to be evaluated and integrated.
• Review the work done in this sprint.
• Adjust for any changes in requirements or plans.

Closure

In this phase, the product’s development is brought to a close, and the product is released.

The Scrum Team

 The scrum team consists of 2 groups – the interested team, which consists of people who are interested, but who will not be doing the work, and the working team – people who are interested, and will be doing the work on the project.

A team typically has no more than 6-9 working members, although scrum has been successfully used with more members. If there are more members than manageable, the project should be broken into multiple sub-projects, each focusing on one, self-contained area of work (one for QA, one for documentation, etc.). There should be people to act as bridges – that is, to attend the meetings of more than one scrum team, and act as a communication bridge between the teams. Members of teams that are closely related/involved with each other should sit in on the other teams’ SCRUM meetings.

The leader (Scrum Master)

 The team’s leader is called the Scrum Master. He should be one of the members of the working team – that is, he should be one of the people who is actually doing the work on the project. The SCRUM Master measures progress, removes impediments, and leads the team meetings.

Commonly Used Terms 

Sprint

The product is developed in a series of 1-to-4-week iterations, or sprints. Before a sprint is begun, a Sprint Planning Meeting is held to determine what features are to be implemented in that sprint. The sprint has 4 major steps:

• Develop the product further – implement, test, and document.
• Wrap up the work – get it ready to be evaluated and integrated.
• Review the work done in this sprint.
• Adjust for any changes in requirements or plans.

 Product Backlog

A prioritized list of all the desired changes to the product being developed, put together by the product owner. See Figure.

Sprint BackLog

A list with items that will be completed in the current sprint, taken from the product backlog. See Figure

The SCRUM Sprint Cycle

Daily Scrum Meeting

A 15-minute scrum meeting is held every day. The scrum Master asks the three questions, and all members of the team and interested parties take part and give feedback. The meeting should be held at the same place every time, so that people know where to go.

Unit Testing

A unit test is an automated test that ensures that the functionality required for a certain area of a project is implemented, and that there are no breaking changes that have not been taken into consideration.

Impediment

Impediments are things that get in the way of the progress of the project. The scrum Master is responsible to look for and remove these obstacles so that they do not slow down or impair the project.

3 Questions

The Scrum Master asks the developers 3 important questions at every scrum meeting:

1. What have you accomplished since the last meeting?
2. Are there any obstacles in the way of meeting your goal?
3. What will you accomplish before the next meeting?

Product Owner

The person who commissions the project, and defines the requirements and priorities for the product.

Sprint Planning Meeting

A meeting at the beginning of a sprint where the sprint is planned. Items from the Product Backlog are selected to be completed in the sprint, based on the priorities set by the Product Owner.

Sprint Review Meeting

A sprint is closed with a Sprint Review Meeting where the progress made in the last sprint is demonstrated, the sprint is reviewed, and adjustments are made to the project as necessary.

Learn more about – What is Agile? What is Scrum?

What is Agile? What is Scrum?

In software development Agile is a set of values and principles formulated by a group of the industry leading figures in 2001.

Scrum is a concrete software development model that can be traced back to 1995 and was created by two of the original signatories of Agile Manifesto. Scrum supports Agile values. Note that Scrum is for project management, it is not a development methodology.

The early approach to software project management usually referred to as “waterfall model” implies a sequence of clearly defined steps necessary to complete any project: define, plan, organize, execute and then close.

This represents a very neat, simple and above all convenient abstraction from the project management theorist point of view. When one stage follows another it is possible to define clear inputs and outputs for each stage, isolate and identify techniques and tools that are most useful at every phase. This is a clear example of reductionism in tackling project management complexity: keep splitting the whole into smaller bits until you get to understand each bit in isolation and then hopefully you will master the mechanics of their totality.

But as soon as the waterfall abstraction was presented it started to leak. Firstly it turned out that real-life process cannot be clearly cut into stages, often definition is still changed on what it seems to be planning, organization or even execution stage. So, in theory, the stages were allowed to overlap and theoreticians started drawing all sorts of diagrams there it’s possible to see how the definition stage gradually runs out as execution starts picking up during the organization stage. Then, again only in theory, it is possible to accurately estimate during the planning stage how long it is going to take to develop a piece of software. Obviously, in actual practice, the estimates and other plans have to be tweaked right through the execution phase which gave birth to a string of complex yet not very meaningful methods as Earned Value Management.

The chronic problems with the waterfall abstraction gave birth to a number of “agile” project management methods (Agile, Scrum, XP Programming etc) that despite many differences at the more detailed level use the same fundamental principles to tackle product development complexity:

• The project is organized as a number of small iterations through the classic project stages (definition, planning, organization, execution and closure).
• Each iteration aims at a relatively small yet semantically complete increment in product functionality or non-functional characteristics.
• Strong end-user involvement throughout the project.

Since every iteration goes through a separate definition and planning stage the time horizon for various estimation and planning activities is greatly reduced. It helps achieve greater accuracy, hence make it easier to access feasibility, measure value and costs etc.

Small increments help controlling the scope, evaluate utility of the changes and keep users involved since there is always a fresh version of fully functioning product. It is also much easier to organize a number of teams working on a large project simultaneously when increments are kept small, this really helps tackling task dependencies.

 

Agile is a methodology, and there are various ways to define what agile is. To a large extent, if it involves constant unit testing and the ability to quickly adapt when the business needs change then it is probably agile. The opposite is the waterfall method.

There are various implementations that are codified by consultants, such as Xtremem Programming, Scrum and RUP (Rational Unified Process).

Agile is a collection of practices. While there is no formal definition of the collection of agile practices, there are studies that have measured the effectiveness of various agile practices.

Broadly, the agile practices can be categories into two groups, management practices and engineering practices. SCRUM is the most popular set of management practices. XP or Extreme Programming is the best known set of engineering practices.

If an agile team only employees the management practices, i.e., SCRUM, they are likely to be unable to maintain a sustainable pace for an indefinite period of time. For example, without automated functional tests, it will take longer and longer to validate each iteration. If you don’t use pairing or Test Driven Development, you are likely to find your defects grow out of control.

Management practices enable the team to collaboration successfully with the business partner. Prioritizing what need to be done, working collaboratively against scope in priority order. SCRUM, by itself, will provide benefit immediately. Management practices tend to be the easiest to learn and put into practices.

Examples of management practices are open workspace, product owner, prioritized product backlog, iteration, iteration and release planning meetings, show & tell etc.

While the engineering practices are more difficult to learn and execute well, they are essential if a team is to maintain a sustainable pace of high quality software. Examples of engineering practices are developer pairing, test drive development, simple evolutionary design, automated functional and performance tests, continuous integration and collective code ownership.

Agile provides alternative ways to achieve the same business goals. IMO agile is less intuitive but works better in practice. The agile approach says it’s impossible to know every detail up front for all but the smallest/simplest projects and that the project should be able to accommodate surprises and updated requirements. Further, by completing and verifying software features in order of importance, touching all relevant architectural layers along the way, agile can make it more possible to have a useful product by the deadline demanded by the business side.

Learn more about – Scrum Values and Scrum Processes