University
of
Washington

Agile
Developer
Cer6ficate

                 Spring
Quarter

Advanced
Topics
in
Agile
So>ware
Dev...
Going
Beyond
1
Team
Doing
Scrum


SCALING
SCRUM

How
Agile
Methodologies
Scale

Many Teams,     Many Teams,
many backlogs   one backlog




                               ...
Product
Defini6on
Team

•  Product
Owner
may
be
part
of
the
Product

   Management
func6on

•  May
receive
input
from
mul6p...
Scaling
the
Product
Owner


   Chief
Product

   Owner

Flow
of
Mul6ple
Sprints
Leads
to


        Product
Release

The
Agile
Release
Train

                                                                Release
1
                       ...
Affinity
Es6ma6ng

                                                                         Is
this
a


                    ...
Mul6ple
teams

 •  Synchronize
within
teams

 •  Synchronize
across
teams
           Daily Scrums
                        ...
Three
Levels
of
Synchroniza6on

           Coordinating Scrum
                Or MetaScrum



Scrum of
 Scrums




       ...
The
ABC’s
of
Scrum

                                Type A              Type B                Type C


Documents          ...
How
Do
We
Set
a
Context
for

  Empowered
Leadership?

Integra6on
Scrum
Team
Model

Single
Backlog
Model

Exercise:
Your
Team
Organiza6on

•  How
are
your
teams
organized
currently?

•  Which
model
would
work
becer
for
your

   ...
Scaling
Recommenda6ons

•  Correlate
team
organiza6on
to
subsystems
or
modules
with

   minimal
cross‐over

•  Implement
d...
Dispersed
Team
Recommenda6ons

•  Co‐locate
the
team
as
o>en
as
possible,
especially
at
incep6on
and

   key
milestones

•...
Notes
on
the
Meta‐Scrum

•    Unlike
the
Scrum
of
Scrums
(where
teams
synchronize
and
coordinate
with
the
purpose
of

    ...
Going
Beyond
the
Sprint
to
Strategic
Product
Planning


THE
5
LEVELS
OF
PLANNING

Planning
at
Mul6ple
Levels

    •     Product
Visioning

    •     Product
Roadmap

    •     Release
Plan

    •     Spri...
Planning
at
Mul6ple
Levels





                              21
Crea6ng
Memorable
Visions

•  Elevator
Statement:
              •  Product
Box:

   –  FOR
(target
customer)

   –  WHO
(s...
The
Extended
Scrum
Framework

                                       Daily
Scrum

Vision                                 o...
Product
Roadmap

•  The
Product
Owner:

   –  Communicates
the
whole

   –  Determines
when
releases
are
needed

   –  Det...
Product
Roadmap
–
an
example

      April
8,
‘06
                   June
3,
‘06
                    July
8,
‘06
          ...
Release
as
a
series
of
Sprints

    •  A
release
comprises

       mul6ple
itera6ons

    •  Each
itera6on
can
be

       ...
An
Agile
Approach
to
Planning

Release

       Condi6ons
of
                                                           Fee...
An
Agile
Release
Plan

                     PrioriXzed
Product
Backlog

       Sprint
n+1





                          A...
Velocity

                                                       Velocity

 40

                                          ...
Deriving
Dura6on
Using
Velocity

              PrioriXzed
Product
Backlog

Itera6on
1





                   As
a
frequen...
Sezng
up
for
Release
Planning

•  What
is
the
purpose
you
hope
to
accomplish
with
Agile
release

   planning?


•  Do
you
...
Release
Planning
Session

•  Conduct
a
Release
Planning
Mee6ng
collabora6vely
with
the
whole

   team
(product
owner,
deli...
Release
Burn‐up





                   33
Informa6on
Radiators:
Big=Beau6ful!

       A
Sample
Task
Board





             © 2007 SolutionsIQ - v15   34
Another
sample
task
board





                             35
Project
repor6ng

•    Minimize
repor6ng

•    What
gets
measured
gets
done

•    Make
it
visible

•    Possible
metrics:
...
End
Of
Sprint
Data

Starting/Ending Metrics
Not
Just
Following
a
Process


SCRUM
SPIRIT

Scrum
Essen6als

•  Elaborate
features
just‐in‐6me
for
the
Sprint,
not
while

   in
the
Product
Backlog

•  Product
Owner
...
What
Can
Cause

                       
Scrum
Adop6on
to
Fail?

•    Ineffec6ve
use
of
the
retrospec6ve

•    Inability
to
...
Cultural
Change:
The
Hard
Part

Old Organization                 New Organization
Centralized                      Distrib...
Glossary
of
Terms

Glossary
of
Terms

•    Daily
Scrum
Mee6ng

      –    A
fi>een‐minute
daily
mee6ng
for
each
team
member
to
answer
three
qu...
Glossary
of
Terms

•    Product
Backlog
Item
Effort

      –  Some
Scrum
prac66oners
es6mate
the
effort
of
product
backlog
i...
Glossary
of
Terms

•    ScrumMaster
Role

      –    The
ScrumMaster
is
a
facilitator
for
the
team
and
product
owner.
Rath...
Glossary
of
Terms

•    Sprint
Goals

      –    Sprint
goals
are
the
result
of
a
nego6a6on
between
the
product
owner
and
...
Glossary
of
Terms

•    Sprint
Task

      –  In
Scrum,
a
sprint
task
(or
task)
is
a
unit
of
work
generally
between
four
a...
Ar6cles

•    “AgileEVM
–
Earned
Value
Management
The
Agile
Way,”
Tamara
Sulaiman,
Agile
Journal,

Jan.
8,

     2007.

  ...
Online
Presenta6ons

•    “Agile
Es6ma6on”
by
Mike
Cohn

     hcp://video.google.com/videoplay?docid=9061050925476245469&q...
Other
Useful
Links

•    Agile
&
Scrum
Training:
hcp://www.solu6onsiq.com/scrum/training_events.html

•    Agile
Alliance
...
Upcoming SlideShare
Loading in …5
×

Class5 Scaling And Strategic Planning

1,291 views

Published on

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,291
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
59
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Class5 Scaling And Strategic Planning

  1. 1. University
of
Washington
 Agile
Developer
Cer6ficate
 Spring
Quarter
 Advanced
Topics
in
Agile
So>ware
Development
 Class
#5:
Scaling
Scrum
and
Strategic
Planning

  2. 2. Going
Beyond
1
Team
Doing
Scrum
 SCALING
SCRUM

  3. 3. How
Agile
Methodologies
Scale
 Many Teams, Many Teams, many backlogs one backlog 3
  4. 4. Product
Defini6on
Team
 •  Product
Owner
may
be
part
of
the
Product
 Management
func6on
 •  May
receive
input
from
mul6ple

 –  Product
Managers
 –  Business
Unit
owners
 –  Analysts
 –  Architects
 –  Informa6on
Architects
 –  Others
 •  How
does
the
effec6ve
Product
Owner
manage
 all
these
inputs?

  5. 5. Scaling
the
Product
Owner
 Chief
Product
 Owner

  6. 6. Flow
of
Mul6ple
Sprints
Leads
to

 Product
Release

  7. 7. The
Agile
Release
Train
 Release
1
 Release
2
 Theme
1
 Theme
2
 • 

Feature
1
 • 

Feature
3
 • 

Feature
2a
 • 

Feature
2b
 Release
 Roadmap
 Components
 A
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 B
 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 C
 21
 22
 23
 24
 26
 27
 29
 30
 32
 32
 2
weeks
 ~
4‐6
weeks
 ~
12‐16
weeks

  8. 8. Affinity
Es6ma6ng
 Is
this
a

 3
or
a
5?
 Ini6al
Compara6ve
 Story
 What
about
 these
 Is
this
an

 epics?
 8
or
a
 Is
this
a

 13?
 5
or
an
 8?
 •  Break
up
into
small
teams
of
2‐4
 •  Discuss
2‐3
stories
so
there
is
a
sense
of
them
 •  Find
an
ini6al
compara6ve
story
 –  If
team
is
already
Sprin6ng,
find
a
small‐ish
one
already
completed
that
was
a
really
 good
es6mate;
use
that
es6mate
 –  Find
a
fully
understandable
story
and
fully
task
it
out;
call
it
either
a
2
or
a
3
 •  Without
conversa6on,
the
en6re
team
puts
all
the
stories
on
a
big
wall
 –  smallest
at
the
right
and
largest
on
the
le>
compared
to
ini6al
story
 –  Anyone
can
move
anyone
else’s
story
posi6on
 •  As
ac6vity
subsides,
put
a
scaled
number
line
up


 •  Secle
on
es6mates
for
boundary
stories
and
epics

  9. 9. Mul6ple
teams
 •  Synchronize
within
teams
 •  Synchronize
across
teams
 Daily Scrums per Team Scrum Team 1 9:00AM
 9:30AM 9:30AM
 Scrum Team 2 10:00AM 10:30AM
 11:00AM Scrum Team 3 Scrum of Scrums 9
  10. 10. Three
Levels
of
Synchroniza6on
 Coordinating Scrum Or MetaScrum Scrum of Scrums Daily Scrums Reproduced with permission from Mike Cohn,
 Mountain Goat Software, 2003 10
  11. 11. The
ABC’s
of
Scrum
 Type A Type B Type C Documents Product Backlog Release Roadmap Resource Plan Sprint Backlog Product Backlog Release Roadmap Burndown Chart Sprint Backlog Product Backlog Burndown Chart Sprint Backlog Burndown Chart Ceremonies Sprint Planning Multi-level Planning MetaScrum Daily Meeting Daily Meeting Multi-level Planning Sprint Review Scrum of Scrums Scrum of Scrums Sprint Review Daily Meeting Sprint Review Roles Product Owner Chief Product Owner Chief Product Scrum Master Product Owners Owner Team Uber Scrum Master Product Owners Scrum Masters Uber Scrum Master Teams Scrum Masters Teams Source:
Jeff
Sutherland
 11
  12. 12. How
Do
We
Set
a
Context
for
 Empowered
Leadership?

  13. 13. Integra6on
Scrum
Team
Model

  14. 14. Single
Backlog
Model

  15. 15. Exercise:
Your
Team
Organiza6on
 •  How
are
your
teams
organized
currently?
 •  Which
model
would
work
becer
for
your
 organiza6on
and
why?
 •  How
would
you
need
to
reorganize
teams
in
 order
to
accommodate
the
new
model?
 •  What
obstacles
are
keeping
you
from
going
 towards
the
new
model?
 •  Debrief
with
the
en6re
group
 •  15‐minute
6mebox

  16. 16. Scaling
Recommenda6ons
 •  Correlate
team
organiza6on
to
subsystems
or
modules
with
 minimal
cross‐over
 •  Implement
development
infrastructure
to
support
the
number
and
 loca6on
of
developers
so
it
acts
as
a
single
development
 environment
 •  Implement
mee6ng
and
communica6on
infrastructure
op6mized
 for
number
and
loca6on
of
teams
 •  Develop
standards,
guidelines,
training
courses,
templates,
and
 frameworks
to
minimize
the
coordina6on
required
for
intended
 scaling
 •  Develop
coordina6on
mechanisms
for
mul6ple
teams
 •  Ensure
each
team
has
sufficient
resources,
carefully
consider
shared
 resources
 •  Implement
ways
to
develop
a
common
culture
across
teams
 16

  17. 17. Dispersed
Team
Recommenda6ons
 •  Co‐locate
the
team
as
o>en
as
possible,
especially
at
incep6on
and
 key
milestones
 •  Rotate
members
around
 •  Invest
in
(and
plan
for)
tools
that
provide
a
shared
environment
 •  Plan
to
experiment
 •  Establish
a
single
global
instance
of
project
assets,
easily
accessible
 by
all
 •  Try
virtual
team
building
(team
wiki
w/bios
&
photos)
 •  Establish
known
hours,
with
as
much
overlap
as
possible
 •  Apply
high
cohesion
and
low
coupling
to
alloca6on
of
work
to
sites
 •  Develop
a
shared
team
vocabulary
 •  Don't
let
anyone
go
dark
 •  Apply
Scrum‐of‐Scrums
concept
when
mass
remote
mee6ngs
are
 unproduc6ve
 17

  18. 18. Notes
on
the
Meta‐Scrum
 •  Unlike
the
Scrum
of
Scrums
(where
teams
synchronize
and
coordinate
with
the
purpose
of
 execu6ng
on
the
Backlog),
 •  The
Meta‐Scrum
focuses
on
execu6ng
on
the
roadmap
and
the
strategy
while
elimina6ng
side
 channel
conversa6ons
about
the
releases
and
the
roadmap.

It
is
a
gap
reduc6on
exercise.
 •  It
is
owned
by
the
Chief
Product
Owner,
who
comes
in
with
the
plan.

The
par6cipants
act
like
a
 Board
of
Directors
for
the
Product
Owner
who
reviews
and
approves
the
plan.


 •  The
par6cipants
must
have
the
authority
to
make
decisions.

If
someone
is
missing,
that
person
 must
act
in
agreement
with
the
decisions
made
in
the
mee6ng.

 •  Successful
Meta‐Scrums
provide
consistent
answers
to
the
ques6on:
quot;Does
a
Chief
Product
Owner's
 Product
Backlog
have
consent
of
all
the
Stakeholders?quot;
 •  The
Chief
Product
Owner
comes
in
to
in
the
Meta‐Scrum
with
the
plan,
discussing
what
is
meant
by
 plan,
roadmap,
product
backlog
and
other
names.

Whatever
you
use,
have
it
clearly
defined.
 •  Indicators
for
when
a
Meta‐Scrum
is
needed:
 –  Organiza6on
needs
to
reduce
chaos
 –  Need
consent
at
highest
level
of
the
organiza6on
 –  Balancing
mul6ple
projects
 –  Mul6ple
organiza6onal
areas
need
alignment
 –  You
are
in
an
environment
where
change
happens
(there
are
surprises)
 hcp://scrumalliance.pbwiki.com/The+Meta‐Scrum

 18

  19. 19. Going
Beyond
the
Sprint
to
Strategic
Product
Planning
 THE
5
LEVELS
OF
PLANNING

  20. 20. Planning
at
Mul6ple
Levels
 •  Product
Visioning
 •  Product
Roadmap
 •  Release
Plan
 •  Sprint
Plan
 •  Daily
Commitment
 Source:
Hubert
Smits

  21. 21. Planning
at
Mul6ple
Levels
 21
  22. 22. Crea6ng
Memorable
Visions
 •  Elevator
Statement:
 •  Product
Box:
 –  FOR
(target
customer)
 –  WHO
(statement
of
the
need)
 –  THE
(product
name)
is
a
 (product
category)

 –  THAT
(product
key
benefit,
 compelling
reason
to
buy).
 –  UNLIKE
(primary
compe66ve
 alterna6ve),
 –  OUR
PRODUCT
(final
 statement
of
primary
 differen6a6on)

  23. 23. The
Extended
Scrum
Framework
 Daily
Scrum
 Vision or
“Standup”
 Q2
 Q3
 Q4
 24
hours
 Product Roadmap
 Sprint 1
 Sprint
 Sprint
Review
&
 Sprint
Planning
 Sprint
Retrospec-ve
 Release
Plan
 Potentially Shippable Sprint Backlog Product Increment Product
Backlog

  24. 24. Product
Roadmap
 •  The
Product
Owner:
 –  Communicates
the
whole
 –  Determines
when
releases
are
needed
 –  Determines
what
func6onality
is
sufficient
 –  Focuses
on
business
value
derived
from
the
releases
 •  Delivery
team

 –  Sees
the
whole
 –  Learns
about
the
steps
 –  Learns
the
business
priori6es
 –  Provides
technical
input
to
the
roadmap
 24

  25. 25. Product
Roadmap
–
an
example
 April
8,
‘06
 June
3,
‘06
 July
8,
‘06
 Aug
12,
‘06
 Magnesium

 Aluminum

 Silicon
 Phosphorus
 2006.2 2006.3 2006.4
 2006.5 •  For
all
users,
improve
 •  For
all
users,
improve
 •  For
Rally
customers,
 •  For
all
users,
enhance
 customizaXon

and
 usability,
navigaXon
and
 implement
some
of
the
 flexibility
of
requirements
 consistency.
 informaXon
presentaXon.
 most
requested
 hierarchy
 •  For
Product
Owners,
 enhancements
 •  Provide
Configurable
 improve
Roadmap,
and
 EdiXons
 Release
Planning.
 Agile PM Agile PM Agile PM Agile PM •  Custom Enumerations •  Agile Product Manager •  Defect Dropdown •  Associate Iterations with •  Unified Backlog Planning Customization Releases •  New Release Status View System Mgmt. •  Task Ranking •  Ajax-Enabled Detail Pages System Mgmt. System Mgmt. System Mgmt. •  Hierarchical Stories •  Defect Close Rate Metrics Comm. & Collaboration •  Daily Defect Metrics Comm. & Collaboration Platform Comm. & Collaboration Platform Comm. & Collaboration •  Improved UI •  User Filterable •  UI Consistency Notifications Responsiveness •  Improved Navigation Platform •  Tab Customization & Web Platform •  Shared Custom Views Tabs *Rally Agile Pro Edition only
  26. 26. Release
as
a
series
of
Sprints
 •  A
release
comprises
 mul6ple
itera6ons
 •  Each
itera6on
can
be
 thought
of
as
a
same‐ sized
box
 •  Stories
of
different
 sizes
(points)
are
put
 into
each
box
un6l
it
is
 full
 •  The
size
of
the
box
is
 the
planned
velocity
 Source:
“Agile
Es-ma-ng
and
Planning,”
by
Mike
Cohn

  27. 27. An
Agile
Approach
to
Planning
 Release
 Condi6ons
of
 Feedback
 Sa6sfac6on
 (backlog,
budget,
 schedule)
 Release
 Planning
 IteraXon
 Feedback
 Condi6ons
of
 Sa6sfac6on
(backlog,
 schedule) 
 Itera6on
 Development 
 Product 
 planning
 increment
 Source:
“User
Stories
Applied”
and
“Agile
Es-ma-ng
and
Planning,”
by
 Mike
Cohn

  28. 28. An
Agile
Release
Plan
 PrioriXzed
Product
Backlog
 Sprint
n+1
 As
a
frequent
flyer,
I
want
to… The
loca6on
of
the
arrow
is
 As
a
frequent
flyer,
I
want
to… determined
by
team
velocity
 As
a
frequent
flyer,
I
want
to… and
the
number
of
remaining
 As
a
frequent
flyer,
I
want
to… itera6ons
 Sprint
n+2
 As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… Sprint
n+3
 As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… We’ll
be
here
by
the
 As
a
frequent
flyer,
I
want
to… planned
deadline
 As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… Source:
“Agile
Es-ma-ng
and
Planning,”
by
Mike
Cohn

  29. 29. Velocity
 Velocity
 40
 Last
observa6on
=
36
 Mean
(Last
8)
=
33
 30
 Mean
(Worst
3)
=
28
 20
 10
 0
 1
 2
 3
 4
 5
 6
 7
 8
 9
 IteraXons
 Source:
“Agile
Es-ma-ng
and
Planning,”
by
Mike
Cohn

  30. 30. Deriving
Dura6on
Using
Velocity
 PrioriXzed
Product
Backlog
 Itera6on
1
 As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… Itera6on
2
 As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… At
our
slowest
velocity
we’ll
finish
here
 As
a
frequent
flyer,
I
want
to… At
our
current
velocity
we’ll
finish
here
 As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… At
our
long‐term
average
we’ll
finish
here
 As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to… As
a
frequent
flyer,
I
want
to…
  31. 31. Sezng
up
for
Release
Planning
 •  What
is
the
purpose
you
hope
to
accomplish
with
Agile
release
 planning?

 •  Do
you
have
a
release
theme
or
themes?
 •  What
is
the
current
state
of
the
team?

 •  Do
you
have
a
velocity?

 •  Do
you
have
a
good
Defini6on
of
Done?

 •  Do
you
have
a
Product
Backlog?
 •  Is
the
Product
Backlog
Priori6zed
by
the
Product
Owner?

 •  Is
the
Product
Backlog
Es6mated
by
the
whole
team?
 •  Will
the
Product
Owner(s)
and
whole
team
be
in
acendance?
 •  Will
key
members
be
in
acendance
(Architects,
Opera6ons,
QA,
 Product
Marke6ng,
PMO,
etc)?


 •  What
have
I
not
asked
that
is
important
to
know?


  32. 32. Release
Planning
Session
 •  Conduct
a
Release
Planning
Mee6ng
collabora6vely
with
the
whole
 team
(product
owner,
delivery
team,
stakeholders)
 •  Plan
for
a
1‐day
event
(2
days
for
VERY
large
programs)
 •  Put
each
feature
on
an
index
card
(post‐it
notes)
 •  Physically
arrange
the
priori6zed
features
into
the
Releases
 •  For
the
first
release,
physically
arrange
the
priori6zed
features
into
 the
3
or
4
groupings
that
represent
the
Sprints

 •  Post
all
decisions,
risks,
ac6ons
(and
if
necessary,
assump6ons)
on
 the
wall
 •  Consider
appropriate
buffers
and
tradeoff
matrix
before
 commitment

 •  Biggest
risk:
Product
Owner
must
have
a
priori6zed
Product
 Backlog!!

  33. 33. Release
Burn‐up
 33
  34. 34. Informa6on
Radiators:
Big=Beau6ful!
 A
Sample
Task
Board
 © 2007 SolutionsIQ - v15 34
  35. 35. Another
sample
task
board
 35
  36. 36. Project
repor6ng
 •  Minimize
repor6ng
 •  What
gets
measured
gets
done
 •  Make
it
visible
 •  Possible
metrics:
 –  Current
burndown
chart(s)
 –  Sprint
goals
and
changes
to
the
goals
 –  Defects
–
inflow,
ou|low
and
#
open
defects
per
week
 –  Build
quality
per
day/week
 –  Number
of
tests/tests
passed
per
day/week
 –  Velocity
over
the
last
x
Sprints
 –  Ac6on
items,
risks
 36

  37. 37. End
Of
Sprint
Data
 Starting/Ending Metrics
  38. 38. Not
Just
Following
a
Process
 SCRUM
SPIRIT

  39. 39. Scrum
Essen6als
 •  Elaborate
features
just‐in‐6me
for
the
Sprint,
not
while
 in
the
Product
Backlog
 •  Product
Owner
stays
engaged
day‐to‐day
for
the
 elabora6on
and
acceptance
of
features
 •  Teams
are
self‐organizing
and
cross‐func6onal:
 everyone
is
responsible
for
the
Sprint
commitment
 •  Done
means
tested,
integrated
code
&
documenta6on
 and
accepted
by
the
product
owner
 •  Reduce
defect
logging
by
always
moving
to
fully
tested
 code
in
the
Sprint
 •  Ensure
that
so>ware
is
always
close
to
shippable
 39

  40. 40. What
Can
Cause
 
Scrum
Adop6on
to
Fail?
 •  Ineffec6ve
use
of
the
retrospec6ve
 •  Inability
to
get
everyone
in
the
planning
mee6ngs
 •  Failure
to
pay
acen6on
to
the
infrastructure
required
 •  Bad
Scrum
Masters
 •  Unavailable
product
owner,
or
too
many
product
owners
who
can’t
 agree
 •  Rever6ng
to
form
 •  Obtaining
only
“checkbook
commitments”
from
execu6ve
 management
 •  Teams
lacking
authority
and
decision‐making
ability
 •  Not
having
an
onsite
evangelist
for
remote
loca6ons
 •  A
culture
that
does
not
support
learning
 •  The
embrace
of
denial
instead
of
the
brutal
truth
 “11
Ways
Agile
Adop6on
Fails”
–
Jean
Tabaka
 hcp://www.s6ckyminds.com/s.asp?F=S12384_COL_2

 40

  41. 41. Cultural
Change:
The
Hard
Part
 Old Organization New Organization Centralized Distributed Unified perspective Diversified perspective Original meaning Emergent meaning Analytical Creative Analysis to action Learning by doing Certain Uncertain Strategy concept Local action Authoritative Participative Hierarchical Flat Olson,
Edwin
&
Eoyang,
Glenda
 41
  42. 42. Glossary
of
Terms

  43. 43. Glossary
of
Terms
 •  Daily
Scrum
Mee6ng
 –  A
fi>een‐minute
daily
mee6ng
for
each
team
member
to
answer
three
ques6ons:
quot;What
have
I
done
since
 the
last
Scrum
mee6ng?
(i.e.
yesterday)quot;
;
quot;What
will
I
do
before
the
next
Scrum
mee6ng?
(i.e.
today)quot;
;
 quot;What
prevents
me
from
performing
my
work
as
efficiently
as
possible?quot;
The
ScrumMaster
ensures
that
 par6cipants
call
sidebar
mee6ngs
for
any
discussions
that
go
too
far
outside
these
constraints.

 •  Impediments
 –  Anything
that
prevents
a
team
member
from
performing
work
as
efficiently
as
possible
is
an
impediment.
 Each
team
member
has
an
opportunity
to
announce
impediments
during
the
daily
Scrum
mee6ng.
The
 ScrumMaster
is
charged
with
ensuring
impediments
get
resolved.
ScrumMasters
o>en
arrange
sidebar
 mee6ngs
when
impediments
cannot
be
resolved
on
the
spot
in
the
daily
Scrum
mee6ng.

 •  Product
Backlog
 –  The
product
backlog
(or
quot;backlogquot;)
is
the
requirements
for
a
system,
expressed
as
a
priori6zed
list
of
product
 backlog
Items.
These
included
both
func6onal
and
non‐func6onal
customer
requirements,
as
well
as
 technical
team‐generated
requirements.
While
there
are
mul6ple
inputs
to
the
product
backlog,
it
is
the
sole
 responsibility
of
the
product
owner
to
priori6ze
the
product
backlog.

During
a
Sprint
planning
mee6ng,
 backlog
items
are
moved
from
the
product
backlog
into
a
sprint,
based
on
the
product
owner's
priori6es.

 •  Product
Backlog
Item
 –  In
Scrum,
a
product
backlog
item
(quot;PBIquot;,
quot;backlog
itemquot;,
or
quot;itemquot;)
is
a
unit
of
work
small
enough
to
be
 completed
by
a
team
in
one
Sprint
itera6on.
Backlog
items
are
decomposed
into
one
or
more
tasks.


  44. 44. Glossary
of
Terms
 •  Product
Backlog
Item
Effort
 –  Some
Scrum
prac66oners
es6mate
the
effort
of
product
backlog
items
in
ideal
engineering
 days,
but
many
people
prefer
less
concrete‐sounding
backlog
effort
es6ma6on
units.
 Alterna6ve
units
might
include
story
points,
func6on
points,
or
quot;t‐shirt
sizesquot;
(1
for
small,
2
for
 medium,
etc.).
The
advantage
of
arbitrary
units
is
they're
explicit
about
the
dis6nc6on
that
 product
backlog
item
effort
es6mates
are
not
es6mates
of
dura6on.

Also,
es6mates
at
this
 level
are
rough
guesses
that
should
never
be
confused
with
actual
working
hours.

Note
that
 sprint
tasks
are
dis6nct
from
product
backlog
items
and
task
effort
remaining
is
always
 es6mated
in
hours.

 •  Product
Owner
Role
 –  In
Scrum,
a
single
person
must
have
final
authority
represen6ng
the
customer's
interest
in
 backlog
priori6za6on
and
requirements
ques6ons.
This
person
must
be
available
to
the
team
 at
any
6me,
but
especially
during
the
sprint
planning
mee6ng
and
the
sprint
review
mee6ng.

 •  Release
 –  The
transi6on
of
an
increment
of
poten6ally
shippable
product
from
the
development
team
 into
rou6ne
use
by
customers.
Releases
typically
happen
when
one
or
more
sprints
have
 resulted
in
the
product
having
enough
value
to
outweigh
the
cost
to
deploy
it.

 •  Release
Burndown
Chart
 –  In
Scrum,
the
release
burndown
chart
is
a
quot;big
picturequot;
view
of
a
release's
progress.
It
shows
 how
much
work
was
le>
to
do
at
the
beginning
of
each
sprint
comprising
a
single
release.
The
 scope
of
this
chart
is
a
single
release;
however,
a
product
burndown
chart
spans
all
releases.


  45. 45. Glossary
of
Terms
 •  ScrumMaster
Role
 –  The
ScrumMaster
is
a
facilitator
for
the
team
and
product
owner.
Rather
than
manage
the
team,
the
 ScrumMaster
works
to
assist
both
the
team
and
product
owner
in
the
following
ways:

 •  Remove
the
barriers
between
the
development
and
the
product
owner
so
that
the
product
owner
directly
drives
 development.

 •  Teach
the
product
owner
how
to
maximize
return
on
investment
(ROI),
and
meet
his/her
objec6ves
through
Scrum.

 •  Improve
the
lives
of
the
development
team
by
facilita6ng
crea6vity
and
empowerment.

 •  Improve
the
produc6vity
of
the
development
team
in
any
way
possible.

 •  Improve
the
engineering
prac6ces
and
tools
so
that
each
increment
of
func6onality
is
poten6ally
shippable.

 •  Keep
informa6on
about
the
team's
progress
up
to
date
and
visible
to
all
par6es.
 •  Sprint
 –  An
itera6on
of
work
during
which
an
increment
of
product
func6onality
is
implemented.
By
the
book,
an
 itera6on
lasts
30
days.
This
is
longer
than
in
other
agile
methods
to
take
into
account
the
fact
that
a
 func6onal
increment
of
product
must
be
produced
each
sprint.
The
sprint
starts
with
a
one‐day
sprint
 planning
mee6ng.
Many
daily
Scrum
mee6ngs
occur
during
the
sprint
(one
per
day).
At
the
end
of
the
sprint
 we
have
a
sprint
review
mee6ng,
followed
by
a
sprint
retrospec6ve
mee6ng.

 •  Sprint
Backlog
 –  Defines
the
work
for
a
sprint,
represented
by
the
set
of
tasks
that
must
be
completed
to
realize
the
sprint's
 goals,
and
selected
set
of
product
backlog
items.

 •  Sprint
Burndown
Chart
 –  A
sprint
burndown
chart
(or
quot;sprint
burndown
graphquot;)
depicts
the
total
task
hours
remaining
per
day.
This
 shows
you
where
your
team
stands
regarding
comple6ng
the
tasks
that
comprise
the
product
backlog
items
 that
achieve
the
goals
of
the
sprint.
The
X‐axis
represents
days
in
the
sprint,
while
the
Y‐axis
is
effort
 remaining
(usually
in
ideal
engineering
hours).
Ideally
the
chart
burns
down
to
zero
by
the
end
of
the
sprint.


  46. 46. Glossary
of
Terms
 •  Sprint
Goals
 –  Sprint
goals
are
the
result
of
a
nego6a6on
between
the
product
owner
and
the
development
team.
 Meaningful
goals
are
specific
and
measurable.
Instead
of
quot;Improve
scalabilityquot;
try
quot;Handle
five
6mes
as
many
 users
as
version
0.8.quot;
Scrum
focuses
on
goals
that
result
in
demonstrable
product.
The
product
owner
is
 en6tled
to
expect
demonstrable
product
(however
small
or
flimsy)
star6ng
with
the
very
first
Sprint.
In
 itera6ve
development,
subsequent
Sprints
can
increase
the
robustness
or
size
of
the
feature
set.

Have
your
 team
commit
to
goals
that
anyone
will
be
able
to
see
are
met
(or
not
met)
at
the
end
of
the
sprint.
At
sprint
 review
mee6ngs,
the
sprint
demonstra6on
is
conducted
a>er
which
the
team
asks
the
product
owner
 whether
(s)he
feels
the
goals
were
met.

While
some
specific
product
backlog
items
may
not
be
done
at
the
 end
of
a
sprint,
it
should
be
very
unusual
for
a
team
not
to
meet
its
sprint
goals.
Scrum
requires
the
team
to
 no6fy
the
product
owner
as
soon
as
it
becomes
aware
it
will
not
meet
its
goals.

 •  Sprint
Planning
Mee6ng
 –  The
Sprint
planning
mee6ng
is
a
nego6a6on
between
the
team
and
the
product
owner
about
what
the
team
 will
do
during
the
next
sprint.
The
product
owner
and
all
team
members
agree
on
a
set
of
sprint
goals,
which
 is
used
to
determine
which
product
backlog
items
to
commit
from
the
uncommiced
backlog
to
the
sprint.
 The
team
will
then
break
the
backlog
Items
down
into
tasks.

 •  Sprint
Retrospec6ve
Mee6ng
 –  The
sprint
retrospec6ve
mee6ng
is
held
at
the
end
of
every
sprint
a>er
the
sprint
review
mee6ng.
The
team
 and
ScrumMaster
meet
to
discuss
what
went
well
and
what
to
improve
in
the
next
sprint.
The
product
owner
 does
not
acend
this
mee6ng.


  47. 47. Glossary
of
Terms
 •  Sprint
Task
 –  In
Scrum,
a
sprint
task
(or
task)
is
a
unit
of
work
generally
between
four
and
sixteen
hours.
 Team
members
volunteer
for
tasks.
They
update
the
es6mated
number
of
hours
remaining
on
 a
daily
basis,
influencing
the
sprint
burndown
chart.
Tasks
are
contained
by
backlog
items.

 •  Team
 –  A
team
(or
quot;Scrum
teamquot;)
is
op6mally
comprised
of
seven
plus
or
minus
two
people.
For
 so>ware
development
projects,
the
team
members
are
usually
a
mix
of
so>ware
engineers,
 architects,
programmers,
analysts,
QA
experts,
testers,
UI
designers,
etc.
This
is
o>en
called
 quot;cross‐func6onal
project
teamsquot;.
Agile
prac6ces
also
encourage
cross‐func6onal
team
 members.

 •  Team
Member
 –  In
Scrum
parlance,
a
team
member
is
defined
as
anyone
working
on
sprint
tasks
toward
the
 sprint
goal.

 •  Velocity
 –  In
Scrum,
velocity
is
how
much
product
backlog
effort
a
team
can
handle
in
one
sprint.
This
 can
be
es6mated
by
viewing
previous
sprints,
assuming
the
team
composi6on
and
sprint
 dura6on
are
kept
constant.
It
can
also
be
established
on
a
sprint‐by‐sprint
basis,
using
 commitment‐based
planning.

Once
established,
velocity
can
be
used
to
plan
projects
and
 forecast
release
and
product
comple6on
dates.


  48. 48. Ar6cles
 •  “AgileEVM
–
Earned
Value
Management
The
Agile
Way,”
Tamara
Sulaiman,
Agile
Journal,

Jan.
8,
 2007.
 hcp://www.agilejournal.com/ar6cles/ar6cles/agileevm‐%96‐earned‐value‐management‐the‐agile‐ way.html
 •  “Agile
Process
and
Self
Organiza6on,”
Ken
Schwaber,
www.controlchaos.com,
 hcp://www.controlchaos.com/download/Self%20Organiza6on.pdf
 •  “Agile
Top‐Down:
Striking
a
Balance,”
Bryan
Stallings,
Agile
Journal,
Mar.12,
2007.
 hcp://www.agilejournal.com/ar6cles/ar6cles/agile‐top%11down%3a‐striking‐a‐balance.html
 •  “Establishing
and
Maintaining
Top
to
Bocom
Transparency
Using
the
Meta‐Scrum,”
Brent
Barton,
 Agile
Journal,
Oct.
6,
2007.
 hcp://www.agilejournal.com/ar6cles/ar6cles/establishing‐and‐maintaining‐top‐to‐bocom‐ transparency‐using‐the‐meta%11scrum.html
 •  “Making
the
Date,”
Ron
Jefferies,
xprogramming.com,
Nov.
10,
2005.
 hcp://www.xprogramming.com/xpmag/jatmakingthedate.htm
 •  
“The
New
New
Product
Development
Game,”
Takeuchi
and
Nonaka,
Harvard
Business
Review,
Jan.
 1,
1986.
 hcp://harvardbusinessonline.hbsp.harvard.edu/b02/en/common/item_detail.jhtml?id=86116
 •  “Want
Becer
So>ware?
Just
Ask:
Seven
Things
Project
Customers
Can
Do,”
Mike
Cohn,
Becer
 So>ware,
March
2004.
 hcp://www.mountaingoatso>ware.com/system/ar6cle/file/9/WantBecerSo>ware.pdf

  49. 49. Online
Presenta6ons
 •  “Agile
Es6ma6on”
by
Mike
Cohn
 hcp://video.google.com/videoplay?docid=9061050925476245469&q=+site %3Avideo.google.com&total=101&start=0&num=10&so=0&type=search&plindex= 3
 •  
“Agile
Project
Management
Planning
and
Budgezng”
by
David
Hussman
 hcp://www.infoq.com/presenta6ons/Agile‐planning‐and‐budgezng
 •  
“Agile
Quality:
A
Canary
in
a
Coal
Mine”
by
Ken
Schwaber









 hcp://www.infoq.com/presenta6ons/agile‐quality‐canary‐coalmine
 •  
“Agile
Retrospec6ves:
Making
Good
Teams
Great”
by
Esther
Derby
and
Diana
 Larsen
hcp://video.google.com/videoplay?docid=‐7910406883328902493
 •  
“How
to
Plan
Projects
with
Distributed
Teams”
by
Hubert
Smits
 hcp://video.google.com/videoplay?docid=2259483443972461251
 •  
Interview:
Jeff
Sutherland
on
“Scrum
and
Not‐Scrum”
























 hcp://www.infoq.com/interviews/jeff‐sutherland‐scrum‐rules
 •  
“ScrumMaster:
Ken
Schwaber’s
Top
Tips”


















































































 hcp://www.scrum‐master.com/top6ps/flash.html
 •  
“The
Roots
of
Scrum”
by
Jeff
Sutherland










































 hcp://www.infoq.com/presenta6ons/The‐Roots‐of‐Scrum


  50. 50. Other
Useful
Links
 •  Agile
&
Scrum
Training:
hcp://www.solu6onsiq.com/scrum/training_events.html
 •  Agile
Alliance
website:
www.agilealliance.org
 •  Agile
Journal:
www.agilejournal.com
 •  Agile
Manifesto:
www.agilemanifesto.org
 •  Agile
Product
Management:
 hcp://allaboutproductmanagement.blogspot.com/2007/04/agile‐product‐ management.html
 •  Becer
So>ware
Magazine
and
www.s6ckylecer.com
 •  Extreme
Product
Mgmt.:
 hcp://www.pragma6cmarke6ng.com/publica6ons/topics/06/0606sj
 •  InfoQ
–
Internet
So>ware
Development
Community:
www.infoq.com
 •  Jeff
Sutherland’s
website:
www.jeffsutherland.com
 •  Ken
Schwaber’s
website:
www.controlchaos.com/
 •  Mike
Cohn’s
websites:
www.mountaingoatso>ware.com,
www.planningpoker.com
 •  Ron
Jeffrey’s
website:
www.xprogramming.com
 •  Scrum
Alliance
website:
www.scrumalliance.com


×