One of the toughest problems when implementing Agile is that methods for defining, measuring, tracking & reporting work are radically transformed. This makes life hard for your PMO! So how can you make sure they’re are happy with the changes?
- Your PMO have a key job to do – making sure information & decisions continue to flow properly. So the basic goal when migrating to Agile is to achieve equivalence with existing reporting solutions. That way, everyone gets what they need.
- To achieve this you will need to consider (with PMO), what is it PMO really trying to achieve? PMOs can be fixated on regular outputs from projects, functions, etc. But more deeply, the reason they need this is to achieve a regular outcome , not a specific output .
- Such an outcome might be ‘track progress’, for example. But tracking progress isn’t the same as ‘tracking milestones/stage completion’. They’re just evidence or predictors of real
- So what is the Agile equivalent of this level of visibility of & control over real progress? Not milestone completion but story As this reflects delivery of working software, it measures real value , not just a formal metric. So Agile is actually superior to traditional tracking.
- Likewise, if PMO need a metric for predicting future progress, Agile offers velocity – which, like stories completed, is a direct measure of real activity, not an indirect indicator. Again, there can be a more or less straightforward substitution of one number for another.
- NB: This isn’t perfect – really migrating to Agile should be much more radical than simply adjusting numbers – but it’s a start. Agile has to show it can adjust to corporate realities, even when it is challenging these realities profoundly .
Actual vs expected
But… ‘progress’ is more than a matter of asking ‘How much have we done?’ There’s a second question: ‘Is this enough?’ That is, how does actual progress compare with the agreed plan ?
- This is more difficult for Agile, as results are delivered differently. In Agile, change is normal, frequent & accepted. But it’s not generally reported or approved outside the Agile team (e.g., to/by PMO). Change is agreed within the team – not by a formal & extended process involving stakeholders, other authorities, etc..
- So PMO needs not only to accept Agile’s measurement of progress but also to change the way PMO defines & even thinks about
- Everyone needed to approve changes is in the team. So a formal process with multiple outsiders is not needed. In any case, deferred items will typically be delivered soon (next, iteration, etc.). And Agile demonstrably leads to the faster delivery of real value anyway.
- Once this is accepted, the meaning of progress under Agile will be clear. ‘Stories completed’ is the basic unit of progress. Velocity defines the rate of progress. And if needed, release- or even product-level burndown charts can be created & tracked.
- Note that this approach to measurement is very superior to traditional progress metrics. It’s metrics for actual vs expected & for predicting future progress are all based on direct measurement of the real delivery of real value.
- Agile metrics are simpler, more accurate & more powerful than waterfall measurement.
- So outcomes are still fully reported.
- But – outputs are not just different but they need to be interpreted very differently .
The good thing is that this can all be done up front with PMO. After that, there’s no reason for them to resist Agile metrics & measurement.