Agile Project Management

Jim Highsmith

Chapter 12

Governing Agile Projects

Executives need to understand…

“How to move from agile projects to agile

organizations?”

• How to measure success?

• How iterative development can be managed alongside

traditional life cycle projects?

“Portfolio Governance”

How executives monitor projects within the context of their

entire project portfolio.

Portfolio Governance

Two concerns: Investment and Risk

Expected “return on investment” (ROI)?

Depends on expected revenue (inflow)

Depends on costs expended (outflow)

Depends on the timing of inflows and outflows

What is he projected value or ROI?

What is the probability that this return can be achieved?

“The critical issues for organizations, then, is bridging this

seeming gap between linear investment decisions and

iterative/agile product development.

The solution is separating governance from operations and then

loosely coupling them – abandoning the tight coupling that led

to the trouble in the first place.”

Operational Delivery

You want to assemble the best set of methodologies, processes, practices, and people to deliver results.

The approach should be matched to project type.

Development balances opportunity and risk.

Two general types of projects:

Production

characterized by a known problem and a known solution

“careful planning can reduce most of the risk

Exploration

characterized by unknowns

unknown problem and unknown solution

known problem and unknown solution

unknown problem and known solution

“For exploration projects, …

… specifying detailed requirements won’t reduce

serious risks.

Only exploration into the problem space reduces these

risks.

Exploration may take the form of simulations, models,

prototypes, engineering breadboards, feature builds, or

in some cases scientific or engineering investigations.

For these types of risks, months of planning and product

specifying contribute mightily to costs, but little to

risk.”

Proof on Concept

To better understand… the project.

Build prototypes or simulations…

What’s needed:

• Define an information gathering strategy bases on key risk

areas

• Decide which activities to fund based on mitigating those

risks as early and with as little cost as possible

Proceeding with a waterfall type model might not reveal

critical (and costly) issues until late in the development.

Managing Product Life Cycle Investment & Risk (Fig. 12-1)

Pre-Project Phase 1 Phase 2 Phase 3

Risk 100 40 20 5

Investment 0 20 40 95

Architecture 0 25 75 100

Features Delivered 0 10 30 100

0

20

40

60

80

100

120

Pre-Project Phase 1 Phase 2 Phase 3

Risk

Investment

Architecture

Features Delivered

Relative

Performance or

Percentage

Achieved

Phases…

Pre-Project

Spend as little money as possible to gain understanding of the project’s

feasibility

Phase 1

From hypothetical graph, the executive goal of reducing risk from 100 to

40% with 20% of the cost expended, 25% of the architecture defined, and

10% of the actual product features build, tested and reviewed by the

product team

Phase 2

More progress… risk factor down to 20%, 75% of architecture in place…

Phase 3

The product is completed deployed

“Incremental funding model”

… executives have the ability to cancel a project at the end of any phase.

Traditional Waterfall Phase-Gate Model (Fig. 12-2)

CONCEPT

Phase

REQUIREMENTS

Phase

DESIGN

Phase

DEVELOP

Phase

TEST

Phase

DEPLOY

Phase

Output/Input

Output/Input

Output/Input

Output/Input

Output/Input

Reqts

Gate

Design

Gate

Develop

Gate

Test

Gate

Deploy

Gate

Output

No Go

No Go

No Go

No Go

No Go

Go

Go

Go

Go

Go

The Waterfall approach

assumes that completing

the “system requirements”

phase reduces the most risk

an unlikely scenario for

most projects

Phase Gates

The Waterfall approach

assumes that completing

the “system requirements”

phase reduces the most risk

an unlikely scenario for

most projects

Phases

At the end of each phase a

“Go” or “No Go” decision

is made

Product

Vision

Release Plan

Project Scope

and Boundaries

Envision Cycle Explore Cycle

Review and Adapt Develop

Iteration Plan

Concept

Gate

Expansion

Gate

Extension

Gate

Deploy

Gate

Governance

Operational

Delivery

Concept Expansion Extension Deploy

Connecting a Linear Governance Model with an Iterative Development Model Fig. 12-3

Multiple Iterations within Each Phase (Fig. 12-4)

Envision Explore Explore

Deploy

Envision Explore Explore Envision Explore Explore

Envision Explore Explore Envision Explore Explore Envision Explore Explore

Envision Explore Explore

Plan Deploy Deploy

Deploy

“Agile projects (with iterative Envision and Explore cycles) produce exactly what

executives are looking for to make funding decisions.”

Enterprise-Level Governance Model

Phases

Concept Phase (proof of concept)

to create and confirm the vision for the product

to identify and mitigate risk

(a mini project)

Expansion Phase … expand Concept Phase work

Expect to complete the project with few surprises

Extension Phase … continue with work

Deployment Phase … product is “in use”

Gates

Critical points at which time decisions are made as to

whether or not to continue.

“Most organizations spend far too much time defining

phases and processes when the time would be much

better spent thinking about decision gates and the

information needed to pass those gates.”

Expansion to Extension

Questions:

Have all significant risk items been mitigated through delivery of working features and other investigations?

Has the product architecture stabilized?

And:

To what extent have the highest risk items been mitigated through the development of architectural spikes, delivery of working features, … etc.

Has the work on a skeleton architecture and any development spikes convinced us that the project is technically feasible and will operate within required performance specifications?

Can the Expansion phase be estimated with a reasonable degree of confidence in having a releasable, quality product?

Are the estimates for the entire project still within its constraints?

Portfolio Management Topics

Designing an Agile Portfolio… mirrors the change to

PM (small chunks, short iterations).

Project Management benefits:

– Demonstrable results – short iterations with stories

developed, implemented, tested, and accepted

– Customer feedback – end of iteration review of stories by

customers and product managers

– Better release planning – more realistic being based on

continuously evaluating actual results

– Flexibility – end of iteration process helps steer the project

toward changing business goals & higher valued stories

– Productivity – through constant negotiation at every level,

features are both eliminated and pared down.

Agile practices provide Portfolio level benefits

• Demonstrable results – every iteration of so products or pieces of products are deployable … developed, implemented, tested & accepted

• Customer feedback – end of iteration reviews by product managers provide feedback… allowing executives to view progress in terms of working products

• Better portfolio planning – based on deployed whole or partial products

• Flexibilitiy – portfolios can be steered toward business goals and higher-value projects because changes are easy to incorporate… working products provide accumulated value prior to release

• Productivity – hidden improvement as a result of work not done… eliminated or pared down while value delivered remains high

‘Chunking’

“Simply put, Project Chunking involves taking larger

projects and breaking them down into smaller bundles

that reduce risk, realize benefits sooner, and increase

flexibility by providing more choice points.”

Chunking helps ‘respond to uncertainty and velocity by

building choice points and delivering value more

quickly;.

Benko and McFarlan

What project FIT an Agile Profile?

Three elements in determining methodology FIT:

1. Project factors (complexity and uncertainty)

2. Cultural factors

3. Governance and compliance factors

Project Factors

Complexity

Team size, team distribution, mission criticality, domain knowledge gaps

Uncertainty

Market uncertainty, technical uncertainty, project duration

“Managing increasing uncertainty is best accomplished by Agile’s flexible

practices, whereas managing complexity requires additional structure.

The most difficult projects are those that have high uncertainty, requiring greater

agility, and high complexity that requires additional structure.

Finding project leaders who can handle both agility and structure is a challenge.”

What project FIT an Agile Profile?

Three elements in determining methodology FIT:

1. Project factors (complexity and uncertainty)

2. Cultural factors

3. Governance and compliance factors

Culture Factors

… agile, flexible, collaborative

Ad hoc, low formality, flexible … however is not ideal.

Will the Agile fit the current culture?

The view from “above” that merely by hitting the “Agile” button will be

sufficient to transform the culture.

What project FIT an Agile Profile?

Three elements in determining methodology FIT:

1. Project factors (complexity and uncertainty)

2. Cultural factors

3. Governance and compliance factors

Governance and compliance factors - overhead

A mistake to allow governance and compliance factors drive the

development process rather than fitting the development process and then

adding practices to deal with compliance issues.

Engineering (development) practices deliver customer value… compliance

and governance processes add cost (the overhead).

Assessing the companies fitness (using the FIT factors) should

inform the decision as to how affect any given methodology

might be.