Skip to main content

Development

Measuring the Performance of Delivery Teams (Part II – Agile)

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Kevin Sheen, Vice President, Global Delivery

Kevin is responsible for Perficient's Global Delivery strategy and execution with teams distributed across the globe in the US, India, China and Mexico. With a background rooted in software development, he has been an Agile evangelist and practitioner for over 20+ years and has been advocating Agile as a way to make global teams successful since Perficient launched it's first global delivery center over 13 years ago. Scrum Certifications: CSP, CSM, CSPO

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram