Agile Methods for Scaling Delivery

Dollars
and
Dates
Are
Killing
Agile

Wednesday, November 2, 2011

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

eﬀecKve
management
techniques
CerKﬁed
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

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

Value

What
is
Value?

5

Agile

Value

Agile

Value

What’s
In-‐Between?

Agile

Value
Demand


Value
Demand

Rhythm
of
the
Business


Value
Demand

Rhythm
of
the
Business
Human

CFO Resources
Cost
Constraints
People
Constraints


Value
Demand

Rhythm
of
the
Business
Human

CFO Resources
Cost
Constraints
People
Constraints

PorEolio/Budget

Value
Demand
PorEolio/Budget


Value
Demand
PorEolio/Budget

Agile

Value
Demand
PorEolio/Budget
Perfec&on

Goes
Here

Agile

10

?
10

Conclusion:
AdapKve
Planning
Stresses

Strategic
Planning
(Fine
Print:
**
Except
in
cases
of
PerfecKon
**)

10

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

Balancing
Signal
to
Noise
at
Scale


Balancing
Signal
Indicators

Value

Quality Constraints
Source:
Jim
Highsmith (Schedule,
Cost,
Scope)

13

The
Agile
Business
Roadmap


Agile
Business
Roadmap
Year 1:
Reduce carryover
Iden:fy
issues
sooner
Make
decisions
earlier
Demonstrate
progress
frequently
Focus
on
quality

15

PaMerns
for
Scaling
Agile
delivery


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

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

Story
Map
Areas
of
func:onality/capabili:es
on
top
Place
associated
user
stories
ver:cally

19

Story
Map
-‐
Next
Release
Draw
line
that
represents
viable
release
• Customer
features
above
the
line
are
“in”
• DoMed
line
represents
nego:ability

!"
20

Forming
the
Meta-‐Scrum

21

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

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


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

Process
AutomaOon
&
OpOmizaOon

with
AddiOon
of
Appropriate
“Slack”


TradiKonal
Source
Control
Management

26

TradiKonal
Source
Control
Management

Main
Branch

26

TradiKonal
Source
Control
Management

Code
Complete
Version
1 Integrate
for
Branch Version
2

Main
Branch

26

TradiKonal
Source
Control
Management

Code
Complete
Version
1 Integrate
for
Branch Version
2

Debt Main
Branch

Death
March

26

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

Flexible
Source
Control
Management

27

Flexible
Source
Control
Management

Main Branch

27

Flexible
Source
Control
Management

Version 1

Main Branch

27

Flexible
Source
Control
Management

Version 1 Version 2

Main Branch

27

Flexible
Source
Control
Management

Version 1 Version 2

Main Branch

{
Not Easy! Must have proper infrastructure to do this.

27

ConKnuous
IntegraKon

28

29

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

PorEolio
Management
Decisions:
Commit,
Transform,
Kill
Source:
Johanna
Rothman
“Manage
Your
Project
PorLolio”
hNp://www.amazon.com/Manage-‐Your-‐Project-‐PorLolio-‐ﬁrst/dp/B004SMU0OW


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

Por_olio
Level
Project
Commitment

33

Por_olio
Project
TransformaKon

34

Early
Warning
Signs

Early
Warnings:
•Broken
Builds
•Broken
Automated
Tests
•Broken
Custom
Thresholds

35

Early
Warnings:
•Design
Debt
in
DuplicaOon
(DRY)
•Technical
Debt
in
Code
Complexity
•Quality
Debt
in
Bug
DB
(Break/Fix)
•Other
Custom
Thresholds

36

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

Thank
you!
QuesOons
&
Answers


Come
see
us
at
AgileAdvantage.com

39

Agile Methods for Scaling Delivery

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Agile Methods for Scaling Delivery

Similar to Agile Methods for Scaling Delivery (20)

More from Chris Sterling

More from Chris Sterling (20)

Recently uploaded

Recently uploaded (20)

Agile Methods for Scaling Delivery