Overview:

What is Scrum?

Scrum is an iterative, incremental process for developing any product or managing any
work. It produces a potentially shippable set of functionality at the end of every iteration. Its
attributes are:

• Scrum is an agile process to manage and control development work.

• Scrum is a wrapper for existing engineering practices.
• Scrum is a team-based approach to iteratively, incrementally develop systems and
products when requirements are rapidly changing
• Scrum is a process that controls the chaos of conflicting interests and needs.
• Scrum is a way to improve communications and maximize co-operation.
• Scrum is a way to detect and cause the removal of anything that gets in the way of
developing and delivering products.
• Scrum is a way to maximize productivity.
• Scrum is scalable from single projects to entire organizations. Scrum has controlled
and organized development and implementation for multiple interrelated products
and projects with over a thousand developers and implementers.
• Scrum is a way for everyone to feel good about their job, their contributions, and that
they have done the very best they possibly could.

Scrum naturally focuses an entire organization on building successful products. Without

major changes -often within thirty days - teams are building useful, demonstrable product
functionality. Scrum can be implemented at the beginning of a project or in the middle of a
project or product development effort that is in trouble.

Scrum is a set of interrelated practices and rules that optimize the development
environment, reduce organizational overhead, and closely synchronize market requirements
with iterative prototyes. Based in modern process control theory, Scrum causes the best
possible software to be constructed given the available resources, acceptable quality, and
required release dates. Useful product functionality is delivered every thirty days as
requirements, architecture, and design emerge, even when using unstable technologies.

Over fifty organizations have successfully used Scrum in thousands of projects to manage
and control work, always with significant productivity improvements. Scrum wraps an
organization's existing engineering practices; they are improved as necessary while product
increments are delivered to the user or marketplace. As heard about Scrum, "oh, that's just
my idea X by another name". Except, Scrum is spelled out as values, practices, and rules in
a development framework that can be quickly implemented and repeated.

Scrum has been used to produce financial products, Internet products, and medical products
by ADM. In every instance, the organization was logjammed, unable to produce shippable
products for such a long period of time that engineers, management, and investors were
deeply concerned. Scrum broke the logjam and began incremental product delivery, often
with the first shippable product occuring with the same quarter.

Scrum as applied to product development was first referred to in "The New New Product
Development Game" (Harvard Business Review 86116:137-146, 1986) and later elaborated
in "The Knowledge Creating Company" both by Ikujiro Nonaka and Hirotaka Takeuchi (Oxford
University Press, 1995). Based on their ideas and research in process theory performed in
collaboration with DuPont Advanced Research Facility, Scrum was first formulated and
presented to the Object Management Group in 1995. The Scrum process is fully described in
a recent book from Ken Schwaber and Mike Beedle, Agile Software Development with Scrum
(Prentice Hall, 2001). An excerpt of that book can be read here.
How it Works:
What is Scrum?
A variation on Sashimi, an "all-at-once" approach to software engineering. Both Scrum and
Sashimi are suited best to new product development rather than extended
development.�� Sashimi originated with the Japanese and their experiences with the
Waterfall model.�� They had the same problems with the Waterfall model as everybody
else, so they adapted it to suit their own style.�� Realizing that speed and flexibility are as
important as high quality and low cost they reduced the number of phases to four --
requirements, design, prototype, and acceptance -- without removing any activities, which
resulted in overlap of the Waterfall phases.�� Then they made the four phases overlap.��
(Sashimi is a way of presenting sliced raw fish where each slice rests partially on the slice
before it).�� Other companies took Sashimi one step further, reducing the phases to one
and calling it Scrum.�� (A scrum is a team pack in Rugby, everybody in the pack acts
together with everyone else to move the ball down the field).
�
Applying Scrum
For each Waterfall phase there are a pool of experienced people available, form a team by
selecting one person from each pool.�� Call a team meeting and tell them that they have
been selected to do an important project.�� Describe the project, include how long it's
estimated to take, how much it is estimated to cost, how it is expected to perform, etc.��
Now tell them that their job is to do it in half the time, with half the cost, twice the
performance, etc.�� Tell them how it's done is up to them and explain that your job is to
support them with resources.�� Now leave.

Stand by, give advice if it's requested, and wait.�� Don't be surprised if a team member
thinks the whole thing is insane and leaves.�� You'll get regular reports, but mostly you'll
just wait.�� At somewhere around the expected time, the team will produce the system
with the expected performance and cost.
�
How does Scrum work?
The first thing that happens is the initial leader will become primarily a reporter.� �The
leadership role will bounce around within the team based on the task at hand.�� Soon QA
developers will be learning how requirements are done and will be actively contributing, and
requirements people will be seeing things from a QA point of view.�� As work is done in
each of the phases, all the team learns and contributes, no work is done alone, the team is
behind everything.�� From the initial meeting, the finished product is being developed.��
Someone can be writing code, working on functional specifications, and designing during the
same day, i.e. "all-at-once".�� Don't be surprised if the team cleans the slate numerous
times, many new ways will be picked up and many old ways discarded.�� The team will
become autonomous, and will tend to transcend the initial goals, striving for excellence.��
The people on the team will become committed to accomplish the goal and some members
may experience emotional pain when the project is completed.
�
Why does Scrum Work?
The basic premise is that if you are committed to the team and the project, and if your boss
really trusts you, then you can spend time being productive instead of justifying your
work.�� This reduces the need for meetings, reporting and authorization.�� There is
control, but it is subtle and mostly indirect.�� It is exercised by selecting the right people,
creating an open work environment, encouraging feedback, establishing an evaluation and
reward program based on group performance, managing the tendency to go off in different
directions early on, and tolerating mistakes.�� Every person on the team starts with an
understanding of the problem, associates it with a range of solutions experienced and
studied, then using skill, intelligence, and experience, will narrow the range to one or a few
options.

Keep in mind that it can be difficult to give up the control that it takes to support the Scrum
methodology.�� The approach is risky, there is no guarantee that the team will not run up
against real limits, which could kill the project.�� The disappointment of the failure could
adversely affect the team members because of the high levels of personal commitment
involved.�� Each person on the team is required to understand all of the problem and all of
the steps in developing a system to solve it, this may limit the size of the system developed
using the methodology.

Observation:

Frequent, First-hand Observations

Scrum provides direct visibility into the progress of the project.

� Management can attend and observe the daily Scrum meetings. During these meetings
they can observe team spirit, each member's participation, team member interaction, work
that is being completed, and impediments to progress.

Management can attend and participate in Post-Sprint Meetings and Sprint Planning
Meetings, where - based on progress to date and team capabilities - work is planned.

Scrum provides daily status on team progress, and iterative (every 30 days) reviews of
product progress. Everything is visible - what's to be worked on, how work is progressing,
and what has been built - supporting management decisions regarding cost, time, quality,
and functionality. Plus, management is apprised daily what it can do to help the
development teams - what decisions are needed, and what's getting in the way.

Burn-down Charts:

Work Burn-Down

Management is concerned about :

• Sprint progress - how is the team doing toward meeting their Sprint goal?
• Release progress - will the release be on time with the quality and functionality
desired?
• Product progress - how is the product filling out compared to what's needed?

� To answer these questions, you can assess Product Backlog, Release Backlog (product
backlog that has been identified as required for the next release of the product), and Sprint
Backlog contents and trends.

Each backlog item contains the amount of work remaining. These values are updated
continuously. Plot this backlog across time. Even though you might think that backlog should
always go down, new work is always being discovered as the product is being built. Expect
the backlog to go up and down.

Plot the slope of the backlog. If you draw a line representing average slope over a period of
time, you can project it to determine when no work is likely to be left (mission accomplished,
Sprint goal reached, or release ready for finalizing). Team velocity=actual work
completed/days to complete.

Manage empirically so that Sprint backlog and Release backlog reach zero when needed. You
do this primarily by adjusting Sprint and Release contents or by modifying the Release date.

This type of management produces "the best possible software". The team is doing what
they can and you are helping them as much as you can.

Every team has different signatures. Backlog trends and velocity represent these team
signatures. You'll learn these signatures and be able to help teams adjust accordingly. For
instance, some teams always have Sprint backlog that keeps going up during the first tpart
of the Sprint, and then descends dramatically. Assess the measurements and determine
whether this is because of inadequate Sprint planning, overwork during the last ten days
(usually causes poor quality), or infrequent reporting of work remaining.

Each team member is responsible for estimating the number of hours remaining to complete
all assigned tasks during a Sprint. As work is completed, new estimates (hours-effort
remaining) are made until all work is completed.� These estimates are then summarized for
all tasks and converted to a burn-down chart which can be used to determine overall
progress being made during the Sprint.

The Product Manager is responsible for maintaining Product Backlog, along with estimates
for how much work is required for a backlog item. As Sprints build product, the Product
Manager re-estimates (sometimes the feature is only partially implemented) or zero's
(feature completed) backlog items.

Work remaining reporting during a Sprint focuses on updates to the estimated number of
hours� to complete a task. This should not be confused with time reporting. At the
beginning of the Sprint, each team member estimates the number of hours it will take to
complete each of the tasks that they have been assigned for the Sprint period.� As the
work is completed, a new estimate to complete is made for each task.� This process
continues on a periodic basis until all tasks are finished during the Sprint.

Active Management:

Active, Intelligent Management

Scrum Requires Active, Intelligent Management

Management is actively involved with Scrum on a daily basis. At the daily Scrum status
meeting, management listens closely to what each team member reports as being worked
on. This is compared to what management expects should be happening. For example, if
someone has been working on a trivial task for three days, it is likely that that team member
needs help. Management also listens for the velocity of the team : are they stuck, are they
floundering, are they making progress? Management can step in and problem-solve if help is
needed.
Management is also responsible for keeping the team working at the highest possible level
of productivity. When decisions are needed in the daily Scrum, make them then even if you
have incomplete information. It's usually better to proceed with partial information. If
enough information isn't available, create a backlog item to make the decision.

When impediments are reported during the daily Scrum - and the team cannot resolve the
impediment themselves - the Scrum Master is responsible for either solving it himself or
causing it to be solved as soon as possible by personally escalating it to executive
management of the organization. When the Scrum Master escalates an impediment, he
makes visible to the organization a policy, procedure, structure, facility, etc. that is hurting
rather than helping the organization perform its primary goal - to produce product.

Management is often surprised at some of the impediments. They were unaware that
seemingly well-thought through initiatives, standards, structures, policies, etc. are getting in
the way. The political turmoil that escalating impediments can cause shouldn't be
underestimated. However, this lets the organization make the choice of what is the most
important thing for them to do.
About XP:
XP @ Scrum

Scrum has been employed successfully as a management wrapper for Extreme

Programming engineering practices. Scrum provides the agile management mechanisms;
Extreme Programming provides the integrated engineering practices. An article written by
Ken Schwaber and Kane Mar on one implementation is at the Prentice Hall InformIT web site.

Benefits of xP@Scrum include:

1. The agile management and control mechanisms of Scrum are applicable for any type
of project, including business initiatives that consist of multiple, simultaneous
software development, business development, re-engineering, marketing, support,
and implementation projects. xp@Scrum projects fit within the overall management
framework of these initiatives.
2. xP@Scrum projects realize the full benefits of self-organization; teams are iteration
(or Sprint) goal directed, rather than story directed.
3. When Extreme Programming projects are wrapped by Scrum, they becomes scalable
and can be run simultaneously by non-colocated teams.
4. Scrum implements in a day; Extreme Programming can be gradually implemented
within the Scrum framework.
5. xp@Scrum projects benefit from ADM's business value metrics process for measuring
and managing initiative ROI.