Scrum is an iterative incremental process of software
development commonly used with agile software development. Despite
the fact that "Scrum" is not an acronym, some companies
implementing the process have been known to adhere to an all capital
letter expression of the word, i.e. SCRUM. This may be due to one
of Ken Schwaber's early papers capitalizing SCRUM in the title.[1]
Although Scrum was intended to be for management of software development
projects, it can be used in running software maintenance teams,
or as a program management approach.
Contents
History
In 1986, Hirotaka Takeuchi and Ikujiro Nonaka described a new holistic
approach which increases speed and flexibility in commercial new
product development:[2] They compare this new holistic approach,
in which the phases strongly overlap and the whole process is performed
by one cross-functional team across the different phases, to rugby,
where the whole team "tries to go to the distance as a unit,
passing the ball back and forth". The case studies come from
the automotive, photo machine, computer and printer industries.
In 1991, DeGrace and Stahl, in Wicked Problems, Righteous Solutions[3]
referred to this approach as Scrum, a rugby term mentioned in the
article by Takeuchi and Nonaka. In the early 1990s, Ken Schwaber
used an approach that led to Scrum at his company, Advanced Development
Methods. At the same time, Jeff Sutherland developed a similar approach
at Easel Corporation and was the first to call it Scrum.[4] In 1995
Sutherland and Schwaber jointly presented a paper describing Scrum
at OOPSLA '95 in Austin, its first public appearance. Schwaber and
Sutherland collaborated during the following years to merge the
above writings, their experiences, and industry best practices into
what is now known as Scrum. In 2001 Schwaber teamed up with Mike
Beedle to write up the method in the book "Agile Software Development
with SCRUM".
Characteristics of Scrum
Scrum is a process skeleton that includes a set of practices and
predefined roles. The main roles in Scrum are the ScrumMaster who
maintains the processes and works similar to a project manager,
the Product Owner who represents the stakeholders, and the Team
which includes the developers.
During each sprint, a 15-30 day period (length decided by the team),
the team creates an increment of potentially shippable (usable)
software. The set of features that go into each sprint come from
the product backlog, which is a prioritized set of high level requirements
of work to be done. Which backlog items go into the sprint is determined
during the sprint planning meeting. During this meeting the Product
Owner informs the team of the items in the product backlog that
he wants completed. The team then determines how much of this they
can commit to complete during the next sprint.[1] During the sprint,
no one is able to change the sprint backlog, which means that the
requirements are frozen for a sprint.
There are several implementations of systems for managing the Scrum
process which range from yellow stickers and white-boards to software
packages. One of Scrum's biggest advantages is that it is very easy
to learn and requires little effort to start using.
Scrum
roles
Several roles are defined in Scrum; these are divided into two
groups; pigs and chickens, based on a joke about a pig and a chicken.[1]
A pig and a chicken are walking down a road. The chicken
looks at the pig and says, "Hey, why don't we open a restaurant?"
The pig looks back at the chicken and says, "Good idea, what
do you want to call it?" The chicken thinks about it and says,
"Why don't we call it 'Ham and Eggs'?" "I don't think
so," says the pig, "I'd be committed but you'd only be
involved."
So the pigs are committed to building software regularly
and frequently, while everyone else is a chicken: interested
in the project but really irrelevant because if it fails they're
not a pig, that is they weren't the ones that committed to
doing it. The needs, desires, ideas and influences of the chicken
roles are taken into account, but not in any way letting it affect
or distort or get in the way of the actual Scrum project.
"Pig"
roles
Pigs are the ones committed to the project and the Scrum
process; they are the ones with "their bacon on the line."
- Product Owner
- The Product Owner represents the voice of the customer.
They ensure that the Scrum Team works with the right things from
a business perspective. The Product Owner writes User Stories,
prioritizes them, then places them in the Product Backlog.
- ScrumMaster (or Facilitator)
- Scrum is facilitated by a ScrumMaster, whose primary
job is to remove impediments to the ability of the team to deliver
the sprint goal. The ScrumMaster is not the leader of the
team (as they are self-organizing) but acts as a buffer between
the team and any distracting influences. The ScrumMaster ensures
that the Scrum process is used as intended. The ScrumMaster is
the enforcer of rules.
- Team
- The team has the responsibility to deliver the product. A small
team of 5-9 people with cross-functional skills to do the actual
work (designer, developer etc.).
"Chicken"
roles
Chicken roles are not part of the actual Scrum process, but must
be taken into account. An important aspect of an Agile approach
is the practice of involving users, business and stakeholders into
part of the process. It is important for these people to be engaged
and provide feedback into the outputs for review and planning of
each sprint.
- Users
- The software is being built for someone! If software is not
used - much like 'the tree falling in a forest' riddle - was
it ever written?
- Stakeholders (Customers, Vendors)
- The people that will enable the project and for whom the project
will produce the agreed upon benefit(s) which justify it. They
are only directly involved in the process at sprint reviews.
- Managers
- People that will set up the environment for the product development
organizations.
The
Scrum meeting
Each day during the sprint, a project status meeting occurs. This
is called a scrum or "the daily standup". The scrum
has specific guidelines:
- The meeting starts precisely on time. Often there are team-decided
punishments for tardiness (e.g. money, push-ups, hanging a rubber
chicken around your neck)
- All are welcome, but only "pigs" may speak
- The meeting is timeboxed at 15 minutes regardless of the team's
size.
- All attendees should stand (it helps to keep meeting short)
- The meeting should happen at the same location and same time
every day
During the meeting, each team member answers three questions:[1]
- What have you done since yesterday?
- What are you planning to do by today?
- Do you have any problems preventing you from accomplishing your
goal? (It is the role of the ScrumMaster to remember these impediments.)
At the end of a sprint cycle (every 15-30 days) a sprint retrospective
is held, at which all team members reflect about the past sprint.
The purpose of the retrospective is to make continuous process improvement.
This meeting is timeboxed at four hours. Two main questions are
asked in the sprint retrospective:[1]
- What went well during the sprint?
- What could be improved in the next sprint?
Scrum enables the creation of self-organizing teams by encouraging
co-location of all team members, and verbal communication across
all team members and disciplines that are involved in the project.
A key principle of Scrum is its recognition that during a project
the customers can change their minds about what they want and need
(often called requirements churn), and that unpredicted challenges
cannot be easily addressed in a traditional predictive or planned
manner. As such, Scrum adopts an empirical approach – accepting
that the problem cannot be fully understood or defined, focusing
instead on maximizing the team's ability to deliver quickly and
respond to emerging requirements.
Documents
Product
backlog
The product backlog is a high-level document for the entire
project. It contains broad descriptions of all required features,
wish-list items, etc. It is the "What" that will be built.
It is open and editable by anyone. It contains rough estimates,
usually in days. This estimate helps the Product Owner to gauge
the timeline and, to a limited extent, priority (e.g. if "add
spellcheck" feature is estimated at 3 days vs 3 months, that
may affect the Product Owner's desire).
Sprint
backlog
The sprint backlog is a greatly detailed document containing
information about how the team is going to implement the
requirements for the upcoming sprint. Tasks are broken down into
hours with no task being more than 16 hours. If a task is
greater than 16 hours, it should be broken down further. Tasks on
the sprint backlog are never assigned, rather tasks are signed-up
for by the team members as they like.
Burn
down
The burn down chart is a publicly displayed chart showing the number
of tasks remaining for the current sprint or the number of items
on the sprint backlog. It should not be confused with an earned
value chart. A burn down chart could be flat for most of the period
covered by a sprint and yet the project could still be on schedule.
Adaptive project management
Following are some general practices of Scrum:
- Customers become a part of the development team. (i.e. the customer
must be genuinely interested in the output.)
- Like all other forms of agile software processes, Scrum has
frequent intermediate deliveries with working functionality. This
enables the customer to get working software earlier and enables
the project to change its requirements according to changing needs.
- Frequent risk and mitigation plans developed by the development
team itself. – Risk Mitigation, Monitoring and Management (risk
analysis) at every stage and with commitment.
- Transparency in planning and module development – Let everyone
know who is accountable for what and by when.
- Frequent stakeholder meetings to monitor progress – Balanced
(Delivery, Customer, Employee, Process) Dashboard updates – Stakeholders'
update – You have to have Advance Warning Mechanism, i.e. visibility
to potential slippage / deviation ahead of time.
- No problems are swept under the carpet. No one is penalized
for recognizing or describing any unforeseen problem.
- Workplaces and working hours must be energized. – "Working
more hours" does not necessarily mean "producing more
output."
Scrum
terminology
The following terminology is used in Scrum[1]:
Roles
- Product Owner
- The person responsible for maintaining the Product Backlog by
representing the interests of the stakeholders.
- ScrumMaster
- The person responsible for the Scrum process, making sure it
is used correctly and maximizes it benefits.
- Team
- A cross-functional group of people responsible for managing
itself to develop the product.
- Scrum Team
- Product Owner, ScrumMaster and Team
Artifacts
- Sprint Burn Down Chart
- Daily progress for a Sprint over the sprint's length.
- Product Backlog
- A prioritized list of high level requirements.
- Sprint Backlog
- A list of tasks to be completed during the sprint.
Others
- Sprint
- A time period (typically between 2 weeks and 1 month) in which
development occurs on a set of backlog items that the Team has
committed to.
- Sashimi
- A slice of the whole equivalent in content to all other slices
of the whole. For the Daily Scrum, the slice of sashimi is a report
that something is done.
Extended usage of Scrum
Though Scrum was originally applied to software development only,
it can also be successfully used in other industries. Now Scrum
is often viewed as an iterative, incremental process for developing
any product or managing any work.
Scrum applied to product development
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). Today there are records of Scrum
used to produce financial products, Internet products, and medical
products by ADM.
Scrum as a marketing project management
methodology
As marketing is often executed in project-based manner, a lot of
generic project management principles apply to marketing. Marketing
can be also optimized similar to project management techniques.
Scrum approach to marketing is believed to be helpful for overcoming
problems experienced by marketing executives. Short and regular
meetings are important for small marketing teams, as every member
of a team has to know what the others are working on and what direction
the whole team is moving in. Scrum in marketing makes it possible
to:
- See possible problems at early stages and allows coping with
them quicker and with minimal losses. According to the key principle
of Scrum “no problems are swept under the carpet”, every team
member is encouraged to describe the difficulties he is experiencing,
as this might influence the work of the whole group.
- Reduce financial risk. With the beginning of every sprint period,
the business owner can change any of the marketing project parameters
without penalty, including increasing investments to enlarge consumers’
quantity, reducing investments until unknowns are mitigated, or
financing other initiatives.
- Make marketing planning flexible. Short-term marketing plans
based on sprints can be much more effective. Marketing managers
get an opportunity to switch from one promotion method to another,
if the first one proved to be unsuccessful during the sprint period.
It also becomes easier to clarify due dates of every small, but
important, task to each member of a team.
- Involve clients in various ways.
There’s also a tendency to execute Scrum in marketing with the
help of Enterprise 2.0 technologies and Project management 2.0 tools.
See
also
- Other Agile methods
- Supporting tools
References
External
links
|