AGILE GOVERNANCE TRICK OR TREAT?

Transcription

1 AGILE GOVERNANCE TRICK OR TREAT? 30 th October 2018 Matthew Taylor, IndigoBlue IndigoBlue Part of the Mastek Group

2 TONIGHT S MENU Agile governance in three parts Concepts Initiation Delivery

3 What is Agile? IndigoBlue

4 What is governance? 2 words Do agile projects need to be governed?

5 DOES AGILE NEED TO BE GOVERNED?

6 AGILE GOVERNANCE Concepts IndigoBlue Part of the Mastek Group

7 WHAT IS GOVERNANCE? The systems and processes concerned with ensuring the overall direction, supervision and accountability of an organisation. (The Co-op) Measures and mechanisms Management 7

8 WHY GOVERN? Why govern? Hold the delivery team accountable while delegating responsibility Alignment Engagement Risk 8

9 WHY GOVERN? [Picture of the Fat Controller, Thomas the Tank Engine] [Picture of HMS Titanic] 9

10 THEORY X AND THEORY Y IndigoBlue 10

11 EFFECTIVE GOVERNANCE Accountability and responsibility Trust the team Not just agile 11

12 ENTER AGILE TYPICAL CHALLENGES Lots of uncertainty Lots of innovation Lots of complexity So how s about 12

13 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more IndigoBlue

14 AGILE GOVERNANCE 3 KEY PRINCIPLES Collaboration Incremental planning Uncertainty management 14

15 INVERTING THE IRON TRIANGLE 15

16 AGILE GOVERNANCE Implicit vs explicit Who s responsible? 16

17 Uncertainty AGILE GOVERNANCE THE CADENCE IDEAS NEW THINKING NEW THINKING INITIATION Backlog prep Some design Project setup BUILD DESIGN TEST BUILD DESIGN TEST BUILD DESIGN TEST Look Ahead Look Ahead Look Ahead 2 weeks 2 weeks 2 weeks 17

18 AGILE GOVERNANCE THE CADENCE PROJECT INITIATION RELEASE Structured engagement Incremental planning Uncertainty planning Retrospective and Planning Meetings Configuration management Continuous integration Automated build and deployment ITERATION 1 (Sprint) ITERATION 2 ITERATION 3 ITERATION n Team empowerment Organisation Standardised process Test-driven implementation Production Plus quality deliverables MANAGEMENT AND GOVERNANCE Commitment management Forecasting Stakeholder reporting Uncertainty management

19 DESCRIBING DELIVERY GOVERNANCE Iterative incremental Adaptive Visibility e.g. team dashboard, information radiators Active stakeholder participation Early feedback & transparency Light-weight milestones Delegated performance monitoring 19

20 THE FRUITS OF AGILE GOVERNANCE 20

21 AGILE GOVERNANCE Initiation IndigoBlue

22 INITIATION ELEMENTS Project Context Value map, goals & objectives Uncertainties, the Design Plan and initial design Incremental Delivery Strategy Story mapping Product Backlog Test Strategy Over-arching plan Team Charter 22

23 VALUE MAP CUSTOMER EXPERIENCE Gain Creators Gains Products and Services Customer Tasks Pain Relievers Pains After Strategyzer s value proposition canvas

24 UNCERTAINTY WHAT IS UNCERTAINTY? Known Unknowns (cf risk & change) Business or technical Examples 24

25 UNCERTAINTY WHAT IS UNCERTAINTY? Known Unknowns Resolution: when and how The Design Plan 25

26 UNCERTAINTIES We don t have any insight into the specific areas that users feel pain Could perform some targeted User Research We don t know what the minimum data set for collection is Further work in analysis of the existing user journey and the reasons for data collection We don t know all the back end integration points Expand on the existing analysis performed against one of the user qualification routes NFR s are not all collated Collate the existing NFR s and then assign the ownership to someone on the team We don t know what of the collected data is actually Regulatory Data As above in terms of the minimum data set We don t know how much of a requirement the ability to save and come back is We need to collate and refer back the existing analysis of the save and loss data We don t know if Analytics is a requirement given that the existing site does not appear to have any and We do not have a customer experience benchmark against which to measure our future success Evaluate the existing data from survey and analysis to establish if this is fit for purpose

27 HOW MUCH CAN WE DO? NEED TO ALLOW FOR PROJECT VARIANCE = - Usable Total Capacity Capacity Risk Uncertainty Change Project Variance 27

28 STORIES Story map and user journeys Initial backlog and calibration Ready to play 28

29 STORY MAP 29

30 INCREMENTAL DELIVERY STRATEGY Phased deliveries that generate value Not just MVP! Early testing of uncertainty 30

31 THE OVER-ARCHING PLAN MORE THAN JUST SOFTWARE 31

32 Effort DELIVERY PLAN RATE OF WORK AND CAPACITY Estimated Velocity Contingent Velocity Contingent Capacity Requirements Estimated Capacity Requirements Time 32

33 Optimistic Realistic Pessimistic Effort WHEN WILL WE DELIVER? RATE OF WORK AND CAPACITY Estimated Velocity Contingent Velocity Contingent Capacity Requirements Estimated Capacity Requirements Time 33

34 Total Capacity FACTORING IN CONTINGENCY FOR A BACKLOG Committed Scope Contingency Capacity to address Project Variance 34

35 SUPPORTING A CONTINGENT MODEL WHAT OPTIONS DO WE HAVE? Optional scope Sacrificial stories Contingency Additional resources More Time 35

36 FUNCTIONAL CONTINGENCY MINIMUM SUCCESSFUL DELIVERY ~70% of the backlog represents the minimum set of features required to make the project a success FUNCTIONAL CONTINGENCY ~30% of the backlog represents additional features not critical for project success 36

37 Total Capacity CONTINGENCY INCREMENTAL PLANNING Milestone 1 Milestone 2 First commercial release Contingency Milestone 4 37

38 Total Capacity Total Capacity CONTINGENCY NEEDS PROTECTING MVP DISASTER Proposed Approved Milestone 1 MVP Milestone 2 First commercial release Contingency Milestone 4 38

39 TEAM CHARTER Context Mission and Objectives Composition and Roles Stakeholders Iteration Cadence Reporting Resources and Support

40 THE AGILE BASELINE Design Plan Incremental delivery plan Product Backlog Over-arching plan incl delivery timeline

41 AGILE GOVERNANCE Delivery IndigoBlue

42 UNCERTAINTY MANAGEMENT ONGOING RESOLUTION Traditional approach Agile approach Design Build To manage uncertainty Design Build 42

43 Uncertainty UNCERTAINTY MANAGEMENT RESOLVE WHEN APPROPRIATE Assume less and base more on proven knowledge initiation Build/Test Time Develop with a view of reducing/limiting the cost of change Some decisions may well be changed 43

44 AGILE BASELINES Baselines come in a number of forms Story Release Project

45 Planning events Sprint X Sprint X+1 Minor Change New Ideas Significant Change Demand Management Look Ahead Analysis & Design Stream Demand management (Strategic Planning) Accepts new work New work may trigger Analysis & Design stream work to remove uncertainty Prioritises backlog(s) Creates proposed sprint backlog for next development sprint Look Ahead (Tactical Planning) Schedules work on the Analysis and Design stream Prepares stories for play in next sprint Schedules work for stories on the horizon which require larger volumes of preparation Stories may take multiple sprints before they are ready to play

46 CHANGE MANAGEMENT Agile embraces change The project plan is a baseline and should be changed under Change Control Scope creep 46

47 CHANGE MANAGEMENT SCOPE Three levels Story Release Project Ask the question: has the baseline changed? 47

48 CHANGE MANAGEMENT SOURCES OF CHANGE Four sources Discovery Uncertainty resolution Innovation Strategic Change 48

49 METRICS FOR GOVERNANCE Productivity e.g. cycle time, throughput Predictability e.g. forecast vs actuals, burnup, iteration commitment % Time to market: frequency of releases (& deployments) Quality e.g. defect count, support call volumes 49

50 METRICS FOR GOVERNANCE Xerxes Squad Throughput Sprint Throughput (items) Throughput (stories) Throughput (bugs) Throughput (tech debt) Linear (Throughput (items)) 50

51 THE PROJECT PLAN TRACKING PROGRESS We only track completed work If it s 80% done, it s not done Done is defined by the project (code + tests + documentation) Focus on completing stories Stories can be split to show basic and advanced versions 51

52

53 Uncertainty needs managing 2014 IndigoBlue Consulting Limited

54 KEEP IN TOUCH Meetup.com/agile-managers-and-leaders Follow us on LinkedIn and IndigoBlue 54