What makes Agile Development so different?

1. The nuts and bolts
Agile of Agile practices,
terms and
Primer
metrics
www.rallydev.com
1
©
2009
Rally
So4ware
Development,
Inc.

2. What
is
All
the
Buzz
About?
• Agile
is
documented
to
help
large
projects
cut
@me-­‐to-­‐
market
by
50%
and
increase
produc@vity
by
25%
• It
shares
values
with
Lean
manufacturing
to
promote:
– disciplined
project
management
– frequent
inspect
and
adapt
cycles
that
minimize
waste
– self-­‐organizing,
cross-­‐func@onal
teams
that
make
and
meet
commitments
– engineering
prac@ces
that
rapidly
deliver
high-­‐quality
so4ware
It
is
common
to
combine
Scrum
project
management
prac@ces
with
Extreme
Programming
(XP)
engineering
prac@ces
www.rallydev.com
2
©
2009
Rally
So4ware
Development,
Inc.

3. What
Makes
Agile
Development
So
Different?
Agile
projects
build
so4ware
incrementally,
typically
using
short
itera@ons
of
1-­‐4
weeks,
to
keep
development
aligned
with
changing
business
needs
So,
instead
of
a
single
pass,
6-­‐18
month
release
that
predicts
all
requirements
and
risks
up
front
…
Agile
adapts
to
frequent
feedback
by
delivering
working,
tested
code
every
1-­‐4
week
itera@on
www.rallydev.com
3
©
2009
Rally
So4ware
Development,
Inc.

4. Agile
Rewards
Value
Delivery
over
Illusion
of
Control
Waterfall
Agile
Fixed Scope Resources Time
AdapDve
Rewarded
for
delivering
value
PredicDve
Rewarded
for
providing
illusion
of
control
Estimated Resources Time Scope
Early
scope
commitment
drives
cost
&
Scope
is
es@mated
and
allowed
to
evolve
to
schedule
es@mates.
But
needs
change
stay
aligned
with
needs.
Teams
commit
to
faster
than
so4ware
can
be
delivered.
always
work
on
highest
value
features
www.rallydev.com
4
©
2009
Rally
So4ware
Development,
Inc.

5. The
Structure
of
Each
Agile
Team
is
Similar
The
ScrumMaster
is
a
facilita@ve
team
leader
who
ensures
the
team
is
fully
produc@ve
so
they
can
make
and
meet
commitments.
Responsibili@es
include:
• Enable
close
coopera@on
across
all
roles
and
func@ons
• Remove
blocks
and
shield
the
team
from
disturbances
•
Work
with
management
to
track
progress
and
re-­‐factor
structures
&
processes
of
the
organiza@on
The
Product
Owner
drives
the
product
from
the
business
perspec@ve.
• Ensure
Agile s
inspect
and
adapt
Responsibili@es
include:
processes
are
followed,
including
• Define
the
requirements
and
priori@ze
their
value
Daily
Stand-­‐ups,
Planning
Mee@ngs,
• Determine
the
release
date
and
content;
• Lead
the
itera@on
and
release
planning
mee@ngs
Demo
Reviews
and
Retrospec@ves.
• Ensure
the
team
is
always
working
on
the
most
valuable
requirements
• Accept
or
reject
work
results
of
each
itera@on
www.rallydev.com
5
©
2009
Rally
So4ware
Development,
Inc.

6. Agile
Scales
by
ReplicaDng
Agile
Teams
Team-­‐of-­‐Teams
We
don t
increase
Program
Steering
Agile
team
size!
Portfolio Mgt &
Governance
Instead,
we
grow
our
disciplines
to
synchronize
many
distributed
teams.
Release Mgt
Mul@-­‐Team
Program
Architecture
Council
Agile
improves
collabora@on
across
all
roles
with
greater
transparency
into
work
in
progress,
quality,
readiness
and
costs.
www.rallydev.com
6
©
2009
Rally
So4ware
Development,
Inc.

7. A
Team
Works
in
IteraDons
to
Deliver
User
Stories
The
team
plans
stories
into
their
itera@on
based
on
each
story s
priority
and
size.
The
team
uses
their
velocity
(how
much
they
get
done
per
itera@on),
to
decide
how
much
scope
to
plan
into
the
itera@on.
www.rallydev.com
7
©
2009
Rally
So4ware
Development,
Inc.

8. User
Story
is
a
Requirement
from
the
User s
PerspecDve
During
release
planning,
user
stories
are
given
a
rough
size
esDmate
using
a
rela?ve
scale
like
points.
Later,
during
itera@on
planning,
we ll
break
the
story
down
into
tasks.
Agile
is
very
disciplined
about
producing
useful,
realis@c
es@mates.
Make
sure
you
As a buyer, I want to have check
out
the
"Es@ma@on"
my shipping information Slideshow
in
this
series
for
a
confirmed so I get a chance thorough
introduc@on.
to correct any errors
www.rallydev.com
8
©
2009
Rally
So4ware
Development,
Inc.

9. Stories
are
Implemented
by
Tasks
Real
work
is
more
granular
than
stories.
Each
story
is
really
a
collec@on
of
Tasks.
We
wait
to
break
stories
into
tasks
un@l
the
story
is
planned
for
the
current
itera@on.
Elabora@ng
details
just-­‐in-­‐?me
takes
advantage
of
learning
and
feedback.
Tasks
are
es@mated
in
hours,
typically
sized
between
2-­‐12
hours.
www.rallydev.com
9
©
2009
Rally
So4ware
Development,
Inc.

10. Stories
are
Validated
with
Acceptance
Tests
www.rallydev.com
10
©
2009
Rally
So4ware
Development,
Inc.

11. When
is
a
Story
Done?
Teams
determine
what
done
means.
Criteria
can
include:
–
all
tasks
completed
(dev,
test,
doc,
etc.)
–
all
acceptance
tests
running
and
passing
–
zero
open
defects
–
accepted
by
the
Product
Owner
–
could
be
delivered
to
users
www.rallydev.com
11
©
2009
Rally
So4ware
Development,
Inc.

12. Agile
Metrics
Make
Progress
Visible
www.rallydev.com
12
©
2009
Rally
So4ware
Development,
Inc.

13. Quick
Glossary
of
Some
Agile
Terms
User
Story:
A
simple
expression
of
a
requirement,
commonly
in
the
form
of:
As
a
<User
Role>
I
want
<Func@onality>
so
that
<Business
Value>
Task:
A
single
unit
of
work
that
helps
a
Story
reach
delivery/acceptance
EsDmaDng:
Gauging
the
rela?ve
size
of
a
User
Story
in
points,
and/or
the
number
of
hours
to
complete
a
task
Ranked
Backlog:
A
list
of
User
Stories
priori@zed
by
importance/
value
to
the
customer
Velocity:
The
rate
at
which
a
team
completes
work,
usually
measured
in
story
points.
Used
to
decide
how
many
stories
to
plan
into
the
release.
Release
Planning:
Es@mate
stories
in
points,
and
select
and
rank
them
in
order
to
sa@sfy
the
release
condi@ons
of
schedule,
scope
and
resources.
Agile
teams
respond
to
feedback
and
typically
adjust
scope
to
meet
the
release
theme
and
date.
IteraDon
Planning:
Select
stories
to
be
delivered
by
the
itera@on
deadline,
detail
their
acceptance
criteria
and
es@mate
their
tasks
in
hours.
Commitment:
En@re
team
commits
to
the
itera@on
stories
and
schedule
www.rallydev.com
13
©
2009
Rally
So4ware
Development,
Inc.

14. Next
Steps
• View
these
other
Agile
Planning
guides:
www.rallydev.com/learn_agile/agile_planning/
– Agile
Es@ma@ng
– Release
Planning
– Itera@on
Planning
www.rallydev.com
14
©
2009
Rally
So4ware
Development,
Inc.