a collaborative approach to the quality in the agile enterprise by jaco viljoen

44

Upload: indigocube

Post on 18-Jul-2015

201 views

Category:

Technology


0 download

TRANSCRIPT

@IndigoCube

/company/indigocube.co.za

LET’S GET SOCIAL!

A Collaborative Approach

to Quality in theAgile Enterprise

Jaco Viljoen | IndigoCube | [email protected]

www.indigocube.co.za | [email protected]

JACO VILJOEN

Principal Consultant

• 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 #1: Collaboration

• Enterprise Challenge #2: Quality

Challenges

Enterprise Challenge #1: Collaboration- Waterfall -

Enterprise Challenge #1: Collaboration- Water-Scrum-Fall -

Enterprise Challenge #1: Collaboration- Water-Scrum-Fall -

Enterprise Challenge #1: Collaboration- Water-Scrum-Fall -

Enterprise Challenge #1: Collaboration- Continuous Delivery -

Enterprise Challenge #1: Collaboration- Continuous Delivery -

Enterprise Challenge #1: Collaboration- Continuous Delivery -

Enterprise Challenge #1: Collaboration- Continuous Delivery -

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

Vision/Solution

• 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

Acceptance Test Driven Developmentfor the Whole Team

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

Continuous Delivery Pipeline43

Continuous Delivery Pipeline

• 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

Continuous Delivery Process

Continuous Delivery Process

Shift user acceptance testing left and automate it

Continuous Delivery Process

Vision of Changes Needed (Was there)

Vision of Changes Needed (Done)

Vision of Changes Needed (To do)

• Whole team approach

• Acceptance test driven development

• Continuous delivery pipeline

Summary