Why should you use Scrum?

Over 3Z% o! traditional pro|ects !ail to meet time and budget. Agile is an alternative approach to so!tware
delivery. ln Z010, Forrester Hesearch recognized that agile is now mainstream
1
and Scrum is the leading
universal agile !ramework.
Z 3 4
Scrum is...
Smpl, a manager-!riendly agile
development !ramework
Sclbl, working !or small start-ups and
large distributed enterprises
Wspr, used by over 60% o!
companies that implement agile
Z

Prvn to improve quality and
productivity by 33% or more
3
!"
$!"
%!"
&!"
'!"
(!!"
())* ())& ())' $!!! $!!$ $!!% $!!)
+,-./0 12,../34/0 5677//0/0
Trtnl lT prjct succss rts,
Stnsh Chs Rprts, JBBB-2OOB
4
www.agile4Z.comJ6whys
1
Agile So!tware Development is Now lainstream", Jan ZZ, Z010, ClO lagazine
Z
Agile by the numbers: Survey !nds more adoption, but age-old problems remain", Oct Z7, Z009, SearchSo!twareQuality
3
Fercentage !ewer !ailures in agile vs. traditional pro|ects, Z010 l1 Fro|ect Success Hates Survey Hesults, Ambyso!t
4
Success rates !or l1 pro|ects taken !rom the Standish Chaos report (1996-Z009)
What is Scrum?
Agile Scrum teams !ocus on results not enort. Scrum is a principle-based !ramework !or continuous
learning that !ocuses on maximizing value delivery instead o! enort.
1he Scrum !ramework
Hequirements are taken !rom a prioritized
Froduct Hacklog and broken down into small
!eatures that can be delivered as
working so!tware during short
development iterations, called
Sprints.
Work is pulled !rom the Froduct
Hacklog into a Sprint Hacklog
!or completion in the sprint by
the Development 1eam. 1he outcome
o! a Sprint is a Deliverable that, ideally, can
be released immediately a!ter acceptance by the
Froduct Owner at the Sprint Heview meeting.
Why Scrum works
Sel!-organizing teams in Scrum emerge because o!
core values:
Full bandwidth
cmmunctn
Work cmmtmnt by
selection
Delivering wrkng
sftwr
Actions guided by
the bg pctur
www.agile4Z.comJ6whys
What is Agile?
1
Agile drives continuous improvement by repeatedly inspecting and adapting the working process.

1he Agile approach
Wrks Emprcll: Agile is an empirical,
principle-based approach !or delivering
so!tware in a complex technical and business
environment
Rucs Cmplxt: 1oday's business and
technical environment changes rapidly;
complexity is growing exponentially
Hnls Chng: Developers solve
increasingly dimcult problems in a technology
environment that is undergoing rapid change
De!ned, process-driven systems, like water!all,
are ill-equipped to manage the dependencies and
uncertainty created by complexity and change.
Th vlum f
c n vr
pructs s
ncrsng
xpnntll
J
www.agile4Z.comJ6whys
1
Why Dinosaurs Will Keep Hunning the Auto lndustry", Harvard Husiness Heview, June Z010
!
#
$
%
&
'!
#!!( #!!) #!'!
!"# %&' ()*+', "- ./('0 "- 1"2'
3*/../"(045 6 7,"89 -", 1"*7.'8/%95 /(
:",2 ;'&/1.'0 &60 1&6(<'2
!
#
$!
$#
%!
&'()*+ ,-,
./(012)*(/
34(/0+( %!$!
5'/6
704)+08'*
9:;<(1= %!!> 9?
@20;; A(/B(6(;
!"#$%&'(") "+ ,-. /".')0
1&.%#2').&3 % 4"&53 %)5 % 6"#$").),
"+ ,-. 7.&6.5.( 89!2%((
:#'22'") 2').( "+ 6"5.;
How agile are you?
Do you use business value to prioritize
requirements?
Do you have cross-!unctional Development
1eams?
Do they deliver working so!tware regularly?
Do you review the process at the end o!
each iteration?
Are !eatures small enough to be completed
in a short iteration?
What is Lean?
Lean thinking is a principle-based approach with empirical inspect-and-adapt iterations instead o! de!ned
process steps. Since Z001 agile has been used to describe so!tware development approaches based on
the lean principles applied so enectively by 1oyota.
1
Agl s ln ppl t sftwr vlpmnt,
Lean thinking
mu - Wst: re!ers to any non-value adding
activity that a customer is unwilling to pay !or.
Lean companies passionately eliminate waste
- mur - Prcss Ovrl: re!ers to the
tendency to overload processes in the hope o!
achieving more. Lean thinking maximizes value
creation over process utilization
mur - Unvn Flw: inconsistent !ow can
disrupt a system, creating inemciencies and
waste. Lean decreases lead time by smoothing
!ow through a system
www.agile4Z.comJ6whys
1
1oyota used lean thinking in their manu!acturing process to become the world's largest car manu!acturer
Why are there |ust 3 roles?
1he Scrum !ramework relies on three peer-level management roles, whose mutually exclusive
responsibilities lead to positively-rein!orcing behaviors that stabilize the process. Combining responsibilities
eventually leads to contradictory drivers or con!icts o! interest. 1he three distinct roles allow people to
!ocus on de!ned responsibilities with dinerent ob|ectives driving behavior.
1he Froduct Owner (FO) maximizes the return-
on-investment (HOl) o! the product, measured
!rom idea conception to delivery to the paying
customer
1he Scrum laster continually improves the
development process, coaching the Scrum team
to become more productive, improve quality
and sel!-organize
1he Development 1eam manage the technical
quality o! the product by nurturing practices
that rein!orce shared code ownership
www.agile4Z.comJ6whys
HOl
Frocess
Quality
1he Busnss Vlu Gm
1
is used to estimate
relative value o! high-level requirements:
Frepare SlAH1
Z
requirements with support o!
stakeholders to !ocus discussion
Convene a Froduct Hoard with all product
stakeholders
Estimate the relative value o! each requirement
by discussing and ranking them together
Write user stories !or requirements at the top o!
the backlog to deliver value as early as possible
1he Froduct Owner - A value-driven role
1Z
1he FO maximizes HOl by managing value delivered with !xed iteration lengths by a stable team.
Value is managed by:
Pruct Vsn: Combining a company's
strategic goals with its customers' needs to
create a product vision
Prrtz Vlu: Creating high level
requirements and prioritizing business needs
by value with the help o! the stakeholders
Grm Bcklg: Writing user stories
to manage production risk
Rls Plnnng:
Fredicting value earned per
sprint and managing the
product backlog to maximize
delivered value
www.agile4Z.comJ6whys
1
agile4Z's Husiness Value game !or estimating relative value is described in !ull online
Z
SlAH1 ob|ectives are Speci!c, leasurable, Achievable, Helevant and 1estable
Facilitating ceremonies
Fcus n vlu: 1imebox meetings, prioritize
discussion, coach participants to communicate
enectively
Oversee the process
Unrstn Vlu: What is being delivered?
lake both delivered value and waste visible
Unrstn lnvuls: Expose inter-team
issues and help the 1eam to resolve the issues?
Unrstn Prcss: Visualize the process
and !ocus on removing single largest bottleneck
1he Scrum laster - Leading without authority
1he Scrum laster has no authority in the Scrum
team. lnunc s rn.
He or she is a srvnt lr, !acilitating the
ceremonies and overseeing the Scrum process.
lt is a cchng rl, analyzing progress to
!ocus on incremental improvement over time and
guiding the 1eams to learn !rom
experience through enective
retrospection.
Stand behind
the team,
not in !ront

www.agile4Z.comJ6whys
Striving !or technical excellence
Share a common De!nition o! Done !or maintainability
Use a De!nition o! Heady to prepare items in the backlog
Encourage collective code ownership
Huild automated tests and integrate continuously
lake quality o! your code transparent to the whole 1eam
Development 1eam - Writing working so!tware
Agile Development 1eams measure progress through the delivery o! working so!tware.
1
Enective agile
Development 1eams share three characteristics:
1hey are crss-functnl - all the skills required to build a complete production-ready product area
represented in one 1eam
1hey are smll - !rom studies o! team behavior, the optimum size !or enective collaboration is 6-9
people; not too large so that communication becomes an issue, not so small that overhead is excessive
1hey use an ntgrt vlpmnt nvrnmnt to create working, production-ready so!tware
within a Sprint, allowing merging and check-ins with automated tests on a regular basis
www.agile4Z.comJ6whys
1
Agile lani!esto, Frinciple #7: Working so!tware is the primary measure o! progress
Owner Ceremony Furpose
Froduct Owner Sprint Flanning Use value to prioritize next sprint by:
Fresenting |ust enough user stories !or the next sprint (or Z)
Guiding the 1eam on the purpose o! the next sprints
Estimating and selecting user stories !or the sprint backlog
Scrum laster Daily Scrum lnspect & adapt progress towards sprint goal by:
linimizing number o! open user stories
Delivering done user stories be!ore taking next story
laintaining balance between quality and value delivery
Development
1eam
Sprint Heview &
Hetrospective
lnspect & adapt product and process by:
Heviewing user stories by viewing working so!tware
Continually reviewing product against vision and sprint goals
lmproving process incrementally by small prioritized steps
Why are there 3 ceremonies in Scrum?
1o help 1eams deliver working so!tware at the end o! a Sprint, there are three regular, time-boxed
ceremonies, each with a single purpose and owner.
www.agile4Z.comJ6whys
Sprint Flanning
Estimation & selection
1he FO describes the sprint goal to give
context surrounding the stories
Each story is discussed with the 1eam, who
estimate relative enort
1he 1eam select stories they will deliver within
a sprint
1ask break down
Each story is broken down into the required
technical tasks by the 1eam
www.agile4Z.comJ6whys
Limit risk o! !ailure
ln order to enectively plan releases and meet
customer needs in terms o! delivery schedule and
!eature sets, the FO needs to be able to predict the
productivity o! the 1eam over time.
1hese practices that help the FO to manage risk:
Sizing stories so 6-10 stories !t into a sprint
Fulling, not pushing, stories !rom the backlog
Keeping a steady cadence or rhythm to sprint
length
Only accepting working, tested so!tware
Working with a visible and shared De!nition o!
Done, what it means to complete a user story
De!ning non-!unctional requirements implicit to
customer acceptance o! the product
Daily Scrum
1he 1eam in!orm one another about what is working and what is not, and agree on how to
address issues that threaten to slow progress against the sprint goal.
A Daily Scrum uses 16 minutes in
which each team member
answers three simple questions:
1.What did you do yesterday?
Z.What will you do today?
3.What is stopping you !rom
delivering (more)?
1he Daily Scrum is not a status
report !or a FO or stakeholder,
but is a !orum !or the 1eam to
work more closely together.
Active participation is limited to the
1eam, with the Scrum laster !acilitating;
others may observe and contribute only i!
asked to by the 1eam.
1he Daily Scrum highlights things to watch !or,
and keeps the 1eam accountable to the sprint
goal.
www.agile4Z.comJ6whys
1he Daily Scrum
ls short, time-boxed at 16 minutes
ls held around the task board to keep !ocus
Lets the 1eam inspect & adapt the plan !or
the sprint
Exposes issues that may need the 1eam to
swarm around and solve
Sprint Heview & Hetrospective
1he last principle o! the agile mani!esto says at regular intervals, the 1eam re!ect on how to become
more enective, then tune and ad|ust their behavior accordingly." 1he Sprint Heview is the 'inspect' part o!
the inspect & adapt process, in which the 1eam look at running so!tware; the Hetrospective is the 'adapt'
part o! the process, in which the 1eam make small changes to incrementally improve the product and the
process.
Froduct improvement
As well as a product demonstration, the 1eam
inspect & adapt the product as a whole,
adapting practices and the product backlog as a
result.
Hased on current results, progress can be
assessed and !urther investment planned.
Frocess improvement
A!ter a Sprint Heview, the Scrum team
inspect & adapt the process through a
retrospective, allowing an agile team to
incrementally improve the development
process.
www.agile4Z.comJ6whys
Hunning a Hetrospective
A Hetrospective can be a challenging discussion.
1o keep !ocussed and enective:
Gather individual !eedback on post-its in short
time boxes
Halance positive and negative !eedback !rom
everyone
Separate idea generation !rom evaluation
Frioritize ideas and select a !ew o! the best
actions
Why are there |ust 3 arti!acts?
1he Scrum !ramework has developed over time, and through the incremental improvement central to all
agile methods, waste has been stripped away.
1he result?
Just 3 core arti!acts or tools necessary to govern
Scrum:
Pruct Bcklg, with items prioritized by
value; owned by the FO
Sprnt Bcklg, sub-set o! product backlog
protected !rom change; owned by the 1eam
Burnwn Chrt, visualization o! work to be
completed; owned by the Scrum laster
www.agile4Z.comJ6whys
De!nition o! Heady
Used to determine when a user story or work
item is ready to present to the 1eam, !or
example:
Stories !ollow the lNVES1 mnemonic
1
Small enough that one 1eam can select 6-10
stories in a sprint
At least 3-4 Acceptance Criteria
1he FO's Froduct Hacklog
1
1he product backlog contains items, or business
requirements, prioritized by relative business
value.
1he backlog consists o! the Wh (requirement)
and the Wht (user stories). 1he Hw, the
technical tasks, is
determined by the
Development
1eam.
Flexibility is
maintained by
using a |ust-in-
time approach to
breaking down
the requirements.
Hequirements near
the top o! the backlog are broken down into
multiple user stories, with the goal o! having
enough prepared user stories !or |ust the next 1-Z
sprints.
www.agile4Z.comJ6whys
1
User stories that are lndependent, Negotiable, Valuable, Estimable, Small, 1estable
1he 1eam's Sprint Hacklog
1
1he Sprint Hacklog contains stories that will not change during the sprint, allowing the 1eam to !ocus on
delivering the selected stories. Outside the Sprint Hacklog, the FO can re-prioritize stories i! needed.
A good Sprint Hacklog contains:
6-10 stories the 1eam selected !or the sprint
Just enough small tasks !or the next !ew days
(to limit risk o! waste)
1he Scrum board
Visualizes the current activity in the 1eam
Helps 1eam limit open and incomplete stories
Highlights dependencies between tasks
Shows time committed to tasks outside the
sprint goal
Keeps !ocus, with ideally one activity or story
open at a time
Tls lk Agl
J
hlp mng gl tms nln,
l fr strbut tms
www.agile4Z.comJ6whys
1
Agilo is an open-source agile management tool, ideal !or distributed teams
1he Scrum laster's Hurndown Chart
1
1he Hurndown Chart shows work that still needs to be done, allowing the Scrum- laster to manage the
Scrum !ramework.
1he units used !or the Hurndown chart provide dinerent in!ormation and levels o! granularity:
Completed User Stories, burning down User Story points, may show no change !or days at a time
Completed tasks, burning down ideal hours, should change daily, but can also burn up i! additional tasks
are uncovered and added to the backlog
Tls lk Agl
J
cn utmt chrt crtn
Heading the Hurndown Chart
Visualizes work to be completed (y-axis)
New tasksJstories move line up
1rend line shows ideal taskJstory burndown
Used by Scrum laster to !ocus Daily Scrum
Sudden gradient drop hints at possible
technical debt
www.agile4Z.comJ6whys
1
Agilo is an open-source agile management tool, ideal !or distributed teams
Agile development principles
Elmnt wst: Automate any repetitive
task, like acceptance testing or product build
- Rgulr, rp fbck: make small
changes and testJintegrateJbuild immediately
lntgrt rl: dimculty o! integrating new
code grows exponentially with size o! change
C wnrshp: the 1eam develop code.
Work together, agree common standards
Emrg sgn: avoid over-engineering -
only design and build what is required today
Why do agile engineering practices help?
1he Scrum !ramework is a simple !ramework with
9 prescriptions: 3 roles, 3 ceremonies and 3
arti!acts. 1hese prescriptions help streamline the
product de!nition and value creation, with a
!ocus on the work de!nition and management
practices; there are no technical practices.
Experience shows that enective Scrum teams
need so!tware engineering practices aligned
with these management practices; short
iterations delivering working so!tware are not
possible using traditional, big up-!ront design
!ollowed by long develop and test cycles.
Other agile methodologies have !ocussed more on
the technical practices, and many success!ul
Scrum teams adopt agile development practices
like those described as part o! the XF
1
!ramework.
www.agile4Z.comJ6whys
1
eXtreme Frogramming describes development practices such as pair programming, re!actoring and continuous integration
Huilding code ownership
Signs that a 1eam is building a culture o! shared
code ownership include:
Knowledge sharing tasks on the task board not
directly related to delivering a new !eature
Design and architecture decisions made with
non-architects or designers in the 1eam
Common use o! pair programming to share
knowledge
Shared, visible and continually updating
De!nition o! Done !or user stories
Selection o! user stories outside area o!
expertise o! a 1eam (and success!ul delivery)
Encouraging code ownership
Code ownership is the principle by which the 1eam take responsibility !or the technical quality o! the
product. lt means that the whole 1eam share responsibility !or the code across the whole system.
Shared code ownership builds in redundancy,
increases general knowledge o! the system
without sacri!cing specialist expertise, increases
quality and reduces time wasted chasing bugs.
Code ownership means:
A common understanding o! coding standards
and expectations
Open communication between developers
Huilding and sharing knowledge
Fractices that support rebuilding and emerging
design
www.agile4Z.comJ6whys
lncrease quality by regular, rapid !eedback
1he cost o! debugging increases exponentially with the length o! time a!ter a bug is introduced; the
earlier a bug is !ound, the cheaper and easier it is to solve. An underlying principle o! agile development
is to get !eedback quickly and o!ten to uncover de!ects early. lany agile development practices !ocus
on decreasing the time taken to get !eedback. 1his helps eliminate waste and build quality in.
Agile practices !ocus on regular, rapid !eedback.
Tst-rvn vlpmnt builds a test
!ramework be!ore the code is written
Pr prgrmmng provides !eedback as the
code is written
Automated !unction or ccptnc tstng
!eeds back as the !eatures grow
Cntnuus ntgrtn ensures !unctioning
builds and tests integration
Hegular, rapid !eedback increases code
quality by:
Encouraging small, incremental code
changes
Discouraging the 'works on my machine'
mentality
laking merging easier
Visualizing code quality and shared coding
standards
Focusing 1eam on writing working so!tware
Validating that the product is shippable
www.agile4Z.comJ6whys
He!actoring legacy applications
You don't need 90% coverage to re!actor:
Huild tests as you code
Fre!erably write tests be!ore you code
Write code that does only what you need it to
When you use legacy code, only test legacy
!unctionality exposed !or the new !eature
Start with speci!c cases, and re!actor to add
generalization or modularity
Continually improve the design
De!ning architecture up!ront seems to be a good
idea. 1he architect must think through the design,
and can design !or !uture growth.
Hut this misunderstands the purpose o!
architecture; it is a service to those that develop
the product, maximizing the 1eam's ability to
develop while meeting the business needs !or the
product in terms o! non-!unctional requirements
like per!ormance under load or number o!
concurrent users.
Hetter to only design !or what is right in
!ront o! you. Frovide a service to the
Development 1eam that makes
development smooth, quick and emcient.
When this is not enough, extend or
modi!y the architecture.
1his serves two purposes. Obviously, it
reduces waste. Only the architecture that
is needed is built. Hut it also creates a continually
improving environment in which the architecture
can be modi!ed and optimized to its current
purpose, rather than stretched and squeezed to
meet unplanned needs.
www.agile4Z.comJ6whys