How (not) to run Agile Programs

Avinash Rao

Scrum Bangalore – June 2015

It’s the dreaded pre-lunch session …

2

Agenda

The Problem Statement The Agile project

TESB, PABHMMD, etc

Measuring Success – Project and Program Chunking the Cone

(i.e., Program Management)

(Actually, the Agile Puritans may have a point … )

The Problem Statement

4

The Cone of Uncertainty is large in the <Current Release>

5

• Since our resource profile is flat, we will lose (are losing) time to waiting (for access, reviews, approvals) and rework. This is using up the project buffer

• How do we make up for this loss, and deal with this ambiguity?

Uncertainty extends into May , but our capacity is flat through 31 July

Applying The Three Rules of Productivity

(or why Agile really works, especially with the –ban … especially offshore)

Beat the ‘Schoolboy Problem’

Capture Early Completes

The One Hour Rule

6

Qualifiers

Applies to a ‘Real World’ problem (though it seemed to fit)

Note about the structure Multi vendor Program Management stayed old-

fashioned – SC, reviews, R&Is …

Not ideal – fat UCs, proxy POs

Prioritized, clean backlog of what is available, skirt the uncertainty

Move fast to deal with the Cone

7

?

Additional insight into the effort - Scrum

8

Lost benefit ofEarly completes!

Additional insight into the effort – Scrum-Ban

9

… and the results were great …

16% improvement in productivity

Team ownership of process

Coach, SMs, Ceremonies in place …

Fail fast, POCs, small Tiger Teams onsite

10

11

We forgot that how fast we go …

… depends on where we are driving

13

Project Measurements

Prioritized backlog

Enabling the team

Velocity, Responsiveness

14

Program Measurements

Review status

Risks, Issues, Mitigation Plan

Budget for a Schedule and Scope

15

Bright Red (a.k.a, Chomp Chomp)

Rework at 66% for Cone items (RIs)

Pressure on teams to JFDI

What’s done is not really done – why on earth would you make those changes?

Tracking to cost and schedule

What the Business really wants … and what the customer IT really wants

16

The lay of the land

Perversely, the Agile approach of chunking kept the Project and Program measurements Green for longer than usual

SC dashboard - pressure to keep Green as much as possible … Risks and Issues list of multiple pages (How are you mitigating these?)

Hit a wall, extending the cone instead of putting pressure early on – mitigating actions, which then resulted in weeks for resolution, extending the cone

17

Program Agile

1. Architectural runway

2. Test a slice e2e ... lining them up is a challenge beyond the Agile team's ability

3. Evolution and emergence will cause the project to run out of money and time in traditional management terms

18

Traditional v/s Agile view of funding

19

Project completion Benefit realization

Measured by size (often the basis for funding), Agile projects show a slower rate of progress because of rework – this rework would have

been funded by CRs on traditional projects

Benefit realization

Questions?

20