Comments on: Agile Metrics

By: Spotlight Interview with Mark Levison | LogiGear Magazine

Spotlight Interview with Mark Levison | LogiGear Magazine — Tue, 30 Aug 2011 18:40:56 +0000

[...] lead to behaviors that optimize for the measure not the delivery of business value. For more see: Agile Metrics and What is a Good Agile [...]

By: Nigel Runnels-Moss

Nigel Runnels-Moss — Wed, 14 Jul 2010 16:20:59 +0000

Martin Fowler was right: it *is* impossible to measure output, and hence productivity. I discovered the reason why when doing research for Symbian on software quality metrics: Kolmogorov-Chaitin-Solomonoff complexity, an analogue to Gödel’s incompleteness theorem that tells us that it is fundamentally impossible to measure the complexity (and hence size) of any computer program over a certain trivial size (see J.P. Lewis 2001).

This little known academic work helps explain why so many software projects fail, and why we find it so hard to estimate software complexity, size, cost etc.

Even Tom DeMarco, who started the whole ‘you cannot control what you cannot measure’ malarkey now admits he was wrong, see http://bit.ly/pRrkd

By: Mark Levison

Mark Levison — Fri, 09 Jul 2010 03:43:18 +0000

From a discussion on LinkedIn:

At the team level I would focus on things they control:
< xx lines per method,
… other simple metrics that help the team produce simpler code and that aren’t trivial to game. Other team measures how long impediments remain in place, how long blocked stories remain blocked, how long retrospective items take to get fixed.

I would measure things that limit the teams ability to produce value and flow.

On the business end, I would ask about getting features into production/deployed/sold – depending on the nature of your industry.

The trick is to find metrics that improve the flow and don’t inhibit it. This isn’t easy. I would find one or two measures for the business, one or two more that the team values and get out of their way.

By: Mark Levison

Mark Levison — Thu, 08 Jul 2010 02:55:49 +0000

Bob – I agree with the point, although even deployed might not be meaningful since the users might not use it. In either case I think most of the value can be found by measuring just beyond your current span of control.

By: Mark Levison

Mark Levison — Thu, 08 Jul 2010 02:54:29 +0000

Thank’s I’ve fixed it.

By: Oli

Oli — Wed, 07 Jul 2010 01:14:35 +0000

Your URL to Martin Fowler’s article is missing /bliki/ in it:
http://www.martinfowler.com/bliki/CannotMeasureProductivity.html

By: Bob Marshall

Bob Marshall — Sat, 03 Jul 2010 14:48:21 +0000

I approve of your modification of Ron’s origin metric – just one word of caution, though: “Purchased” often tells you little more about the value being earned by a feature than does “Tested”. Better to consider “in production” / “in use”, or even better still, take the Systems Thinking (Synergistic) perspective and consider to what extent the feature in use with a given customer actually elevates their constraint and increases the throughput of their “system”.

Cheers

- Bob