1

Portfolio Management – Agile

How to plan like a VPHighsmith, Ch 12

CSSE579Session 6

Part 2

One company’s software product portfolio

2

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

3

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!

4

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.

5

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.

6

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).

7

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.”

8

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.

9

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.

10

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.

11

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.

12

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.

13

An alternate view of investment and risks

• Takes into account risks that grow, too.

14

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?

15

Linear governance, iterative development – interactions

• Highsmith’s Fig 12-4

16

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

17

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.

18

Expansion phase

• Focus on broad capabilities.• Confirm that the project’s scope was well

understood.• Build high-value features.• Drive out remaining risks.

19

Extension phase

• Do more of what we already know what to do.• Not many, if any, surprises.

20

Deployment phase

• Product is put into actual use.• Likely “deploy an incremental piece of the

product.”

21

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?

22

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.

23

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

24

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

25

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.

26

Final thoughts

• Project leaders and customers use the agile triangle to assess project results.

• Executives tend to look at investment and risk profiles.