Home › Downloads › Project portfolio management and Agile: bringing the two worlds together
How to integrate an Agile method into project portfolio management, and give leadership the visibility it needs without disrupting the culture and practices of Agile teams.
This article draws on a white paper by Daptiv, a company specialized in project portfolio management systems. It shows how, despite common misconceptions, projects run in Agile mode integrate very well into a project portfolio, provided the specific features of Agile teams are taken into account.
The challenge: integrating portfolio and Agile processes
Many portfolios now include a mix of methods: traditional waterfall, Agile, Six Sigma, or the “Stage-Gate” approach for new product development. Even with the will to adopt Agile, integrating it into a portfolio framework has proven difficult for many organizations.
Three misconceptions about combining portfolio and Agile
Misconception 1: Agile projects do not give leadership enough visibility
Empowering a team does not mean that no progress reporting should reach leadership. The difficulty is to produce those reports without breaking Agile practices: leaders must learn to interpret the status of an Agile team rather than impose incompatible formats.
Misconception 2: Agile projects have no reliable end dates
Agile teams avoid guaranteed dates, given the cone of uncertainty, but an Agile project can provide a forecast end date. “Epics” and “themes” make it possible to estimate work at a high level.
Misconception 3: Agile and traditional practices are incompatible
They differ, but can be combined into an effective framework. Agile practices rarely cover project initiation, whereas traditional practices for cost, communication and risk management are often more mature.
Integrating an Agile methodology into a portfolio framework
Integration is no different from that of a traditional method, with four nuances:
- do not stifle Agile processes with unnecessary reviews and control points; stakeholder meetings should remain the exception;
- measure progress by “story points” delivered and business value, not by hours spent, and adapt health and percentage-complete indicators accordingly;
- assign full-time resources to Agile teams, apart from cross-functional profiles such as architects or database administrators, because part-time work breaks self-organization;
- focus reviews on the state of the product rather than on predetermined milestones.
Measures common to all project types
Five common parameters give leadership visibility whatever the execution mode:
- the forecast end date, updated with recent data: critical path for traditional, delivery plan for Agile;
- percentage complete: task hours for traditional, “story points” delivered for Agile;
- scope changes: change requests, or variation in total “story points”;
- actual and budgeted costs, reported in both cases, with dedicated resources on the Agile side;
- project status: on track, needs attention, or at risk, derived from the measures above.
Brought together in a dashboard, these measures make it possible to quickly identify projects that need attention, whatever the method. The key: calibrate measures across project types, and create a single source of truth for leadership.
Published by NetsFive.