Managing Software Debt - Quality Debt Focus for QASIG Seattle

Managing
So)ware
Debt
Workshop

Tuesday, May 8, 2012

First
Things
First...

@csterwa
#swdebt

2

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

eﬀecKve
management
techniques
InnovaKon
Games®
Trained
Facilitator Email:
chris@agileadvantage.com

Web:
h<p://www.agileadvantage.com
CerKﬁed
Scrum
Trainer Follow
me
on
TwiTer:
@csterwa
Blog:
h<p://www.ge?ngagile.com
Open
Source
Developer Hashtag
for
presentaKon:
#swdebt

3

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
• Conﬁgura=on
Management • Automated
Promo=on
• Design • Advanced
Quality
Metrics

• Pla@orm
Experience Trending
and
Analysis

Asser=ng
Quality Wrap
Up
• Deﬁni=on
of
Done • So)ware
Debt
Management

Strategy
• Test
Automa=on
• The
“No
Defect”
Mindset

4

Managing
So)ware
Debt

Overview
Let
me
tell
you
a
potenKally

familiar
story…


Lack
of
emphasis
on
so'ware
quality
a2ributes

contributes
to
decay


Principle:

No
maTer
what,
the
cost
of

addressing
soBware
debt

increases
with
Kme.


Types
of
So)ware
Debt
Technical,
Quality,

ConﬁguraKon
Management,

Design,
and
Plaorm

Experience


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
diﬀerent
tools
and
approaches
Focusing
on
managing
each
type
of
soBware

debt
simpliﬁes
creaKon
of
an
overall
strategy
that

promotes
holisKc
perspecKve

10

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.
Conﬁgura5on
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


AsserGng
Quality
Teams
must
focus
on
asserKng

sustainable
quality
to
support

future
customer
needs
in
a

Kmely
manner


DeﬁniGon
of
Done
SoBware
developments
assert

what
ﬁnished,
working

soBware
entails
to
support

predictable
delivery
into
the

future


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

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


Case
Study:

Test
AutomaKon
Reduces
Cost

of
Change


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

Introducing
Fit
into
TesKng
Process
ABer
8
iteraKons
team
had
introduced
healthy

amount
of
Fit
ﬁxtures
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

ﬁxtures

Reduced
cost
of
tesKng
each
iteraKon
from

$17,000
to
$7,000

18

The
Agile
Regression
TesKng
Triangle*

*
The
Agile
Triangle
has
been
modiﬁed
from
Mike
Cohn’s
original
version

19

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
modiﬁed
from
Mike
Cohn’s
original
version

19

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
modiﬁed
from
Mike
Cohn’s
original
version

19

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
modiﬁed
from
Mike
Cohn’s
original
version

19

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


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

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
aﬀect?
•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

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
clariﬁcaKon

and
design
through

testable
inputs/
23

Acceptance
Test-‐Driven
Development

24

Release
Management
“If
releases
are
like
giving

birth,
then
you
must
be
doing

something
wrong.”
-‐
Robert

Beneﬁeld


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

The
Power
of
2
Scripts:
Deploy
&
Rollback

27

TradiKonal
Source
Control
Management

28

TradiKonal
Source
Control
Management

Main
Branch

28

TradiKonal
Source
Control
Management

Code
Complete
Version
1 Integrate
for
Branch Version
2

Main
Branch

28

TradiKonal
Source
Control
Management

Code
Complete
Version
1 Integrate
for
Branch Version
2

Debt Main
Branch

Death
March

28

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

Flexible
Source
Control
Management

29

Flexible
Source
Control
Management

Main Branch

29

Flexible
Source
Control
Management

Version 1

Main Branch

29

Flexible
Source
Control
Management

Version 1 Version 2

Main Branch

29

Flexible
Source
Control
Management

Version 1 Version 2

Main Branch

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

29

Scaling
ConKnuous
IntegraKon

End-‐to-‐End
&
Load/Stress

Integrated

Component
Valida5on

Component
Valida5on

30

Automated
PromoKon
to
Environments

31

Advanced
Quality
AsserGons

Using
Automated
Tools
and

Dashboards


ConKnuous
IntegraKon

33

Quality
Dashboard
-‐
Sonar

34

Quality
Dashboard
-‐
Sonar

35

Quality
Dashboard
-‐
Sonar

36

Quality
Dashboard
-‐
Sonar

37

Early
Warning
Signs

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

38

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

The
“No
Defect”
Mindset
“What
he
needs
is
some
way

to
pay
back.
Not
some
way
to

borrow
more.”
-‐-‐
Will
Rogers

39

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
reﬂected

in
the
ﬁnancial
statements.”
hHp://www.infoq.com/presenta=ons/agile-‐quality-‐canary-‐coalmine


Case
Study:
Field
Support
ApplicaKon
2000+
users
access
applica=on
each
day
Applica=on
supports
mul=ple
perspec=ves
and
workﬂows

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


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


Thank
you!
QuesKons
and
Answers
[Time
permiong]


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

eﬀecKve
management
techniques
InnovaKon
Games®
Trained
Facilitator Email:
chris@agileadvantage.com

Web:
h<p://www.agileadvantage.com
CerKﬁed
Scrum
Trainer Follow
me
on
TwiTer:
@csterwa
Blog:
h<p://www.ge?ngagile.com
Open
Source
Developer Hashtag
for
presentaKon:
#swdebt

45

Managing Software Debt - Quality Debt Focus for QASIG Seattle

Managing Software Debt - Quality Debt Focus for QASIG Seattle

More Related Content

What's hot

Similar to Managing Software Debt - Quality Debt Focus for QASIG Seattle

More from Chris Sterling

Recently uploaded

Managing Software Debt - Quality Debt Focus for QASIG Seattle