We often talk about agile in terms of development of new systems, sometimes called greenfield projects. These scenarios present us with a “cleaner” version of agile. But Jim Peers is asking the question: What about agile methodologies when applied to the maintenance of a mature product? A mature product brings into play many more variables—addition or upgrading of features, addressing technical debt, bug fixing, security and accessibility concerns, and working with an aging codebase. And each variable brings its own challenges. By necessity, these scenarios can force us to adapt our work model, moving away from a pure agile workflow to find the right blend. Jim describes some of his experiences—both good and bad—as a tester dealing with the maintenance of a mature product in an agile environment. Join Jim for some important takeaways—Your product is going to live longer than you think. Technical debt will come back to haunt you within a year. And yes, you do have to implement that security fix.

1.
W16
Agile
Testing
5/10/17
15:00
When
the
System
Creaks:
Lessons
Learned
in
Agile
Maintenance
Presented
by:
Jim
Peers
PQA
Testing
Brought
to
you
by:
350
Corporate
Way,
Suite
400,
Orange
Park,
FL
32073
888-­‐-­‐-­‐268-­‐-­‐-­‐8770
·∙·∙
904-­‐-­‐-­‐278-­‐-­‐-­‐0524
-­‐
info@techwell.com
-­‐
http://www.starwest.techwell.com/

2.
Jim
Peers
A
QA
practitioner
with
PQA
Testing,
Jim
Peers
has
more
than
sixteen
years
of
experience
in
software
development
and
testing
in
multiple
industry
verticals.
After
working
in
the
scientific
research
realm
for
a
number
of
years,
Jim
moved
into
software
development,
holding
roles
as
tester,
test
architect,
developer,
team
lead,
project
manager,
and
product
manager.
A
trusted
technical
advisor
to
clients,
Jim
creates
test
strategies,
and
mentors
and
assists
testers
on
multiple
projects.

3. 1
When the System Creaks
Lessons
Learned
in
Agile
Maintenance
Jim
Peers

4. 2
© PQA Testing Ltd.
About Me
u QA
Prac55oner
at
PQA
Tes5ng
in
Vancouver
u I
have
been:
u Developer
u Test
architect
u Team
lead
u Project
Manager
u Product
Manager

5. 3
© PQA Testing Ltd.
Agile in an Ideal World
u Greenfield
–
no
maintenance
u Automated
tests

6. 4
© PQA Testing Ltd.
Mature Product Problems
u Tech
debt
u Lack
of
con5nuity
of
team
knowledge
u Quality
not
built
in
u LiHle
(if
any)
automa5on

7. 5
© PQA Testing Ltd.
Mature Products can be Hard to Test
u Code
is
rarely
removed
u Increased
complexity

8. 6
© PQA Testing Ltd.
Waiting for the Next Big Thing
u Where
is
that
new
version
anyway?
u Your
product
is
longer-­‐lived
than
you
expect

9. 7
© PQA Testing Ltd.
Technical Debt
u Example:
Upgrading
web
elements
-­‐-­‐
>1
person-­‐year
of
effort
u Whole
team,
including
the
business,
needs
to
understand
the
effects
u Changing
from
Flash
to
HTML5
controls

10. 8
© PQA Testing Ltd.
Security
u Increasingly
complex
u Customers
demand
it
u Modern
frameworks
have
more
built-­‐in
security

11. 9
© PQA Testing Ltd.
Localization
u Changes
to
strings
can
be
small
or
wholesale
u Example:
more
formal
level
of
address
desired

12. 10
© PQA Testing Ltd.
Data
u Changing
data
structures
is
high
risk
u Some5mes
unavoidable

13. 11
© PQA Testing Ltd.
About Those Customers…
u Might
need
to
do
a
fix
or
create
a
new
feature
to
retain
u Compe5ng
agendas

14. 12
© PQA Testing Ltd.
Scheduling
u Need
to
be
flexible
u Sprinkle
bug
fixes,
security
fixes
in
u Build
in
slack
to
accommodate
urgent
fixes
u Fixes
may
take
several
sprints

15. 13
© PQA Testing Ltd.
Root Cause Analysis
u Hold
a
session
a^er
any
cri5cal
bug
fix
u Use
the
5
Whys
u Not
about
blaming
u Output:
ac5ons,
people
assigned,
5meline

16. 14
© PQA Testing Ltd.
Tester Skillset
u Good
to
have
senior
people
on
legacy
products
u Good
product
knowledge
a
plus
u Code
literacy
u Release
management
u Communica5on

17. 15
© PQA Testing Ltd.
Code Review
u Important
for
testers
to
be
involved
u Think
about
risk,
regression
u Analysis
takes
more
focus
u Small
changes
may
have
big
implica5ons
u Issues
cannot
escape
into
the
wild

18. 16
© PQA Testing Ltd.
Automation
u Anything
is
beHer
than
nothing
u Bugs
tend
to
cluster,
so
building
in
regression
tests
can
pay
off
u If
no
unit
tests
for
an
area
of
code
being
fixed,
add
them

19. 17
© PQA Testing Ltd.
Add Logging
u A
good
5me
to
add
if
there
isn’t
any
u Helps
with
testability

20. 18
© PQA Testing Ltd.
Feature Flags
u Cau5on:
may
cause
fragility
u Recommend
removing
them
once
fully
in
use
u Good
to
know
which
toggles
are
on
–
build
a
system
to
report
config

21. 19
© PQA Testing Ltd.
Team Morale
u Good
to
move
people
on/off
maintenance
(unless
they
really
love
it!)
u Occasionally
crazy
hours
-­‐>
burnout
possibili5es

22. 20
© PQA Testing Ltd.
Retrospectives
u Make
sure
they
are
produc5ve
u If
people
are
just
going
through
the
mo5ons,
consider
only
having
them
when
needed

23. 21
© PQA Testing Ltd.
Summary
u Flexibility
is
key
u Add
automa5on
where
you
can
u Count
on
the
product
living
longer
than
you
expect

24. 22
© PQA Testing Ltd.