CSSE579
Session 6
Part 2
One company’s
software product
portfolio
Portfolio Management – Agile
How to plan like a VP
Highsmith, Ch 12
1
Ch 12 – Governing agile projects
• Portfolio governance
–
–
–
–
–
Investment and risk
Executive-level information requirements
Engineering-level information generation
An enterprise-level governance model
Using the agile governance model
• Portfolio management topics
– Designing an agile portfolio
– Agile methodology “Fit”
• Final thoughts
2
Given that we have to live with various
higher-level management processes…
• What if we could have Agile at higher levels?
– What would it look like?
• People are starting to realize – changing how a
whole organization works could be a good
thing.
– It could be profitable.
• So, we see Lean Management practices
– And they have morning stand-up meetings!
3
They don’t just see Agile as a threat
• How do they learn to live with it?
• And measure how Agile groups are doing?
• And move into Agile deeper, and on a wider scale.
– E.g., how to make “agile project portfolios.”
• In Ch 12, Highsmith takes steps in this direction:
– Portfolio governance,
– Methodological “fit” for projects, and
– “chunking” at a portfolio level.
4
Portfolio governance
• It’s about making investment decisions in an environment
of uncertainty.
• ROI is a function of
– Value produced (inflows of money),
– Costs expended (outflows of money), and
– Time (timing of these flows).
• Typically care about Net Present Value (NPV) or ROI.
• Probability of achieving these also is figured.
• Money and time are not renewable – they disappear when
spent.
• Engineering processes, in contrast, are iterative.
– Agile ones surely are.
5
Iterative vs sequential
• We know how to measure what we’re getting,
at end of each stage, with sequential (left).
– Not so much for iterative (right).
6
Governance vs operations
• In a sequential process, it’s ok to bury the
governance deep in the process.
– E.g., “Configuration management” assesses it at
the end of each phase.
• In iterative engineering processes, this
coupling has to be loosened.
• The answer to, “How do I know things are
going well?” is more often, “You don’t, at the
moment.”
7
Investment and risk
• In software development work, typically some
risks are unknown.
– What’s known can go in planning documents.
– The project will discover the rest in process.
• These are “wicked problems.”
– Production vs exploration projects:
• Production – a known problem and solution.
– Careful planning reduces risks.
• Exploration – a known problem and unknown solution.
– Or some other combination of known / unknown!
– Significant uncertainties may be associated with both.
– E.g., the “grizzly bear repellant” problem of our first class.
8
Explorations, cntd
• For these problems:
– More detailed requirements don’t cut risks.
– Exploration of the problems space does:
•
•
•
•
•
Simulations
Prototypes
Models
Feature builds
Coding spikes
– Action, not planning, reduces risks.
– Iterative, not linear prototypes, uncover the most risk.
9
Funding model for explorations
• Focus on what executives need to carry out
their oversight and fiduciary responsibilities.
• They need to gather info at key intervals, to
make investment decisions.
• Projects become phases with gates.
– At each gate, decision makers need relevant info
about continued funding with acceptable risk.
10
Executive-level information
requirements
• What would executives like from the first
phase?
– Spend little to learn a lot.
– Ideally – actually reduce risks. A lot.
• Then growth in actual product features
– With continued risk reduction.
– May actually have spent 40% but only built 30%.
– With 75% of the architecture built.
11
Advantage of incremental
• At each phase, it produces incremental
product, not just documents.
• Delivery of high-value product features, while
reducing risks, fits executives’ values.
12
An alternate view of investment and
risks
• Takes into account risks that grow, too.
13
Engineering-level information
generation
• Managing projects = buying information?
– But is it the right information?
– At the right price?
– Spending a lot for requirements documents,
versus on working products, not so good…
– “Old school” assumes (implicitly) that completing
a phase reduces most risk –
unlikely!
Worth looking at?
14
Linear governance, iterative
development – interactions
• Highsmith’s Fig 12-4
15
An enterprise-level governance model
• Need to use project phase names that do not
reflect specific activities, like requirements
gathering.
• Should reflect investment and risk mitigation
phases.
• Using the names from  Fig 12-4 
16
Concept phase
• Create and confirm the vision for the product.
• Identify and mitigate risks.
• May contain product, marketing, financial, and
team components.
• For large projects, this is longer than a typical
“Iteration 0.”
• Goal – at the end of this phase, be able
realistically to plan the rest of the project.
• More than a “feasibility phase.”
– Repeat: Actual risk reduction, not just identification.
17
Expansion phase
• Focus on broad capabilities.
• Confirm that the project’s scope was well
understood.
• Build high-value features.
• Drive out remaining risks.
18
Extension phase
• Do more of what we already know what to do.
• Not many, if any, surprises.
19
Deployment phase
• Product is put into actual use.
• Likely “deploy an incremental piece of the
product.”
20
Gates
• “Most organizations spend far too much time
defining phases and processes when time would
be much better spent thinking about decision
gates and the information needed to pass those
gates.”
• Critical decision points.
• Questions for Extension phase, for example:
– Have all the significant risk items (marketing,
technology, financial) been mitigated through the
delivery of working features and other investigations?
– Has the product architecture stabilized?
21
Using the agile governance model
• Options:
– Don’t use it.
– Use the concept phase.
– Use the entire model.
• For small projects, where all teams use the
same agile methods, using iteration 0 and the
standard project control reports may be ok.
22
Portfolio management topics
• What to do regularly, once you have portfolio
governance in place.
• Lowest level – agile project management.
• At portfolio level, you also get:
– Demonstrable results
– Customer feedback
– Better portfolio planning – more realistic, based on
deployed whole or partial products.
– Flexibility.
– Productivity
23
Designing an agile portfolio
• “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.” – Cathleen Benko and
Warren McFarlan
24
Agile methodology “Fit”
• Uncertainty and complexity may determine what
“type” of process should be used.
• Also to be considered:
– Cultural factors.
– Governance and compliance factors.
• More uncertainty  more agile.
• More complexity  more structure.
25
Final thoughts
• Project leaders and customers use the agile
triangle to assess
project results.
• Executives tend to
look at investment
and risk profiles.
26