Traditionally, projects are managed based on cost, schedule, and scope. This continues to be insufficient and leads to poor outcomes, unsustainable development efforts, quality issues, and software that may meet requirements but not the expectations of users. This talk will go into how organizations can integrate quality and value considerations into their portfolio management strategies leading to less surprises and more valuable outcomes. The talk will go into detail about how Agile, Lean thinking, and Managing Software Debt can give a more holistic view of the project portfolio.

1. Integra(ng
Quality
into
Project
Por3olio
Management
Friday, October 28, 2011

2. Chris
Sterling
Co-­‐founder
of
Agile
Advantage
and
VP
of
Engineering
(www.AgileAdvantage.com)
Author
of
Book
“Managing
So;ware
Debt:
Building
for
Inevitable
Change”
Consults
on
so;ware
technology,
Agile
technical
pracGces,
Scrum,
and
effecGve
management
techniques
CerGfied
Scrum
Trainer
InnovaGon
Games®
Trained
Email:
chris@sterlingbarton.com
Web:
h5p://www.agileadvantage.com
Facilitator Blog:
h5p://www.ge<ngagile.com
Follow
me
on
Twi5er:
@csterwa
Open
Source
Developer
2
Friday, October 28, 2011

3. Agenda
Pa5erns
for
Scaling
Agile
delivery
• Problems
of
Scaling
SoDware
Delivery
Balancing
Signal
to
Noise
at
Scale
• DefiniHon
of
Done
• Source
Control
Management
• ConHnuous
IntegraHon
• Quality
Dashboards
PorNolio
Management
Decisions:
• Commit,
Transform,
Kill
3
Friday, October 28, 2011

4. Pa6erns
for
Scaling
Agile
delivery
Friday, October 28, 2011

5. Component
Teams
“Component
Team”
structure
Separate
Product
Backlog
Managing
dependencies
is
oDen
serialized
ProblemaHc
integraHon
issues
are
typically
faced
if
mulHple
components
are
required
to
release
Use
an
“IntegraHon
Team”
to
pull
components
together
Causes
more
rework
than
“Feature
Team”
structure
5
Friday, October 28, 2011

6. Feature
Teams
“Feature
Team”
structure
Uses
common
Product
Backlog
IntegraHon
is
done
in
parallel
Requires
high
levels
of
communicaHon
across
teams
to
resolve
integraHon
issues
Forces
Product
Owners
to
be
more
coordinated
Sprints
should
be
synchronized
Cross
team
ferHlizaHon
is
a
requirement
to
successfully
deliver
in
parallel
6
Friday, October 28, 2011

7. Story
Map
Areas
of
funcHonality/capabiliHes
on
top
Place
associated
user
stories
verHcally
7
Friday, October 28, 2011

8. Story
Map
-­‐
Next
Release
Draw
line
that
represents
viable
release
• Customer
features
above
the
line
are
“in”
• Do5ed
line
represents
negoHability
!"
8
Friday, October 28, 2011

9. Forming
the
Meta-­‐Scrum
9
Friday, October 28, 2011

10. Problems
Scaling
Agile
methods
Dependencies
across
teams
IntegraHon
points
across
architecture
Cross-­‐team
coordinaHon
Inconsistent
quality
standards
MulHple
lists
of
work
Larger
batches
created
for
deployment
MulH-­‐level
planning
And
probably
much
more...
10
Friday, October 28, 2011

11. Balancing
Signal
Indicators
Value
Quality Constraints
Source:
Jim
Highsmith (Schedule,
Cost,
Scope)
11
Friday, October 28, 2011

12. Problems
We’ll
Focus
On
-­‐
Quality
Dependencies
across
teams
Integra(on
points
across
architecture
Cross-­‐team
coordina(on
Inconsistent
quality
standards
Mul(ple
lists
of
work
Larger
batches
created
for
deployment
MulH-­‐level
planning
And
probably
much
more...
12
Friday, October 28, 2011

13. DefiniUon
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
13
Friday, October 28, 2011

14. Release
DefiniUon
of
Done
Every
release
should
have
clear
quality
criteria
With
a
“Release
DefiniHon
of
Done”
you
can
understand
targets
be5er
Measure
the
gap
between
the
teams’
DefiniHon
of
Done
and
a
Release
DefiniHon
of
Done.
• This
gap
is
a
source
of
quality
issues
and
represents
significant
risk
to
schedule
Friday, October 28, 2011

15. Release
DefiniUon
of
Done
Every
release
should
have
clear
quality
criteria
With
a
“Release
DefiniHon
of
Done”
you
can
understand
targets
be5er
Measure
the
gap
between
the
teams’
DefiniHon
of
Done
and
a
Release
DefiniHon
of
Done.
• This
gap
is
a
source
of
quality
issues
and
represents
significant
risk
to
schedule
Friday, October 28, 2011

16. TradiUonal
Source
Control
Management
15
Friday, October 28, 2011

17. TradiUonal
Source
Control
Management
Main
Branch
15
Friday, October 28, 2011

18. TradiUonal
Source
Control
Management
Code
Complete
Version
1 Integrate
for
Branch Version
2
Main
Branch
15
Friday, October 28, 2011

19. TradiUonal
Source
Control
Management
Code
Complete
Version
1 Integrate
for
Branch Version
2
Debt Main
Branch
Death
March
15
Friday, October 28, 2011

20. TradiUonal
Source
Control
Management
Code
Complete
Version
1 Integrate
for
Branch Version
2
Debt Main
Branch
Death
March
{
Debt
accrues
quickly
within
stabilizaBon
periods
15
Friday, October 28, 2011

21. Flexible
Source
Control
Management
16
Friday, October 28, 2011

22. Flexible
Source
Control
Management
Main Branch
16
Friday, October 28, 2011

23. Flexible
Source
Control
Management
Version 1
Main Branch
16
Friday, October 28, 2011

24. Flexible
Source
Control
Management
Version 1 Version 2
Main Branch
16
Friday, October 28, 2011

25. Flexible
Source
Control
Management
Version 1 Version 2
Main Branch
{
Not Easy! Must have proper infrastructure to do this.
16
Friday, October 28, 2011

26. ConUnuous
IntegraUon
17
Friday, October 28, 2011

27. 18
Friday, October 28, 2011

28. Por3olio
Management
Decisions:
Commit,
Transform,
Kill
Source:
Johanna
Rothman
“Manage
Your
Project
PorBolio”
hDp://www.amazon.com/Manage-­‐Your-­‐Project-­‐PorBolio-­‐first/dp/B004SMU0OW
Friday, October 28, 2011

29. EsUmates
are
Unreliable
but
Useful
EsHmate
using
relaHve
size
Affinity
EsHmaHng
technique*
Affinity
EsHmaHng
How-­‐To:
h5p://www.ge<ngagile.com/2008/07/04/affinity-­‐esHmaHng-­‐a-­‐how-­‐to/
20
Friday, October 28, 2011

30. PorYolio
Level
Project
Commitment
21
Friday, October 28, 2011

31. PorYolio
Project
TransformaUon
22
Friday, October 28, 2011

32. Early
Warning
Signs
Early
Warnings:
•Broken
Builds
•Broken
Automated
Tests
•Broken
Custom
Thresholds
23
Friday, October 28, 2011

33. Early
Warnings:
•Design
Debt
in
DuplicaWon
(DRY)
•Technical
Debt
in
Code
Complexity
•Quality
Debt
in
Bug
DB
(Break/Fix)
•Other
Custom
Thresholds
24
Friday, October 28, 2011

34. Project
PorYolio
Kill?
Early
Warnings:
•When
transform
and
re-­‐”commit”
is
not
a
valid
opWon:
•“Kill”
should
be
an
opWon
on
the
table
MORE
25
Friday, October 28, 2011

35. Thank
you!
Ques(ons
&
Answers
Friday, October 28, 2011

36. Come
see
us
at
AgileAdvantage.com
27
Friday, October 28, 2011