These are the slides I presented to the QASIG Seattle group on May 9, 2012.

1. Managing
So)ware
Debt
Workshop
Tuesday, May 8, 2012

2. First
Things
First...
@csterwa
#swdebt
2
Tuesday, May 8, 2012

3. Chris
Sterling
Co-­‐founder
&
CTO
of
Agile
Advantage
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
InnovaKon
Games®
Trained
Facilitator Email:
chris@agileadvantage.com
Web:
h<p://www.agileadvantage.com
CerKfied
Scrum
Trainer Follow
me
on
TwiTer:
@csterwa
Blog:
h<p://www.ge?ngagile.com
Open
Source
Developer Hashtag
for
presentaKon:
#swdebt
3
Tuesday, May 8, 2012

4. Agenda
Managing
So)ware
Debt
• The
“3
Amigos”
PaHern
Overview • Test-­‐Driven
Design
So)ware
Debt
Types Monitoring
Quality
• Technical • The
Power
of
2
Scripts
• Quality • Con=nuous
Integra=on
• Configura=on
Management • Automated
Promo=on
• Design • Advanced
Quality
Metrics
• Pla@orm
Experience Trending
and
Analysis
Asser=ng
Quality Wrap
Up
• Defini=on
of
Done • So)ware
Debt
Management
Strategy
• Test
Automa=on
• The
“No
Defect”
Mindset
4
Tuesday, May 8, 2012

5. Managing
So)ware
Debt
Overview
Let
me
tell
you
a
potenKally
familiar
story…
Tuesday, May 8, 2012

6. Tuesday, May 8, 2012

7. Lack
of
emphasis
on
so'ware
quality
a2ributes
contributes
to
decay
Tuesday, May 8, 2012

8. Principle:
No
maTer
what,
the
cost
of
addressing
soBware
debt
increases
with
Kme.
Tuesday, May 8, 2012

9. Types
of
So)ware
Debt
Technical,
Quality,
ConfiguraKon
Management,
Design,
and
Plaorm
Experience
Tuesday, May 8, 2012

10. Why
not
just
call
it
all
“ Technical
Debt”
Technical
debt
tended
to
focus
more
on
programming
aspects
of
soBware
delivery
and
leB
out
full
soBware
development
life
cycle
Each
type
of
soBware
debt
can
be
managed
and
monitored
using
different
tools
and
approaches
Focusing
on
managing
each
type
of
soBware
debt
simplifies
creaKon
of
an
overall
strategy
that
promotes
holisKc
perspecKve
10
Tuesday, May 8, 2012

11. Types
of
SoBware
Debt
Technical
Debt:
These
are
the
ac=vi=es
that
a
team
or
team
members
take
shortcuts
on
now
that
will
impede
future
development
if
le)
as
is.
Quality
Debt:
There
is
a
diminishing
ability
to
verify
the
func=onal
and
technical
quality
of
so)ware:
the
“Break/Fix”
mentality.
Configura5on
Management
Debt:
Integra=on
and
release
management
become
more
risky,
complex,
and
error-­‐prone.
Design
Debt:
The
cost
of
adding
features
is
increasing
toward
the
point
where
it
is
more
than
the
cost
of
wri=ng
from
scratch.
Pla:orm
Experience
Debt:
The
availability
and
alignment
of
people
to
business
objec=ves
that
involve
so)ware
changes
is
becoming
more
limited
or
cost-­‐prohibi=ve.
8
Tuesday, May 8, 2012

12. AsserGng
Quality
Teams
must
focus
on
asserKng
sustainable
quality
to
support
future
customer
needs
in
a
Kmely
manner
Tuesday, May 8, 2012

13. DefiniGon
of
Done
SoBware
developments
assert
what
finished,
working
soBware
entails
to
support
predictable
delivery
into
the
future
Tuesday, May 8, 2012

14. 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
14
Tuesday, May 8, 2012

15. Release
DefiniKon
of
Done
Every
release
should
have
clear
quality
criteria
With
a
“Release
DefiniKon
of
Done”
you
can
understand
targets
beTer
Measure
the
gap
between
the
teams’
DefiniKon
of
Done
and
a
Release
DefiniKon
of
Done.
• This
gap
is
a
source
of
quality
issues
and
represents
significant
risk
to
schedule
Tuesday, May 8, 2012

16. Case
Study:
Test
AutomaKon
Reduces
Cost
of
Change
Tuesday, May 8, 2012

17. Manual
Regression
TesKng
TesKng
was
taking
75
person
hours
during
2
full
test
runs
consisKng
of:
• Comprehensive
manual
regression
tesKng
• Data
conversion
and
validaKon
Cost
for
tesKng
was
$17,000
each
iteraKon
17
Tuesday, May 8, 2012

18. Introducing
Fit
into
TesKng
Process
ABer
8
iteraKons
team
had
introduced
healthy
amount
of
Fit
fixtures
and
automated
tests
Reduced
70+
hour
test
runKme
down
to
6
hours
which
now
included:
• Fit
automated
regression
tesKng
• Data
conversion
and
validaKon
automated
with
Fit
fixtures
Reduced
cost
of
tesKng
each
iteraKon
from
$17,000
to
$7,000
18
Tuesday, May 8, 2012

19. The
Agile
Regression
TesKng
Triangle*
*
The
Agile
Triangle
has
been
modified
from
Mike
Cohn’s
original
version
19
Tuesday, May 8, 2012

20. The
Agile
Regression
TesKng
Triangle*
Automated
Unit
Tests
Make
up
largest
por.on
of
regression
tests
and
are
developed
by
programmers
*
The
Agile
Triangle
has
been
modified
from
Mike
Cohn’s
original
version
19
Tuesday, May 8, 2012

21. The
Agile
Regression
TesKng
Triangle*
Integra5on
Tests
Automated
&
Exploratory
Automated
Unit
Tests
Make
up
largest
por.on
of
regression
tests
and
are
developed
by
programmers
*
The
Agile
Triangle
has
been
modified
from
Mike
Cohn’s
original
version
19
Tuesday, May 8, 2012

22. The
Agile
Regression
TesKng
Triangle*
Smoke++
Tests
Risk-­‐based
UI
&
API
Automated Integra5on
Tests
Tests Automated
&
Exploratory
Automated
Unit
Tests
Make
up
largest
por.on
of
regression
tests
and
are
developed
by
programmers
*
The
Agile
Triangle
has
been
modified
from
Mike
Cohn’s
original
version
19
Tuesday, May 8, 2012

23. The
“3
Amigos”
Pa<ern*
Quickly
get
testers,
coders,
and
business
on
the
same
page
before
building
based
on
a
requirement
*
The
Three
Amigos
paHern
originally
coined
by
George
Dinwiddie
hHp://www.s=ckyminds.com/s.asp?F=S17232_COL_2
Tuesday, May 8, 2012

24. The
Three
Amigos
PaTern
As a Shopper I want to
receive updates on incredible
deals that are located near
my home so that I can save
money on my purchases
Acceptance Criteria:
•Save Shopper’s location
•Ask Shopper if they want to receive
localized deals daily
•Send notification of incredible deals to
Shoppers located within 10 miles each
morning
•Allow Shopper to stop receiving
localized deals
21
Tuesday, May 8, 2012

25. The
Three
Amigos
PaTern
As a Shopper I want to
receive updates on incredible
deals that are located near
my home so that I can save
money on my purchases
•What
areas
of
the
applica=on
will
this
affect?
•What
is
the
overall
design?
(UI,
API,
UX,
etc…)
•What
are
the
details
test
cases
for
this
user
story
and
it’s
acceptance
criteria?
•What
about
nega=ve
test
condi=ons?
•What
about
boundary
condi=ons?
•How
might
we
put
exis=ng
func=onality
at
risk?
22
Tuesday, May 8, 2012

26. The
Three
Amigos
PaTern
At
minimum
include
tester,
coder
&
business
rep
in
discussion
Should
only
take
30
minutes
to
1
hour
for
user
stories
Focus
on
clarificaKon
and
design
through
testable
inputs/
23
Tuesday, May 8, 2012

27. Acceptance
Test-­‐Driven
Development
24
Tuesday, May 8, 2012

28. Release
Management
“If
releases
are
like
giving
birth,
then
you
must
be
doing
something
wrong.”
-­‐
Robert
Benefield
Tuesday, May 8, 2012

29. Case
Study:
Enterprise
Agile
AdopKon
180+
person
“Web
2.0”
product
organiza=on
Waterfall
SDLC
that
development
uses
to
deliver
in
6
month
release
cycles
Want
to
use
Agile
methods
to
be
more
responsive
to
users
and
keep
up
with
other
“Web
2.0”
companies
Transi=oned
to
Agile
methods
on
15
teams
in
3
months
Changed
release
management
strategy,
added
XP
technical
prac=ces,
and
implemented
Scrum
product
development
framework
for
scaled
coordina=on
Able
to
release
every
week
to
users
within
4
months
Used
streamlined
deployment
environment
process
to
validate
product
changes
daily
using
Con=nuous
Integra=on
and
automated
promo=ons
26
Tuesday, May 8, 2012

30. The
Power
of
2
Scripts:
Deploy
&
Rollback
27
Tuesday, May 8, 2012

31. TradiKonal
Source
Control
Management
28
Tuesday, May 8, 2012

32. TradiKonal
Source
Control
Management
Main
Branch
28
Tuesday, May 8, 2012

33. TradiKonal
Source
Control
Management
Code
Complete
Version
1 Integrate
for
Branch Version
2
Main
Branch
28
Tuesday, May 8, 2012

34. TradiKonal
Source
Control
Management
Code
Complete
Version
1 Integrate
for
Branch Version
2
Debt Main
Branch
Death
March
28
Tuesday, May 8, 2012

35. TradiKonal
Source
Control
Management
Code
Complete
Version
1 Integrate
for
Branch Version
2
Debt Main
Branch
Death
March
{
Debt
accrues
quickly
within
stabiliza5on
periods
28
Tuesday, May 8, 2012

36. Flexible
Source
Control
Management
29
Tuesday, May 8, 2012

37. Flexible
Source
Control
Management
Main Branch
29
Tuesday, May 8, 2012

38. Flexible
Source
Control
Management
Version 1
Main Branch
29
Tuesday, May 8, 2012

39. Flexible
Source
Control
Management
Version 1 Version 2
Main Branch
29
Tuesday, May 8, 2012

40. Flexible
Source
Control
Management
Version 1 Version 2
Main Branch
{
Not Easy! Must have proper infrastructure to do this.
29
Tuesday, May 8, 2012

41. Scaling
ConKnuous
IntegraKon
End-­‐to-­‐End
&
Load/Stress
Integrated
Component
Valida5on
Component
Valida5on
30
Tuesday, May 8, 2012

42. Automated
PromoKon
to
Environments
31
Tuesday, May 8, 2012

43. Advanced
Quality
AsserGons
Using
Automated
Tools
and
Dashboards
Tuesday, May 8, 2012

44. ConKnuous
IntegraKon
33
Tuesday, May 8, 2012

45. Quality
Dashboard
-­‐
Sonar
34
Tuesday, May 8, 2012

46. Quality
Dashboard
-­‐
Sonar
35
Tuesday, May 8, 2012

47. Quality
Dashboard
-­‐
Sonar
36
Tuesday, May 8, 2012

48. Quality
Dashboard
-­‐
Sonar
37
Tuesday, May 8, 2012

49. Early
Warning
Signs
Early
Warnings:
•Broken
Builds
•Broken
Automated
Tests
•Broken
Custom
Thresholds
38
Tuesday, May 8, 2012

50. Early
Warning
on
Quality
Dashboard
Early
Warnings:
•Design
Debt
in
Duplica=on
(DRY)
•Technical
Debt
in
Code
Complexity
•Quality
Debt
in
Bug
DB
(Break/Fix)
•Other
Custom
Thresholds
39
Tuesday, May 8, 2012

51. The
“No
Defect”
Mindset
“What
he
needs
is
some
way
to
pay
back.
Not
some
way
to
borrow
more.”
-­‐-­‐
Will
Rogers
39
Tuesday, May 8, 2012

52. Ken
Schwaber
“For
every
[dollar]
of
compe==ve
advantage
gained
by
cuung
quality,
it
costs
$4
to
restore
it;
and
so)ware
is
an
organiza=onal
asset
and
decisions
to
cut
quality
must
be
made
by
execu=ve
management
and
reflected
in
the
financial
statements.”
hHp://www.infoq.com/presenta=ons/agile-­‐quality-­‐canary-­‐coalmine
Tuesday, May 8, 2012

53. Case
Study:
Field
Support
ApplicaKon
2000+
users
access
applica=on
each
day
Applica=on
supports
mul=ple
perspec=ves
and
workflows
from
Field
Support
Opera=ons
to
Customer
Service
Team
of
5
people
delivering
features
on
exis=ng
Cold
Fusion
pla@orm
implementa=on
Migra=ng
Architecture
to
Spring/Hibernate
in
slices
while
s=ll
delivering
valuable
features
36
2-­‐week
Sprints,
33
produc=on
releases,
and
only
1
defect
found
in
produc=on
So,
what
was
the
defect
you
say?
Let
me
tell
you…
40
Tuesday, May 8, 2012

54. Can
We
Afford
a
“No
Defect”
Policy?
This
team
worked
on
legacy
codebase
inherited
from
another
vendor
Other
vendor
had
been
slowing
down
month
aBer
month
and
cost
of
development
was
increasing
In
first
iteraKon
this
team
was
able
to
deliver
more
than
other
vendor
was
able
to
in
previous
2
months
ABer
24
iteraKons
this
team
was
10
Kmes
faster
delivery
than1st
iteraKon
Acceptance
Test-­‐Driven
Development
and
ConKnuous
IntegraKon
were
greatest
technical
factors
to
support
team
in
these
results
Can
you
afford
not
to
have
a
“No
Defect”
policy?
41
Tuesday, May 8, 2012

55. Thank
you!
QuesKons
and
Answers
[Time
permiong]
Tuesday, May 8, 2012

56. Chris
Sterling
Co-­‐founder
&
CTO
of
Agile
Advantage
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
InnovaKon
Games®
Trained
Facilitator Email:
chris@agileadvantage.com
Web:
h<p://www.agileadvantage.com
CerKfied
Scrum
Trainer Follow
me
on
TwiTer:
@csterwa
Blog:
h<p://www.ge?ngagile.com
Open
Source
Developer Hashtag
for
presentaKon:
#swdebt
45
Tuesday, May 8, 2012