How Agile methodology can enable more accurate and timely measurement
Not surprisingly, development organizations that operate with a truly Agile methodology, tend to have far more meaningful, quantitative and frequent measurements of their operational performance than those using more classical (i.e. waterfall) methodologies. That isn’t to say that practitioners of waterfall methodology don’t generate a deluge of metrics. It’s just that many of those metrics are not as meaningful or practical as they sound (e.g. percentage complete, number of documents and specifications delivered, bugs per KLOC, etc.).
The reason that Agile methodologies tend to produce more effective and practical measurements, is that the principles of such are actually built into the DNA of Agile methodology practices themselves.
| Agile Methodology ‘DNA’ | Result in the measurement dimension |
| Promotion of a high degree of transparency and openness | Since the basis of the methodology itself is to be as transparent as possible, the degree to which metrics can emerge is enhanced. In short – all development team members are always trying to be very open and clear about where things are at – such that even a subjective ‘feel’ for project progress is more accurate. |
| Planning is a fully integrated activity with daily management and tracking of change built into the methodology at the developer level. | Many implementations of ‘plan based’ methodologies, which often have a disconnected planning cycle from actual development. It is done extensively up front, and project plans are generally ‘owned’ by a project manager. In fact – most times developers do not even refer back to the plan unless forced to by the PM when seeking updates to progress – which again is tracked at the ‘activity’ level rather than ‘working features’ level.In Agile by contrast, while there is absolutely some planning that is done up front, the executable plan is embodied in the actual working documents of the project (iteration plan, release plan, etc.) that are updated by developers as a matter of course of day to day activity. There isn’t an artificial ‘planning update’ overlay – it’s done as part of the development activity with very little overhead. |
| Iterations and adaption to change | Work in Agile is broken up into iterations, which are in simple terms, small segments of requirements, design, construction and test. Rather than ‘mini-waterfalls’ – iterations are actually highly integrated as part of an overall release plan. Features can move back and forth between iterations, guidance is still provided by some degree of up front requirements, architecture and decomposition. It is because of this interaction of iterations, that the participants in an Agile project get very well practiced at not only adapting to change, but knowing concretely how that change will affect other iterations (and the project as a whole). Change is measured at a feature level (and often a ‘task’ level) – and project level change can be measured from the bottom up on a daily basis. |
| Focus on delivering features / stories | The key concept required for effective measurement of productivity is the ‘unit of work’ itself. This unit of work must result in something concrete. While the completeness of a requirement or design can be ‘cut short’ to produce a document – working code cannot be similarly cut short and still pass the more easily measured dimensions of such things like 85% coverage, passing code quality analysis using automated tools like Sonar, and working code (per very specific test case driven requirements). |
There are certainly other aspects of Agile that aid in measurement – the above are intended just to provide a few key examples. It’s also not the intent to completely dissect Agile methodologies with respect to measurement in this whitepaper. The above was intended to just give a feel for how Agile can certainly help the process of measurement.
In the next few posts in this series, we’ll start getting into the nitty gritty of what to measure and how.
