Ron Jeffries is currently publishing another great series of ‘diary’ articles, this time in which he and Chet Hendrickson tackle a serious project the way they would advise their clients to tackle it. The results are as entertaining and informative as usual. Yesterday I sent Ron a note about the way he accounts for his and Chet’s time on the project; read his reply in Shooting Oneself in the Brain…
Wow – I never expected such an in-depth response! I definitely agree that working full-time on a problem isn’t the most effective way to make progress on it. And as a side thought, I wonder if the extra thinking time is one of the benefits of “slack”; that is, if we have a somewhat smaller load than our capacity, does our subconscious make use of that time to help us be more effective?
In How do you measure up? Dwayne Melancon points out the book Measure of a Leader by Daniels and Daniels. Not directly related to measuring the value of a coach, but not a million miles away either. I wonder what actual measures they propose.
In Agile Atlanta – 4/11 meeting notes John Brothers reports on a discussion of metrics for agile projects. Again, not directly related to coaching, but it always helps to be able to measure team effectiveness along the way.
Do you know of any more discussion, research or case studies into measuring the performance of managers, coaches or businesses?
In The Productivity Metric James Shore adds fresh fuel to the “running tested features” debate. The article is well worth reading, and James concludes:
“There is one way to define output for a programming team that does work. And that’s to look at the impact of the team’s software on the business. You can measure revenue, return on investment, or some other number that reflects business value.”
I whole-heartedly agree with this conclusion, although in my experience there are a couple of hurdles to overcome:
First, the figures may be hard to come by or difficult to compute. This is particularly true of infrastructure software, or tooling that’s used internally to the business. How do you compute the development team’s ROI from the impact they have on an admin clerk’s day-to-day? There will always be the danger of monetising some intermediate measure, and thereby creating a local optimum. (If you have examples of this being solved successfully, please get in touch.)
And second, the development team may feel that the figures are too dependent on other business processes, such as sales or dispatch. Even where the software is the company’s product, the value stream is often not as short or highly tuned as one might wish; and so the developers may not wish to be measured against the whole stream’s effectiveness. In theory, rapid feature development and compelling usability ought to energise the sales team and the market to the point where demand dominates supply; in which case the value/time metric will work well. In practice, the necessary pull is too often absent. (Maybe in that case the metric is still valuable, telling us something about the whole value stream…)