Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
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.