« In Praise of Slowness | Main | Outsourcing as Social Transformation »
September 29, 2005
"Agile Metrics" at SD Best Practices Conference - Boston
Just returned from Boston where Joshua Kerievsky and I gave a talk entitled "Agile Metrics: Keeping Deadlines from Killing Your Projects and Ruining Your Life."
A most lively reaction came from the audience of 100+ attendees, especially when I commented that "Agile Metrics" seemed an odd oxymoron, akin to terms like "Homeland Security", "Central Intelligence", or "Federal Emergency Management." (Couldn't resist...) But seriously, what we mean by the term Agile Metrics is actually two-fold: The first being about how to measure quickly and reliably (which you can do on your own) and the second being about gaining measurement insights into the “before and after” (think ROI), of implementing an Agile approach.
Joshua began by talking about the void in the industry when it came to productivity metrics on XP projects. To some extent, he even laid the blame at the steps of the Agile community for the absence of measures that senior managers would believe. ("Metrics? We don't need no stinking metrics.") He commented that many of the proponents of XP sought to go it alone, to their eventual chagrin, and didn't see how to collaborate with those in the field of metrics to understand how XP projects were behaving versus the status quo, and make a compelling enough case to senior decision makers who would ultimately hold the purse strings on approving an Agile initiative.
Kerievsky then went on to talk about his excitement about the prospect of synthesizing what we are able to accomplish with modern benchmarking practices that I’ve written about over the last 10+ years, and how this collaboration yielded powerful results that were clear and concise when it came to schedule and defect patterns on XP projects.
My portion of the talk gave insight into how we can quickly and reliably get a diagnostic reading on the outcomes for any development paradigm, and what we saw when we measured "before and after" an Industrial XP implementation, at a major medical devices company.
(Rather than repeat the findings described in an earlier post, you can view the results in this blogosphere. See the entry on "Reassessing XP.")
Ironically, one thing I believe we conveyed in this session was the debunking of some myths about Agile, and about software measurement.
Myth #1: Agile is another term for "License to Hack". I've heard critics of XP and other Agile methods dismiss it as undisciplined. But, truth be told, what seems like programmers running amuck is actually one of the most disciplined executions of software invention that one can imagine. It seems to me that, done properly, something like Industrial XP is more rigorous than most organizations that claim a high degree of process maturity. Tim Lister says they’re at least the equivalent of CMM Level 3.
Myth #2: Metrics is a Frederick Taylor inspired, “heavy methodology” that slows things down by detracting from real work. Yet ironically, companies that know how to use measures well, quickly gain insights into their current IT capacity, can reliably generate project scenarios using advanced modeling techniques in days rather than weeks, and are more able to respond to changes on a project, from a management perspective.
So to sum it up, we’re discovering that Agile can be highly disciplined, and measurement can be about fast and accurate knowledge about software productivity, along with accelerated decision making. In my opinion, we've only just scratched the surface on this subject.
Posted by Mike at September 29, 2005 03:15 PM
Listed below are links to weblogs that reference "Agile Metrics" at SD Best Practices Conference - Boston:
Comments
Mike, Recently after hearing you speak, someone raised the issue about the importance of having the developer provide their own estimate so, "they have some skin in the game."
This concept seems similar to the XP notion that the developers are the best ones to supply their own estimates. While the belief might be that this is a more benign approach since it keeps management from forcing estimates on the development team, it is a flawed approach to project management.
Having developers supply estimates is less accurate than basing estimates on historical precidence. Instead, ask the developer to access more knowable things that can be used to adjust the historical estimate such as the developers skill level or familiarity with the target technology.
Asking the developer to supply an estimate is just inviting the super-achiever to over-commit and then forcing him/her into heroics to deliver on that commitment while failing to account for all the other components in the development process.
Posted by: Tim Hadfield at November 2, 2005 10:21 PM
Tim, excellent point. I agree with you about this risk. Many of us in IT have an unconscious bias that works its way into our work and time commitments, which comes back to haunt.
In a talk I gave yesterday (to 400 people no less) on this topic, I closed with a quote that basically encouraged people to use historical patterns not only to show others evidence on deadline/scope negotiations, but to *show themselves* as well, as a way of implementing a self-imposed checks/balances practice. It's the only way to objectively assess if we're overcommitting. It's in our own self-interest to find this out.
Jim Highsmith of Cutter also had some good things to say about estimating in an agile XP environment. I refer to his ideas in this article http://www.qsma.com/html/CorporateAlzheimers.htm.
Thanks again for your insights.
Posted by: Michael Mah at November 3, 2005 04:47 PM
