An Agile Implementation of SeRUM
Michele GannonJohn Hopkins University Applied Physics Laboratory 11101 Johns Hopkins Road
Laurel, MD 20723 443-778-5345
Micbele.Gannon@jhuapl.edu Abstract-Is Agile a way to cut corners? To some, the use of an
Agile Software Development Methodology has a negative connotation - "Oh, you're just not producing any documentation". So can a team with no experience in Agile successfully implement and use SCRUM?
This paper explores the fundamentals of SCRUM as well as how this
Agile
development methodology has been implemented on aproject
at the Johns HopkinsUniversity
Applied Physics Laboratory. It will review the deviations made from the traditional SCRUM framework, the management of the project using standard SCRUM artifacts such as the Product Backlog, Sprint Planning, Daily Serum meetings, Sprint Reviews, Sprint Retrospectives, metrics and documentation as well as integrating the use of a Kanban board and pair programming methods from ExtremeProgramming (XP).
In addition to explaining the "what's" and "how's" of the project implementation, it will e
x
amine the many challenges and successes encountered.TABLE OF CONTENTS
1. INTRODUCTION
•••••••••••••••••••••••••••••••••••••••••••••••••1
2. THE SCRUM PROCESS
••••••••••••••••••••••••••••••••••••1
3. IMPLEMENTATION
••••••••••••••••••••••••••••••••••••••••••••2
4. CHALLENGES
••••••••••••••••••••••••••••••••••••••••••••••••••••5
5. RESULTS
...6
6. SUMMARY .
... .. .... ... ... ... ... ... ... ....
.. .. .. ...7
REFERENCES
•••••••••••••••••••••••••••••••••••••••••••••• •••••••••••7
BIOGRAPHY
••••••• •••••••••••••••••••••••••••••••••••••••••••••••••••7
1. INTRODUCTION
It is inevitable that
there will
be change on
any software project, so why not planfor it?
seRUM
is an iter
ativ
esoftware
development methodology that utilizes an "inspectand adapt" framework.
There is astandard
setof roles and artifacts
as wellas
an officialSeRUM
Guide.But
as weall
know, no two software development projects everseem to be the
same.
So
why not be agile in the implementation of anagile software
development methodology?With the
gui
danceof
aproject
manager
dedicated to thesuccess
of the project
as wellas
the use
of an agilemethodology
and a team having never usedSeRUM
before, isit possible
to succeed? Yes!978-1-4673-1813-61131$31.00 «J2013 IEEE
2. THE SCRUM PROCESS
seRUM is a framework for
develo
pi
ng and sustallllllg complex products and consistsof
thefollowing
artifacts, roles,and
events. [1] SeRUMTeams deliver
productsiteratively
and incrementally,maximizing
opportunities for feedback. [1]Wri.i"G inOW'T'Wtnt of the .oftw ...
Figure 1 -The
SeRUM
Process[2]
SCRUM Artifacts
SeRUM
has two artifacts: a Product Backlogand a S
pr
int
Backlog. The ProductBacklog is
a prioritized list of requirementsfor
asystem.
Thelist
cani
nclu
de functionaland
non-functional customer requirements as wen as technical requirements. TheSprint
Backlogis the set
ofitems
from
the ProductBacklog that
the team has committed tocomplete during
a single iterationor
Sprint.seRUM Roles
seRUM
has three roles: Product Owner, Team Member, and SeRUM Master. The Product Owneris
asingle person
who representsthe
interestof
thestakeholders. It is the
sole
responsibility of the
Product
Owner to prioritize the Product Backlog. Theteam members
includea
crossfunctional
group
of peopleresponsible
for delivering an end to end product at the end of each iteration or Sprint.The
SeRUM Master coaches the teamin following
the
SeRUM
process. SCR UM EventsSprint Planning
Meeting-The goal of sprin
t plal1l1ing is to identify thegoal
of the Sprint, what willbe done
in the Sprint, and howthat work will
get done. [1]
The Pr
oduct
Backlog is
reviewedto
determine which itemswill be
addressed in
thisSprint.
The goalof the
Sprint identifies why the Sprint is being conducted. The Spring Backlog is thencreated
based on the items pulledfrom
the Product Backlog to be com
pl
eted in this Sprint. The Sprint Backloghas
tasks
broken down into unit
s ofone day
or less and the team self-organizes todetermine
how these tasks will get done. [1]Daily Scrum-A
time-boxed
DailyScrum
(orstand
upmeeti
ng) is conducted
orh
eldevery
day in which each member of
the team answers three questions:•
What
did youaccomplish yesterday?
• What will you commit to complete today?
• Do you
have
any impediments?Any identified impediments
are
resolved
immediatelywithin the team
or
escalated by the SCRUM master for resolution as soonas
possible.Sprint Review-At the end of each sprint there
is
aSprint
Review
meeting where the teamhas
achance to
presentto
the stakeholders what was done in the Sprint. During this meeting the attendees collaborate on what was
done and
what to do next. [1] Feedback is collectedand
theproduct
backlog
isupdated
to include itemsto be
completed infuture Sprints.
Sprint Retrospective-The Sprint Retrospective is held after the Sprint Review and prior to the
next S
print PlanningSession.
This is the opportunity forthe SCRUM
Team toidentify
things that wen
t well and not so well during the Sprint. The meeting results in one or more identifiedimprovements that can
then be incorporated into
the future Sprints. This encourages and ensurescontinuous
improvement throughout the process.3. IMPLEMENTATION
Following the above SCRUM rules
the
team set out to develop co
mple
xsoftware.
Software Pwpose
The purpose
of the software
this team was developing wasto
remotely monitor
and control equipment thatb
uil
ds a connection from a mannedworkstation
to a satellite to aremote
site which housesvarious
components. There is a COTS product which provides the core functionality.Team Composition
The team consisted
of
1 Product Owner,6 software
developers, 5 networ
k
engineers, 4 testers, 2 IA representatives, I Project Manager, and 1 SCRUM Master. Teammembers
ranged in allocation to theproject
of 50%
-100%.
Because there were team memberswith
less than100%
allocation, Sprin
ts were scheduledto
last greaterthan
30 days. In add
ition one teammember
was not co-locatedwith
the rest of the team.DailyScrum
Daily Serums were held
every day at 9am
in the team lab. Initially theDaily
Serums includedjust
the software engineers.These
meeting
s typically resultedin illlanswered
qu
es
tio
ns which
would requirefo
ll
owup
with the other teams. It became beneficial to have each of the other teams
represented at the Daily Serum.Because
of the largerteam
size,
the Daily Serums were time-boxed to30
minu
te
s versus 15 minutes.Originally
the team made one pass aroundthe
table to answer the 3 questions in the Daily Serum. There were typically additional, beneficial discussions held at the Serum. This would result in a longer meeting or team membersf
ollowingthe
discussionbeing rushed
through their 3 questions. After several sprints the team realized it was necessary to have two passes; one for the3
qu
est
ions
and asecond for
anyfurther
discussion or questions. This actually resu
lted in the meetings being shorter.Product Backlog
The Product Backlog was written with the Product Owner and other
stakeholders
inthe form
of userstories. A user
story is a
description
of afeature
of the soft
ware written fromthe
perspectiveof
an enduser.
[3] The format foruser
stories is "As a
[name
of end
user or role] I want[simple
description offunctionality]
so that Ihave
[business
value]." The user stories reflect the requirements for the software. Each user story is assigned Story Points by the development team. Story Points are simply a numberu
sed
to expressthe
complexity of a user story. Story Points areu
se
d during Sprint Planning to assist in determining thenumber
of user stories that can be completedin
a Spr
int, as well as for capturing metrics on theSCRUM
Teams velocity.The
Product Backlog for
this
project started with 53 user stories and 2200 story points.Sprint Planning
After completing the Product
Backlog
or immediately following the Spr
int Retrospective fora Sprint, planning
for the next Sprint was started. SprintPlanning
typically lasted betweensix
and eight hours, broken up over two to four meetings.Spring
Pl
anning started with
a set of userstories
thathad a
si
milar theme
andthat
when grouped together could result in ad
emo-able product. Each selected
user story was reviewed to identify the list of detailed tasks to complete the story. Eachof the tasks
was written on asticky note,
whic
h would ultimatelybe
added to theKanban board
asa
"To Do"task. After
all tasks for the Sprint had beendefined a
second
pass acrossall
of the tasks was made. Duringt
his pass hour estimates anda
prioritywere
assigned to each task.Estimating-Estimating
always seems to bea
di
ffi
cult process withany s
oftw
are
develop
ment methodology. This starts with the decomposition of tasksto
an appropriatelevel.
In the first Sprinttasks
were decomposed to a very low level
. As multiple tasks could be completed within apiece of code, mu
l
tiple ta
sks
were worked by a single team member in parallel. In Sprint 2 tasks were not decomposed to the same low level, which resulted in the need to decomposetasks
even further before theycould
bestarted.
In Sprints 3 and 4, decomposition of
tasks
became easier for the team as theyhad
seen the result of poor task decomposition. The goal of decomposition and estimation was to keep each task under20
hours, asa
task great than20
hours shoul
d be broken down further.SPRINT BURN DOWN CHART
f 400 350 300 250
;
200 ::c 150 100 50 3 4 5 6 7 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Days in SprintPrioritization
of
Tasks-To ensur
ethat
the most critical taskswere
addressed first,
the team began to prioritize tasks as part of sprint planning. Tasks were given apriority of
one to three. Priority 1 tasks were critical to
the
success ofthe
Sprint. A priority3 task could be
deferredfrom the
Sprintshould the amount
of work in the Sprint exceed the capacity ofthe team.
Assigning Tasks-The
process
of task assignment changed as the team became more experiencedin using
this methodology. Following Spring Planning for Sprint I alltasks
were assigned to a team member.
In subsequent sprints just an initial set oftasks
were assignedas tasks
wereoften
reassigned multiple times throughoutthe first
Sprint. Process Improvements-With the use of an inspect and adapt framework, as well as the Sprint Retrospective, there was always continuous improvements being made. Inaddition to other improvements noted, during Sprint
Planning for
S
print 2the
team identified certai
n tasks thatwould need
to happen with every user story, thus a baseset
of tasks for
each user story was created
. Examples of thesetasks
included
"create detailed use case,""create design
documentation,"
and "create
testcase".
Sprint Burndown Chart
The
SCRUM Mastercreated and
maintained the Sprint Backlog and aSprint Bumdown
Chart. The Sprint Backlog, as illustrated in Figur
e 2,includes
all tasks to be completedin
the Sprint as well asthe
totalhour
estimatesand hours
remaining oneach task.
With this information one can graph thecompleted
and remaining hoursin
the Sprint in a Bumdown Chart,as illustrated
in Figure 3. The Sprint Backlog and Bumdown Chart are reviewed and updated every day. The red line in the chart, incorporated as a process improvement, conveysthe
"ideal"bum line. This
allows the team to easily gauge whether they are behind or ahead of schedule.Kanban
The team used a Kanban chart, illustrated in Figure 4, to
track
the progress of each task throughout the Sprint. This provided a visualrepresentation
of where the team was at any point intime
and was displayed prominently in the lab. The team continually refined the use of theKanban Board
for
easeof
use and effectivenessfor
the team.�\I
'
.s
CIU8E
TDJ(q,1Lb
....-
TOIJl
AUI
A8M
HANM-'
&ET �M£.HJ£KY
IIOTf!l
-Figure
4 -Kanban Board Example
The
original categories of taskson
the Ka
nban Board included To Do, In Progress, and Complet
ed. Additional categories were added to better trackwhere tasks
were in their lifecycle, such as Awaiting CodeReview, Ready
for Test,& Tested.
Originally there was just one big In Progress sec
t
ion on the Kanban board. The team decided to split this area up so each team memberhad
their own section of the board. This way everyone could easily see thetask load
on each team member.Sprint Review
The
Sprint
Reviewmeeting
was scheduled at the be
ginning of each Sprint and was open to anyteam
membe
r or stakeholder. A dry run of the review demonstration wastypically sche
d
uled about a week prior to the Sprint Reviewmeeting.
The
demonstration of
the Sprint accomplishments was conductedby
the team members, eachpresenting the
features
orfunctions
they developed. Participantswere
encouraged toask
questions andmake
comments at any point during the meeting.Following
the
demonstration the completion of the user stories identified for theSprint were assessed. If
a user story was not fully complete a new user story was createdto
capture the remainingor
missing functionality and the Product Backlog was updated. A team member would capture all comments and discussion points
so it could ultimately be determinedif
additionaltasks,
defects or user stories were required.Sprint Retrospectives
The Sprint Retrospective was a one hour time-boxed meeting to discuss how the Sprint went, similar
to
the identification of lessons learned.During the Sprint Retrospective there is a period of
time
allotted for
everyone towrite
down things
that they felt went well or not so well during the Sprint. After the time was reached, there was a round robin discussion to go througheach
itemthat was
written down.At the end
of the meeting, after every itemwas
discussed, theteam would
collectively identify process
improvements
to be
implementedi
mmediately
at the startof t
he
next Sprint. TheS
pr
in
tRetrospectives
were highlyeffective
for this team.The team was
open, honest, and professional when identifying anddiscussing
the topics that came up atthe
meeting
.
Many process improvements were implemented throughout theproject. Examples
of theitems
captured during the SprintRetrospective include:
•
Th
eteam
was flexiblein the
assignment of tasksand
"rolled with
thepunches"
• The team established trust an
d
a feelingof
collectivesuccess
• Poor communication with network
and
test teams(res
u
lted in process
improvement)
• Need to streamline code reviews, as they were
cumbersome
(resulted in
processimprovement)
•
Some
Definition of Done tasks are beingoverlooked (resulted in process
improvement)
MetricsMetrics are necessary to assist with Sprint Planning
and to
ensure
the
result of the process is asuccessful
Sprint.The
two essential metrics for
this process
were Capacityand
Velocity.
Capacity-Capacity is the total number
of hours
availablefor work between
the start and endof
a Sprint. The
equation
used
to create a person's capacityfor this
implementation was:(Workdays
in sprint
-Plalmed
out ofoffice)
* Allocation tothe
project * .75This metric takes into account that
so
me
teammembers
are not allocated 100% to the project and scheduled time outof
the
office. Inaddition, it
assumesthat each
team member spend75% of their
allocated time on the project on thetasks
in
the Sprint
Backlog.This
allows timefor breaks,
t
ra
ining
, an unplanned out of office, or corporate meetingand events.
The total teamcapacity
wasthe
sum of each individual teammember's capacity.
Est
i
mates
Person A
Person B
Person C
Person D
Pers
on E
Person F
Remainin
T
o
ta
l
:
1344
118
39
23
69
89
110
645
1093
Figure 5
-Team Capacity Metric
Velocity-Velocity is
the
total effort a team is capable ofin
a sprint
based on historical
data. Velocityc
anbe m
easured
in user stories or story points. Velocity can only be
measured
after thereis historical
data and becomes a more reliable metric over time.Story Point$ Completed by Sprint
.�tir "�l
Figure 6 -Team Velocity Metric
Documentation
Most
documentation was created on a Just-in-Time basis andthere
were few formal templates. Checklists were created andused for
ensuringcompleted
tasks met the teams Definitionof
Done. The documentation repository included a folder structure under each Sprint for documentation to be captured. This includedcode
review documentation, Daily Serumminutes,
dem
o scripts, design documents, use cases, andchecklists.
A user guide,s
ty
le guide, and installation procedureswere
updatedwith
each Sprint.4. CHALLENGES
Challenges
w
ill
occur on any software development project. Thebenefit of
using an Agile Development Methodology isthat with
the continuous inspecting and ad
ap
ting
, processimprovements
canbe made as
needed and are planned for within each Sprint.Team
Only
oneof
the six team members was al
lo
cat
ed 100%
to theproject.
Theother
team memberswere
allocated 50%,60%, or 70% to the project. Each team member managed their own time across their projects. At
the beginning of
theproject
it
wasdecided that a
teammembers' other
project
could not be stated as an
impediment. As
the team met every dayfor
the Daily Scrum it wasacceptable
tosay that
they had completed
only a
few hoursof
workor
thatthey
were unable
to
work on the projectfor
thatday. If
there werecritical
tasks tobe
completed that day, tasks were reassigned.There were times when team members stated that they were
working
more hours on the proj
ect than they were allocated. This wasaddressed
as apart
of SprintPlanning. The
entire team participatedin
Sprint Planning and made a collective commitmentto meet
the Sprint goal by the Sprint Review date. Through this commitmentand with
the assistance ofthe
Daily Serum meetings tea
mmembers
had to becomegood
with their own time management.Another
challenge for
the team was changes inteam
composition from Sprint to Sprint. This
is
not desirable, but projectassignments
would changefor
varyingreasons
andoccurred frequently
throughout thefIrst
fewSprints.
This made
identifying the team velocity metric diffIcult. This was addressedby ensuring the
total hoursfor
task
s assigned to a Sprint were less than the team capacity and by Spri
ntBacklog
task prioritization.Priority 3 tasks
wereidentifIed
as tasks
that couldbe
deferred to a future Sprint if needed. A third chal
lenge for the team was that one team memberwas not co-located with
the rest of the
team. He was involved in every meetingand
many discussions via the phone; however body language and emotion are not easilyconveyed
via aphone
conversation.The
seRUM Masterwould convey some
of
this information over the phone inmeetings and through follow up conversations,
but
this is not a challengeto easily
overcome.A fourth team challenge was
each team member's
amenability to
change. Somesoftware
developers are set intheir
ways andhave
diffIculty adaptingto the m
ult
ip
le
improvements being made. Each team member must
be
honest with the team
and
opento
frequent change. Also, as new tasks werecreated the team
members needed to accept that although these tasks are being identifIedthey
may not fall wi
thinthe
goalof
the current Sprint. These taskswould
be
fIled
under a new or existing user story and be reviewed and possibly implemented in a futureSprint.
Daily Scrum
Software developers are not typically fans
of
meetings. This wasevident in
someof the
earl
ier Daily Serum meetings, as the team waslearning
the process. After completing a Sprint andstarting
a second Sprint, the purpose and benefItsof
this meetingbecame
apparent to the team.In
additi
on, throughexperience the
team learned how to quickly address the3
questions, whatwarranted
additional discussion
duringthe SeRUM
and what topics shouldbe deferred to
a sma
lle
r discussion immediatelyfollowing the seRUM or a follow up meeting
la
ter in the day.Sprints
The
length
of theS
prints was a challenge. Withthe
teammembers being
al
located less than100%
tothe
project
Sprints
were
typically lon
gerthan 30 days
and their durations varied from Sprintto
Sprint. It is diffIcult to ensurethat
a Sprint is not too long or too short. Longer Sprints can result in diffIculty with motivation and stayingfocused;
as well as a larger set of tasks,which
could be potentially overwhelming.Shorter
Sprints resulted in moreattention
beingpaid
to scheduleand
tasks that had yet to be started.Tool Setup
and Configuration
Tasks
in the Product Backlog and ultimately tlle SprintBacklog
did noti
nclud
etool
set up and confIgurationor
product installation. In the initial Sprints this was a challenge, because automated builds and unit testing
was
d
esi
ra
ble.For
the second Sprint anew
user story wascreated
to address ReleaseEngineering.
This user storywas
broken down intotasks
that included product installations and configuration,as well as infrastructure tasks
and testharness
creation. Portionsof this
user
story were executed overseveral
Sprints, soas
not to impact the quality or diminish the numberof
enduser
requirementsin a
given Sprint."/n
Sprint"
TestingIt was a challenge to conduct testing
of
aSprint
wit
hin the Sprint. Adevelopment
environment was maintainedwhere
the softwaredevelopers created
and compiled code. Atest
environment was maintained
which
had the
content of the lastS
print.Testers
could not reliably testin
the development environmentdue
to the instability and continuous changingof the
environment. Thus, testingwas
always
a Sprint behind development.Procurement
Delays
As the
purpose of the software beingd
evelo
pedwas to
monitor
various pieces
of equipment, dela
ys in the procurement and receipt of the equipment presented a challengeto
the team. Because of this some user stories were broken in what the team called "verticalslices".
A vertical sli
ce was defmedas an
implementation of a featureacross
a singlepi
ec
e of equipmentor
asubset
of thetotal
pieces of equipmentto be
monitored.S.RESULTS
The ultimate success, of course, is a fInal working product that meets the end user requirements. Each
Sprint
however was a successin
that it resulted in functionalitythat
couldbe
demonstratedto the
stakeholders.There
werealso
successes in the implementationof
SCRUM.
Working
a s aTeam
Daily
meetings,
collaboration, team commitment, paired or team programming, honest discussion, and various otherteam
buildingactivities
resulted in a tightly knit teamenvironment. Through
this strong senseof
teamand
sharedcommitment the
agile processes seemed to happen automatically. Tasks could easily shift from one team
member toanother, unit and
integration testing became easier, bugs were identified and resolved by anyone and everyone, potential problems or pitfallswere discussed and
resolved collectively, code reviews were a positive experience, Sprint Planning and estimation improved throughout the duration of theproj ect
and
collaborativework
between development teamand
test team are just asmall
setof
th
e resultof
a strong agile SCR UM team.Sprint Planning
Sprint Planning
improved
throughout the duration of the project. Asthe
teambecame c
omfortable with the processand each
other, aswell as
their collective goal, SprintPlanning
discussions were more honest and thorough. This resu
lted in better estimates, properly decomposed tasks, and a realistic set of achievable user stories.Sprint Review
The execution of the Sprint Review meeting was
a
team success. Each member of the
team presented the por
ti
onof
the productthey
developed. This allowedfor everyone
on the team to participate and take pride in each incrementald
elivery.Sprint Retrospectives
There is
always room to improve. Effective communicationis
essential to a team ' s success. This, along with professionalism,self
evaluation, honesty, and openness allowed the teams Sprint Retrospective to be highly beneficial to the success of the team. The goal of each retrospective was to identify 3 process improvements. This was an easygoal for
the team. Process improvements were easily identified andimplemented.
And
if a process improvement did not meet the desired goal, it was amended as needed. Due to these retrospectives theteam
was able to inlprove quality, capability,and
productivity.Improved
Productivity
As any identified impediments are removed on a daily
basis,
the team is able
tofocus
theirefforts
onproductive tasks
resulting in incre
a
sed productivity.Improved Quality
With a documented Definition
of
Done on a task, user story, and sprint level, there is always a focus on what it meant to state that someth
ing was "Done" . This ensured that throughout the process standards were being followed,documentation was
being
updated, unit tests werebeing
created and
executed, and code reviews wereb
eing
conducted.
The
checklist was posted in the lab andthe
teamwould
ensurethat
all items were incorporated resulting in higher quality code as well assupporting materials.
6. SUMMARY
Is it
possible
tointroduce
and succeed using a new AgileSoftware
Development Methodology? Of courseit
is. Willthere be
challenges along the way? Of course there will. Will there bechanges
an
dimprovements
that mustbe
made along the way? Yes. Isit
better to understand this fromproject
in
ceptionand
plan for these things along
the way? Absolutely.Three key requirements
for
a successful implementation of anAgile
Development Methodology include:• A well
defined baseline set
ofrules
or a framework, such as SCRUM• Supportive management and
stakeholders
educatedin agile methods
• Team members that are open minded
and
amenable tochange.
The only constant in most software development is change. It is inevitable that there will
be
change on any software proj ect, so why not plan for it? Thereis
no "right" wayto
implement an Agile Development Methodology. Pay attention to what works and what does not work and make adjustments as needed - Inspect and Adapt.Be
Agile.REFERENCES
[ 1 ] The official Scrum
Guide:
www.scrum.orWScrumGuides.aspx
[2]
http://commons.
wikinled
i
a
.
org/wikilF ile: Scrum process.syg
[3] http://www.agilemodeling.comlartifacts/userStory.htm
BIOGRAPHY
Michele Gannon
received aB.S.
inComputer Science from Towson
State
University, in 1 99 7. She has worked
at the Johns Hopkins UniversityApplied
Physics lab for
two yearsand with Agile
Software Development Methodologies