AGILE GOVERNANCE TRICK OR TREAT? 30 th October 2018 Matthew Taylor, IndigoBlue IndigoBlue Part of the Mastek Group
TONIGHT S MENU Agile governance in three parts Concepts Initiation Delivery
What is Agile? IndigoBlue
What is governance? 2 words Do agile projects need to be governed?
DOES AGILE NEED TO BE GOVERNED?
AGILE GOVERNANCE Concepts IndigoBlue Part of the Mastek Group
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
WHY GOVERN? Why govern? Hold the delivery team accountable while delegating responsibility Alignment Engagement Risk 8
WHY GOVERN? [Picture of the Fat Controller, Thomas the Tank Engine] [Picture of HMS Titanic] 9
THEORY X AND THEORY Y IndigoBlue 10
EFFECTIVE GOVERNANCE Accountability and responsibility Trust the team Not just agile 11
ENTER AGILE TYPICAL CHALLENGES Lots of uncertainty Lots of innovation Lots of complexity So how s about 12
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 http://agilemanifesto.org IndigoBlue
AGILE GOVERNANCE 3 KEY PRINCIPLES Collaboration Incremental planning Uncertainty management 14
INVERTING THE IRON TRIANGLE 15
AGILE GOVERNANCE Implicit vs explicit Who s responsible? 16
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
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
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
THE FRUITS OF AGILE GOVERNANCE 20
AGILE GOVERNANCE Initiation IndigoBlue
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
VALUE MAP CUSTOMER EXPERIENCE Gain Creators Gains Products and Services Customer Tasks Pain Relievers Pains After Strategyzer s value proposition canvas
UNCERTAINTY WHAT IS UNCERTAINTY? Known Unknowns (cf risk & change) Business or technical Examples 24
UNCERTAINTY WHAT IS UNCERTAINTY? Known Unknowns Resolution: when and how The Design Plan 25
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
HOW MUCH CAN WE DO? NEED TO ALLOW FOR PROJECT VARIANCE = - Usable Total Capacity Capacity Risk Uncertainty Change Project Variance 27
STORIES Story map and user journeys Initial backlog and calibration Ready to play 28
STORY MAP 29
INCREMENTAL DELIVERY STRATEGY Phased deliveries that generate value Not just MVP! Early testing of uncertainty 30
THE OVER-ARCHING PLAN MORE THAN JUST SOFTWARE 31
Effort DELIVERY PLAN RATE OF WORK AND CAPACITY Estimated Velocity Contingent Velocity Contingent Capacity Requirements Estimated Capacity Requirements Time 32
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
Total Capacity FACTORING IN CONTINGENCY FOR A BACKLOG Committed Scope Contingency Capacity to address Project Variance 34
SUPPORTING A CONTINGENT MODEL WHAT OPTIONS DO WE HAVE? Optional scope Sacrificial stories Contingency Additional resources More Time 35
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
Total Capacity CONTINGENCY INCREMENTAL PLANNING Milestone 1 Milestone 2 First commercial release Contingency Milestone 4 37
Total Capacity Total Capacity CONTINGENCY NEEDS PROTECTING MVP DISASTER Proposed Approved Milestone 1 MVP Milestone 2 First commercial release Contingency Milestone 4 38
TEAM CHARTER Context Mission and Objectives Composition and Roles Stakeholders Iteration Cadence Reporting Resources and Support
THE AGILE BASELINE Design Plan Incremental delivery plan Product Backlog Over-arching plan incl delivery timeline
AGILE GOVERNANCE Delivery IndigoBlue
UNCERTAINTY MANAGEMENT ONGOING RESOLUTION Traditional approach Agile approach Design Build To manage uncertainty Design Build 42
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
AGILE BASELINES Baselines come in a number of forms Story Release Project
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
CHANGE MANAGEMENT Agile embraces change The project plan is a baseline and should be changed under Change Control Scope creep 46
CHANGE MANAGEMENT SCOPE Three levels Story Release Project Ask the question: has the baseline changed? 47
CHANGE MANAGEMENT SOURCES OF CHANGE Four sources Discovery Uncertainty resolution Innovation Strategic Change 48
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
METRICS FOR GOVERNANCE 40 36 Xerxes Squad Throughput 35 30 25 25 27 29 31 33 27 20 17 19 15 10 10 9 13 11 8 13 10 7 5 0 4 3 3 2 2 1 1 0 0 0 79 80 81 82 83 84 85 Sprint Throughput (items) Throughput (stories) Throughput (bugs) Throughput (tech debt) Linear (Throughput (items)) 50
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
Uncertainty needs managing 2014 IndigoBlue Consulting Limited
KEEP IN TOUCH matthew.taylor@indigoblue.co.uk Meetup.com/agile-managers-and-leaders Follow us on LinkedIn and Twitter @IndigoBlueNews IndigoBlue 54