Viewing entries tagged
metrics dysfunction

QPPE Metrics Model – A Measured Reaction

Comment

QPPE Metrics Model – A Measured Reaction

First of all, it’s been far too long for me writing something about metrics. It’s one of those topics in the agile community that keeps on giving ;-) 

But I’ve been inspired (yet again) by an article that Anthony Crain wrote a while back on the topic. He introduced it as his QPPE Metrics Model, where:

Q – represents Quality,

P – represents Predictability,

P – represents Productivity, and

E – represents Engagement.

You can find the article here –

https://techbeacon.com/how-software-teams-can-measure-anything-qppe-metrics-model

I shared this article with my friend and colleague, Shaun Bradshaw. I’ve known Shaun for the better part of two decades and he’s my go-to guy when it comes to all thing’s metrics related. Here’s his initial reaction to the QPPE post:

Comment

The Agile Project Manager—The ‘Essence’ of Agile Metrics

I’ve been struggling for quite some time figuring out the “essence of” agile metrics. What are good ones versus bad ones? Are there related sets that are relevant and how many are needed? And how much change do we need to make from our traditional metrics thinking towards agile metrics?

One thing I have discovered is that metrics need to be “different” in an agile organization or culture. Traditional measures don’t seem to work within agile teams—as I’ve often seen them to cause dysfunction (more on that later).

Another thought I’ve had is whether they should represent a trailing indicator or a leading indicator? Meaning should we measure the processes (at the beginning or leading edge) or should we more so focus on the results & learning (at the end or from the trailing edge)? I’ll explore this more next.

Leading vs. Trailing Indicators

I think of measuring estimate accuracy (estimate + actual) as a leading indicator. Why is that since you measure actuals at the end of your work?