Scrum Project Management Techniques


Scrum Project Management Techniques










PDF
version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files.
The reader is available for free
download.

Scrum Project Management Techniques

by Geoff Keston

Copyright 2018, Faulkner Information
Services. All Rights Reserved.

Docid: 00011498

Publication Date: 1811

Report Type: TUTORIAL

Preview

Software developers have been reconsidering their
methodologies for the past several years, especially in response to the
demands of creating applications for both the Web and for mobile
platforms. The advent of apps prompted many developers to seek more
flexible approaches that better accommodate business goals and
frequently changing conditions. The Scrum methodology defines project
management techniques that facilitate flexible – that is, “agile” –
development.

Report Contents:

Executive Summary

[return to top of this report]

Scrum is a methodology for creating software applications
based on the agile development philosophy.

Agile
Software Development Tutorial
Web
Design Programs and Tools Tutorial
DevOps Tutorial

Agile development encourages the use of flexible, lightweight
management and coding techniques. Projects are not rigidly defined
up-front, but instead are refined and take shape in later stages of the
process, with changes being partly based on input from customers and
other stakeholders.

The Scrum methodology provides two main points at which
flexibility can be exercised:

  • Daily Meetings – The
    development team holds daily meetings that are intended to give each
    developer the chance to change what he or she plans to work on for that
    day based on the latest update about other aspects of the project.
  • Project Phases, known as “Sprints”
    – Scrum advises breaking down projects into small phases. The end of
    each phase – or “Sprint,” in Scrum jargon – provides the opportunity
    for the developers and for other stakeholders, most notably the
    customer, to modify or redirect the project.

In addition to Scrum, there are other methodologies based on
agile principles, including context driven testing, Crystal, the
Dynamic Systems Development Method, Extreme Programming, Feature-Driven
Development, Kanban, IBM’s Rational Unified Process, and the Scaled
Agile Framework (SAFe). These methodologies offer somewhat different
advice on issues such as the length of project stages and the size of a
development team. SAFe has, in particular, emerged as an important
alternative because it is designed for large projects whereas most
agile methods are best suited for use by smaller teams. When
considering Scrum, developers will need to first ask whether agile
development is the right choice for the types of applications they
create, and then, if so, determine whether Scrum is the right agile
methodology.

Description

[return to top
of this
report]

Software developers have long been interested in finding more
flexible ways to create applications. By some accounts, this interest
dates back to the 1980s. But it was only in 2001, when the nonprofit
Agile Alliance formed, that interest shot up. In that year, the Agile
Alliance released the Agile Manifesto, which champions an alternative
to traditional methods of software development. This alternative favors
“lightweight” methods that encourage flexibility and grant developers
more independence to work in their own ways.

The most popular methodology for putting this agile
development philosophy into practice is Scrum. Among developers who use
agile methods, 56 percent use Scrum as their primary method and
14 percent use a hybrid of Scrum and XP (Extreme Programming), while no
other method is used as the main approach by more than 10 percent of
developers.1

Table 1 compares Scrum against traditional development methods
according to
several key characteristics.

 

Table 1. Traditional Software Development vs. Scrum
Category Traditional
(Heavyweight) Methods		 Scrum’s Methods
Project Phases
and Timetables		 Milestones are set at the beginning
of the project, and they are often based on meeting formalistic
requirements (such as creating documentation) rather than on developing
working software.

Timetables are rigid.

 Projects are divided into short
timeframes built around incremental steps, iterations that are called
“Sprints” in Scrum terminology. At the end of an iteration, the team
tests the software. As needed, budgets, product specifications, and
other key parameters are changed based on the results of testing.

Key Term

Product Backlog – The
product backlog lists the requirements of the software that have yet to
be developed, by order of priority. The priorities, and even the
requirements themselves, typically change during the
development process. The product’s requirements are not fully defined
at the beginning of the project but are fleshed out later; therefore,
the initial product backlog may be relatively small.
Change Management Making changes often requires
several bureaucratic steps, including getting approvals from multiple
stakeholders. The process does not provide natural opportunities to
make changes, and any requested changes may trigger penalties that are
defined in a contract with a customer. 		Budgets, requirements, and other
parameters change throughout the process. This approach is designed to
reduce risk and enables projects to be responsive to changing markets
and business environments.

Key Term

Sprint Backlog – The
Sprint backlog defines the tasks to be completed in a given Sprint,
based on requirements defined in the product backlog. These individual
tasks are organized into increments that are small enough to be
completed in fewer than 16 hours.
Customer
Involvement		 Customers provide extensive input
before development begins, but they are typically kept at a distance
during development and do not get a chance to see the software
demonstrated until near the end of the project.		 Customers and other stakeholders are
involved at the end of each Sprint, and their feedback can lead to
changes in the project’s design plan, timetables, and budgets.

Key Term

Sprint Review – At the
end of a Sprint, the development team and other stakeholders, including
customers, meet to review the project’s status. The team demonstrates
the working software that has been created thus far. (Features that
have not been added are excluded from the review.) Based on the results
of the review, the stakeholders can change the requirements, as
reflected in the product backlog, or change other parameters, such as
which developers will participate in the next Sprint.
Team Composition Teams may be large and may be
segmented into silos.

Members of a team often have narrowly defined roles in
which they exercise little independence and in which they have little
knowledge of the overall project and its business goals.

 Scrum calls for teams of five to
nine people. Teams “self-organize” rather than answering to detailed
orders from superiors. 

Most participants on a project are simply called “team
members,” and they are not given narrowly defined positions. Instead,
they are expected to take on tasks according to decisions made during
Sprint planning. In a few situations, the developers on a Scrum team
may be assigned particular roles, but these roles are typically
flexible.

Key Terms

There are, however, two titles that the Scrum
methodology specifically defines:

  • Scrum Master – In
    addition to overseeing the technical side of the development project,
    the Scrum Master is also expected to manage aspects such as staff
    motivation and personal interactions among team members.
  • Product Owner – The
    Product Owner speaks for the customer, who may be an external party or
    an internal party for whom the software is being created. This role is
    sometimes called the “Project Owner.”
 Communication In many cases, team members
communicate infrequently. In particular, communication across silos may
be very limited.		 Team members meet daily, typically
for 15 minutes, to update the group on their progress and activities.
These meetings enable developers to adjust their activities and
techniques to aspects of the project being worked on by other members
of the team.

Key
Terms

Daily Meeting – The daily
meeting is sometimes referred to by names such as “The Daily Scrum,”
the “Stand-Up Meeting,” “The Daily Stand-Up,” or the “Morning Role
Call.”2

Outlook

[return to top of this report]

Alternative agile development methodologies include the
following:

  • Context Driven Testing
  • Crystal
  • Dynamic Systems Development Method (DSDM)
  • Extreme Programming
  • Feature-Driven Development (FDD)
  • IBM’s Rational Unified Process
  • Kanban

Scrum has a more mature body of instructional
literature than do many alternatives, it has a reputation for being
simple,3 and there are several certifications
for it. (DSDM also has a certification.) The basic roles of Scrum are
covered by the Certified ScrumMaster and Certified Product Owner
courses. More advanced topics are covered by the Certified Scrum
Developer and Certified Scrum Professional programs. And for people who
would like to teach about Scrum, there are the Certified Scrum Trainer
and Certified Scrum Coach designations. The development of formal
certifications for Scrum represents a major step toward maturity: It
encourages greater use by enabling developers to earn professional
credentials for studying and employing the methodology.

One area in which Scrum is not as mature (but
still more mature than most other agile methods) is in mobile
development. But it has potential in this domain. An analysis by mobile
app development company Clearbridge noted the following: “Using agile
scrum methodology, we’ve found that apps are delivered more quickly and
efficiently due to the better and more frequent communication between
teams.”4 Another mobile app development
company, Thinslices, makes a similar case for Scrum: “Given that mobile
apps and the web ecosystem change rapidly, this strategy helps us save
valuable resources, by integrating specifications for future features
into each working sprint.”5

An
additional area in which Scrum has had shortcomings is in scaling to
larger projects. Traditionally, agile methodologies have been designed
for smaller teams, but the increasing use of cloud applications has
created the need to accommodate much more expansive development work.
As a result, the Scaled Agile Framework (SAFe) has become increasingly
popular. It is now the most popular scaling method for agile
development, being used significantly more often than the second place
method, Scrum of Scrums.6

While in some cases, developers may choose
alternatives to Scrum, in other cases, they will address its
shortcomings by using it with other approaches. In particular, it is
likely to be used with DevOps, a philosophy that fosters collaboration
between developers and IT operations.7 And Scrum
can be used in conjunction with some other agile frameworks, like
Kanban. “Kanban and scrum aren’t mutually exclusive,” says Nate
Berent-Spillson, who works on software development at Nexient.8
“In fact, they complement each other quite nicely, and when used for
devops tasks, they allow your fast development cycles to go even
faster.”

Recommendations

[return to top
of this report]

Is Agile Development the Right Choice?

Before considering Scrum, a development team should assess
agile development itself. The various versions of agile development
(e.g., Scrum, context driven testing, DSDM) are largely similar. The
differences between them, although not trivial, relate to only a few
details. So organizations must first evaluate the core characteristics
of agile development to determine whether the philosophy itself will
suit their needs. A general guiding principal is that agile methods are
favored when

  • requirements are not fully and concretely formed at the
    beginning of a project,
  • a new type of project brings inherent uncertainty,
  • changes are anticipated throughout the development process,
    or
  • some new features may need to be rolled back quickly.9

A team that adopts agile methods will need to be effective in dealing
directly with a variety of parties, and organizations will need to
adjust their training programs and hiring practices to consider these
communication skills. Developers on a Scrum team are expected to
understand the project’s business objectives and to know about every
aspect of the software. The purpose of having this knowledge is to
enable all team members to work independently toward project goals
rather than simply completing tasks assigned by a supervisor. The
developers need this knowledge because they are given the authority to
employ their own techniques to meet the project’s aims.

Software developers who are accustomed to rigid methods will
be pressured to adapt their work habits to accommodate the independence
and flexibility that agile methods provide. And those developers who
have typically worked in isolation will be compelled to adapt to a
tight-knit team environment in which they interact with
developers, managers, executives, and customers alike. In some cases,
organizations may need to provide additional training to developers in
order to facilitate this transition.

Is Scrum the Right Choice for Agile Development?

If a development team decides to use agile development –
whether adopting it as the team’s core philosophy or taking the more
prudent approach of first testing its use on a single project – the
team will benefit from choosing a particular version of agile
development. Following a formal, documented version of agile
development will give the team specific, concrete guidance. The basic
structure these versions provide will generally help development
efforts, and the structure will not undermine the independent and
flexible work practices that agile development promotes.

Scrum has some inherent features that make it more (or less)
suitable for a particular situation. For instance, Scrum does not
dictate engineering practices, which makes it highly adaptable. But the
key variable will be the development team’s ability to successfully
follow the methodology. Therefore, if an organization has members with
experience in Scrum, or if Scrum has been demonstrated to be effective
on a project similar to the one being undertaken, it might be
preferable to alternatives.

References

1 “12th Annual State of Agile Report.” CollabNet and VersionOne.
2018.

2 Jason Yip. “It’s Not Just Standing
Up: Patterns of Daily Stand-Up Meetings.” ThoughtWorks.
August 29, 2011.

3 Jim Bird. “Why Scrum Won.” Building
Real Software. November 2012.

4 Dan Kosir. “A Mobile App
Using Agile Scrums?” Clearbridge.

5 Ilie Ghiciuc. “Tips from
Ioana – How to Do Agile Project Management with Scrum.”
Thinslices.
August 28, 2015.

6 “12th Annual State of Agile Report.” CollabNet and VersionOne.
2018.

7 For example, see:

Joshua Partogi. “Scrum and
DevOps.” Scrum.org.
March 31, 2018.

8 Nate Berent-Spillson. “A Different Drumbeat: Using Kanban for Devops to Smooth
Out Your Scrum Cycles.” InfoWorld.
March 27, 2018.

9 This list is based in part on the
following sources:

“Agile
Development – Advantages, Disadvantages and When to Use It?” 360logica. February
19, 2018.

“Agile Methodology:
Advantages, Disadvantages and When to Use It?” Lvivity. March 6,
2018

[return to top
of this report]

About the Author

[return to top of this report]

Geoff Keston is the author of
more than 250 articles that help organizations find opportunities in
business trends and technology. He also works directly with clients to
develop communications strategies that improve processes and customer
relationships. Mr. Keston has worked as a project manager for a major
technology consulting and services company and is a Microsoft Certified
Systems Engineer and a Certified Novell Administrator.

[return to top of this report]