LET S GET SOCIAL! /company/indigocube.co.za

Transcription

1

2 LET S GET SOCIAL!

3 A Collaborative Approach to Quality in the Agile Enterprise Jaco Viljoen IndigoCube

4 JACO VILJOEN Principal Consultant

5 Agenda Introduction Challenges Vision/Solution Implementation Obstacles faced with implementation Outcome Lessons learned Summary

6 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

7 LEVEL DELIVERY FOCUS 5: Optimizing Hypothesis-driven delivery 4: Quantitatively Managed Release on demand CHARACTERISTICS Teams focus on optimizing cycle time to learn from customers Delivery teams prioritize keeping code trunk deployable over doing new work RESULT Continuous deployment capability enables business innovation / experimentation Release on demand: Software is always in a releasable state. Relea time box is well defined and equa to, or less than, business need 3: Defined Regular releases over a defined period with interim milestone 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-boxed releases (the team sets a release date and manages to it) There is an adaptive delivery process Planned release: Release time box well defined, but duration from id 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

8 Value 4 Documents Va 4 : Documents Working Software System :

9 Challenges Enterprise Challenge #1: Collaboration Enterprise Challenge #2: Quality

10 Enterprise Challenge #1: Collaboration - Waterfall -

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

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

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

14 Enterprise Challenge #1: Collaboration - Continuous Delivery -

15 Enterprise Challenge #1: Collaboration - Continuous Delivery -

16 Enterprise Challenge #1: Collaboration - Continuous Delivery -

17 Enterprise Challenge #1: Collaboration - Continuous Delivery -

18 Quality Enterprise Challenge #2: Quality - Waterfall - Product v1.0 Product v2.0 Acceptable level of quality in Production DEV makes changes Bug fixing Testing Regression... Underlying assumption: Capacity matches demand No surprises Time

19 Quality Technical Debt Enterprise Challenge #2: Quality - Waterfall - Product v1.0 Product v2.0 Acceptable level of quality in Production Product v2.0 Not enough time for fixing the quality Too many changes to fix up in time provided Time

20 Quality Technical Debt Enterprise Challenge #2: Quality - Water-Scrum-Fall - Product v1.0 Product v2.0 Acceptable level of quality in Production Product v2.0 Time Traditional practices fail if timeline is too short The most difficult challenges when adopting agile testing approaches - Agile Testing Survey % 37% Getting all testing done in the current iteration/sprint Adopting test-driven development (TDD) approaches

21 Technical Debt Quality Technical Debt Enterprise Challenge #2: Quality - Water-Scrum-Fall - Product v1.0 Product v3.0 Acceptable level of quality in Production Product v2.0 Product v3.0 Technical Debt grows Time Time

22 Quality Enterprise Challenge #2: Quality - Continuous Delivery - Product v1.0 Product v2.0 Acceptable level of quality in Production Team collaborate around changes Team collaborate around changes Team collaborate around changes Team collaborate around changes Time

23 Quality Enterprise Challenge #2: Quality - Continuous Delivery - Product v1.0 Product v2.0 Acceptable level of quality in Production Team collaborate around changes Team collaborate around changes Team collaborate around changes Team collaborate around changes Time

24 Quality Enterprise Challenge #2: Quality - Continuous Delivery - Product v1.0 Product v2.0 Product v2.0 Acceptable level of quality in Production Team collaborate around changes Team collaborate around changes Team collaborate around changes Time

25 Vision/Solution

26 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

27 Acceptance Test Driven Development for the Whole Team

28 Define Build Test Define Build Test Define Build Test LEVEL DELIVERY FOCUS 5: Optimizing Hypothesis-driven delivery 4: Quantitatively Managed Release on demand 3: Defined Regular releases over a defined period with interim milestone builds Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprin D B T D B T D B T D B T D B T D B T D B T D B T D B T Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprin 2: Managed Time-boxed releases (the team sets a release date and manages to it) Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprin Define Build Test Define Build Test Define Build Tes 1: Initial A few smart people performing heroics Define Build Test Define Build Test

29 Continuous Delivery Pipeline43

30 Continuous Delivery Pipeline

31

32 Implementation From Water-Scrum-Fall to Continuous Delivery Strategy to minimise impact of necessary change

33 LEVEL DELIVERY FOCUS 5: Optimizing Hypothesis-driven delivery 4: Quantitatively Managed Release on demand CHARACTERISTICS Teams focus on optimizing cycle time to learn from customers Delivery teams prioritize keeping code trunk deployable over doing new work RESULT Continuous deployment capability enables business innovation / experimentation Release on demand: Software i always in a releasable state. Re time box is well defined and eq to, or less than, business need 3: Defined Regular releases over a defined period with interim milestone builds Teams build quality into release process Regular release cadence: Relea time box is well defined, but duration from idea inception to production release is greater th business need 2: Managed Time-boxed releases (the team sets a release date and manages to it) There is an adaptive delivery process Planned release: Release time b well defined, but duration from inception to production release greater than business need 1: Initial A few smart people performing heroics There is an ad hoc release delivery process Ad hoc deployments

34 Continuous Delivery Process

35 Continuous Delivery Process

36 Shift user acceptance testing left and automate it

37 Continuous Delivery Process

38

39 Vision of Changes Needed (Was there)

40 Vision of Changes Needed (Done)

41 Vision of Changes Needed (To do)

42 Summary Whole team approach Acceptance test driven development Continuous delivery pipeline

43

44