1 Portfolio Management – Agile How to plan like a VP Highsmith, Ch 12 CSSE579 Session 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.