The document discusses strategies for scaling agile practices in large organizations. It outlines a three year roadmap for organizations to gradually adopt agile, beginning with reducing work carried over between sprints in year one, optimizing project portfolios in year two, and moving to incremental funding in year three. The document also covers techniques for balancing strategic planning needs with adaptive planning, forming meta-scrums to coordinate multiple agile teams, and establishing definitions of done for both individual teams and product releases.
2. Chris
Sterling
Co-‐founder
of
Agile
Advantage
and
VP
of
Engineering
(www.AgileAdvantage.com)
Author
of
Book
“Managing
SoBware
Debt:
Building
for
Inevitable
Change”
Consults
on
soBware
technology,
Agile
technical
pracKces,
Scrum,
and
effecKve
management
techniques
CerKfied
Scrum
Trainer
InnovaKon
Games®
Trained
Email:
chris@sterlingbarton.com
Web:
hWp://www.agileadvantage.com
Facilitator Blog:
hWp://www.geYngagile.com
Follow
me
on
TwiWer:
@csterwa
Open
Source
Developer
2
Wednesday, November 2, 2011
3. Agenda
Business
Value
and
Agility
• How
AdapKve
Planning
Stresses
Strategic
Planning
Balancing
Signal
to
Noise
at
Scale
The
Agile
Business
Roadmap
• Year
1:
Reduce
Carryover
• Year
2:
OpKmize
Por_olio
• Year
3:
Incremental
Funding
• What
we
can
do
to
help
all
along
the
way
Ques:ons
&
Answers
3
Wednesday, November 2, 2011
22. Conclusion:
AdapKve
Planning
Stresses
Strategic
Planning
(Fine
Print:
**
Except
in
cases
of
PerfecKon
**)
10
Wednesday, November 2, 2011
23. Typical
Outcomes
Business
can’t
take
advantage
of
Adap:ve
Planning
methods
It
is
decided
that
Agile
can’t
scale
Subop:mal
results
Restarted
several
:mes
11
Wednesday, November 2, 2011
27. Agile
Business
Roadmap
Year 1:
Reduce carryover
Iden:fy
issues
sooner
Make
decisions
earlier
Demonstrate
progress
frequently
Focus
on
quality
15
Wednesday, November 2, 2011
29. Component
Teams
“Component
Team”
structure
Separate
Product
Backlog
Managing
dependencies
is
oBen
serialized
ProblemaKc
integraKon
issues
are
typically
faced
if
mulKple
components
are
required
to
release
Use
an
“IntegraKon
Team”
to
pull
components
together
Causes
more
rework
than
“Feature
Team”
structure
17
Wednesday, November 2, 2011
30. Feature
Teams
“Feature
Team”
structure
Uses
common
Product
Backlog
IntegraKon
is
done
in
parallel
Requires
high
levels
of
communicaKon
across
teams
to
resolve
integraKon
issues
Forces
Product
Owners
to
be
more
coordinated
Sprints
should
be
synchronized
Cross
team
ferKlizaKon
is
a
requirement
to
successfully
deliver
in
parallel
18
Wednesday, November 2, 2011
31. Story
Map
Areas
of
func:onality/capabili:es
on
top
Place
associated
user
stories
ver:cally
19
Wednesday, November 2, 2011
32. Story
Map
-‐
Next
Release
Draw
line
that
represents
viable
release
• Customer
features
above
the
line
are
“in”
• DoMed
line
represents
nego:ability
!"
20
Wednesday, November 2, 2011
34. DefiniKon
of
Done
-‐
Assert
Quality
Acceptance defined criteria for each Code checked in with reference to
user story US#/Task#
Unit tests written and passed Tested on FE
Code compiles with no errors and no Integration test written & passes
warnings
Test code reviewed
New code doesn’t break existing code
Environment requirements documented
Test case review (Dev to review test
Interface document updated/added
case written)
and checked in to SVN
Architectural impact assessed and
Acceptance criteria verified complete
artifacts updated if necessary
All P1-P3 bugs for the story are
Comments in code
closed
Error codes added
Test approves user story
Code reviewed by peer
Story demonstrated to product owner
and accepted on Target Platform
22
Wednesday, November 2, 2011
35. Release
DefiniKon
of
Done
Every
release
should
have
clear
quality
criteria
With
a
“Release
Defini:on
of
Done”
you
can
understand
targets
beMer
Measure
the
gap
between
the
teams’
Defini:on
of
Done
and
a
Release
Defini:on
of
Done.
• This
gap
is
a
source
of
quality
issues
and
represents
significant
risk
to
schedule
Wednesday, November 2, 2011
36. Release
DefiniKon
of
Done
Every
release
should
have
clear
quality
criteria
With
a
“Release
Defini:on
of
Done”
you
can
understand
targets
beMer
Measure
the
gap
between
the
teams’
Defini:on
of
Done
and
a
Release
Defini:on
of
Done.
• This
gap
is
a
source
of
quality
issues
and
represents
significant
risk
to
schedule
Wednesday, November 2, 2011
37. Agile
Business
Roadmap
Year 2:
Optimize Project Portfolio
Iden:fy
emergent
value
Compare
performance
across
porRolio
Increase
overall
value/cost
ra:o
Lower
cost
of
compliance
Deliver
smaller
batches
Reduce
stabiliza:on
periods
Coordinate
across
groups
24
Wednesday, November 2, 2011
38. Process
AutomaOon
&
OpOmizaOon
with
AddiOon
of
Appropriate
“Slack”
Wednesday, November 2, 2011
41. TradiKonal
Source
Control
Management
Code
Complete
Version
1 Integrate
for
Branch Version
2
Main
Branch
26
Wednesday, November 2, 2011
42. TradiKonal
Source
Control
Management
Code
Complete
Version
1 Integrate
for
Branch Version
2
Debt Main
Branch
Death
March
26
Wednesday, November 2, 2011
43. TradiKonal
Source
Control
Management
Code
Complete
Version
1 Integrate
for
Branch Version
2
Debt Main
Branch
Death
March
{
Debt
accrues
quickly
within
stabilizaCon
periods
26
Wednesday, November 2, 2011
47. Flexible
Source
Control
Management
Version 1 Version 2
Main Branch
27
Wednesday, November 2, 2011
48. Flexible
Source
Control
Management
Version 1 Version 2
Main Branch
{
Not Easy! Must have proper infrastructure to do this.
27
Wednesday, November 2, 2011
51. Agile
Business
Roadmap
Year 3:
Incremental Funding
Safe-‐fail
environment
Use
experimenta:on
as
a
compe::ve
advantage
Combat
compe::ve
threats
Integrate
technical
&
customer
feedback
promptly
Aggressively
use
commit/transform/kill
for
porRolio
op:miza:on
Pull
ini:a:ves
through
teams
rather
than
pushing
resources
to
projects
30
Wednesday, November 2, 2011
52. PorEolio
Management
Decisions:
Commit,
Transform,
Kill
Source:
Johanna
Rothman
“Manage
Your
Project
PorLolio”
hNp://www.amazon.com/Manage-‐Your-‐Project-‐PorLolio-‐first/dp/B004SMU0OW
Wednesday, November 2, 2011
53. EsKmates
are
Unreliable
but
Useful
Es:mate
using
rela:ve
size
Affinity
Es:ma:ng
technique*
Affinity
EsKmaKng
How-‐To:
hWp://www.geYngagile.com/2008/07/04/affinity-‐esKmaKng-‐a-‐how-‐to/
32
Wednesday, November 2, 2011
56. Early
Warning
Signs
Early
Warnings:
•Broken
Builds
•Broken
Automated
Tests
•Broken
Custom
Thresholds
35
Wednesday, November 2, 2011
57. Early
Warnings:
•Design
Debt
in
DuplicaOon
(DRY)
•Technical
Debt
in
Code
Complexity
•Quality
Debt
in
Bug
DB
(Break/Fix)
•Other
Custom
Thresholds
36
Wednesday, November 2, 2011
58. Project
Por_olio
Kill?
Early
Warnings:
•When
transform
and
re-‐”commit”
is
not
a
valid
opOon:
•“Kill”
should
be
an
opOon
on
the
table
MORE
37
Wednesday, November 2, 2011
59. Thank
you!
QuesOons
&
Answers
Wednesday, November 2, 2011
60. Come
see
us
at
AgileAdvantage.com
39
Wednesday, November 2, 2011