a collaborative approach to the quality in the agile enterprise by jaco viljoen
TRANSCRIPT
A Collaborative Approach
to Quality in theAgile Enterprise
Jaco Viljoen | IndigoCube | [email protected]
www.indigocube.co.za | [email protected]
• Introduction
• Challenges
• Vision/Solution
• Implementation
Obstacles faced with implementation
Outcome
Lessons learned
• Summary
Agenda
• Systems Thinking 101 The structure of a system determines the behaviour
Pervasive problems are caused by many interacting agents leading to emergent properties
Nobody is to blame
• 3 Types of Systems in Agile Enterprises Waterfall
Water-Scrum-Fall
Continuous Delivery
Introduction
LEVEL DELIVERY
FOCUS
CHARACTERISTICS RESULT
5: Optimizing Hypothesis-drivendelivery
Teams focus on optimizing cycle time to learn from customers
Continuous deployment
capability enables business
innovation / experimentation
4:
Quantitatively
Managed
Release on demand Delivery teams prioritize keeping code trunk deployable over doing new work
Release on demand: Software is always in a releasable state. Release time box is well defined and equal to, or less than, business need
3: Defined Regular releasesover a definedperiod with interimmilestone builds
Teams build quality into release process
Regular release cadence: Release time box is well defined, but duration from idea inception to production release is greater than business need
2: Managed Time-boxedreleases (the teamsets a release date and manages to it)
There is an adaptive delivery process
Planned release: Release time box is well defined, but duration from idea inception to production release is greater than business need
1: Initial A few smart people performing heroics
There is an ad hoc release delivery process
Ad hoc deployments
Value
4 :Documents Working Software System Value
4 444 :
Documents Documents Unverified Code Software Value
Value
4
Documents
Enterprise Challenge #2: Quality- Waterfall -
Product v2.0
Qualit
y
Time
Product v1.0 Acceptable level of quality in Production
DEV makes
changes…
Bug fixing…
Testing…
Regression...Underlying assumption:• Capacity matches
demand• No surprises
Enterprise Challenge #2: Quality- Waterfall -
Product v2.0
Qualit
y
Time
Acceptable level of quality in Production
Too many changes to fix up in time provided
Product v2.0
Product v1.0
Not enough time for fixing the quality
Te
ch
nic
al
Debt
Enterprise Challenge #2: Quality - Water-Scrum-Fall -
Qualit
y
Time
Acceptable level of quality in Production
Te
ch
nic
al
De
bt
Product v2.0Product v1.0
Product v2.0
Traditional practices fail if timeline is too short
50%Getting all testing done in the current iteration/sprint
37%Adopting test-driven development (TDD) approaches
The most difficult challenges when adopting agile testing approaches - Agile Testing Survey 2012
TimeTe
ch
nic
al D
eb
t
Qu
ality
Time
Acceptable level of quality in ProductionProduct
v3.0
Product v3.0
Te
ch
nic
al
De
bt
Technical Debt grows…
Product v2.0
Product v1.0
Enterprise Challenge #2: Quality- Water-Scrum-Fall -
Enterprise Challenge #2: Quality- Continuous Delivery -
Qualit
y
Time
Product v1.0Acceptable level of quality in Production
Team collaborate around changes…
Product v2.0
Team collaborate around changes…
Team collaborate around changes…
Team collaborate around changes…
Enterprise Challenge #2: Quality- Continuous Delivery -
Qualit
y
Time
Product v1.0Acceptable level of quality in Production
Team collaborate around changes…
Team collaborate around changes…
Team collaborate around changes…
Team collaborate around changes…
Product v2.0
Enterprise Challenge #2: Quality- Continuous Delivery -
Qu
alit
y
Time
Product v1.0Acceptable level of quality in Production
Team collaborate around changes…
Product v2.0
Team collaborate around changes…
Team collaborate around changes…
Product v2.0
• Shift user acceptance testing left
• Prevent defects
• Collaborate around quality
• Automate acceptance and regression testing
• Build a parallel “system that tests the system”
Vision/Solution
LEVEL DELIVERY
FOCUS
5: Optimizing Hypothesis-drivendelivery
4:
Quantitatively
Managed
Release on demand
3: Defined Regular releasesover a definedperiod with interimmilestone builds
2: Managed Time-boxedreleases (the teamsets a release date and manages to it)
1: Initial A few smart people performing heroics
D D DB B BT T T
D D DB B BT T T
D D DB B BT T T
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
De
fin
e
De
fin
e
De
fin
e
Build
Build
Build
Test
Te
st
Te
st
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Define Build Test
BuildDefine Test
Define Build Test
Define Build Test
BuildDefine Test
Define Build Test
• From “Water-Scrum-Fall” to “Continuous Delivery”
• Strategy to minimise impact of necessary change
Implementation
LEVEL DELIVERY
FOCUS
CHARACTERISTICS RESULT
5: Optimizing Hypothesis-drivendelivery
Teams focus on optimizing cycle time to learn from customers
Continuous deployment
capability enables business
innovation / experimentation
4:
Quantitatively
Managed
Release on demand Delivery teams prioritize keeping code trunk deployable over doing new work
Release on demand: Software is always in a releasable state. Release time box is well defined and equal to, or less than, business need
3: Defined Regular releasesover a definedperiod with interimmilestone builds
Teams build quality into release process
Regular release cadence: Release time box is well defined, but duration from idea inception to production release is greater than business need
2: Managed Time-boxedreleases (the teamsets a release date and manages to it)
There is an adaptive delivery process
Planned release: Release time box is well defined, but duration from idea inception to production release is greater than business need
1: Initial A few smart people performing heroics
There is an ad hoc release delivery process
Ad hoc deployments