April 28, 2015 // By Angela Johnson
We are celebrating the 10 year anniversary of the Agile Manifesto. Even after a decade of “uncovering better ways of developing software,” one of the most common challenges I encounter as an agile coach working with organizations adopting agile is around metrics. If a better way of approaching software development has been embraced, why try to force the old metrics and reporting on these efforts?
In asking dozens of traditional software project managers what metrics they use to manage projects they consistently answer with “percent complete” or project health dashboard colors of “red, yellow, and green.” In asking how they know a project is successful, the answer is unanimously “on time, on budget.”
Magenic Blog: Defining Success Metrics for an Agile Project Methodology But what if we are tracking to the penny on budget and deliver on time, but our customer looks us in the eye and says “I can’t use this; it’s not what I asked for”? Is the project really “green?” Is the project really a “success?”
The Agile Manifesto tells us to value “working software” with the underlying 12 principles explaining further that the goal is to “deliver working software frequently.” In the spirit of transparency, we need to demonstrate this working software to our product owner, stakeholders and customers at regular intervals as the primary measure of the project’s health, inspecting and adapting as necessary.
Velocity is one metric that is based on historical data, and as a result, a number of organizations gravitate towards this metric in adopting agility. As with any metric, however, this number is often used as a reporting mechanism when its intended use is as a planning tool. An agile team’s velocity is a planning metric for the team to use when determining the amount of work that they can realistically commit to for an iteration. Reporting a team’s velocity to the organization does not demonstrate business value, working software, or that the work the team produced during the iteration was accepted by the product owner.
And what about percent complete? We could express percent complete in terms of the number of product backlog items an agile team committed to completing for an iteration versus current progress, but this data is readily available through a burndown chart. The burndown chart shows work remaining in relation to the end of the iteration. If the line is trending in the wrong direction, this forces the “right” conversation early. Are we in jeopardy of not completing the iteration goal? Is there something blocking or impeding the team? Has the team been interrupted? This chart is often misused as a “measuring stick” of how the team is performing when it is intended to provide transparency and to force the “right” conversation as soon as possible.
The intention is for the organization to provide support to the team to reach the iteration goal by addressing the impediment, removing the blocker, responding to newly discovered tasks, etc.
One thing that impresses me about Magenic, is their innovative approach of adopting a customer-focused framework like Agile. Magenic successfully blends new measures of success and metrics with those that are more traditional yet relevant to continuously improve communication with their customers and provide project state reporting.
With the Agile Manifesto to remind us that “working software is the primary measure of progress,” can we examine our traditional reporting metrics if they no longer apply? Can the “project health” colors reflect that we met iteration goals, delivered business value, or are impeded in some way that is preventing us from achieving the end goal of working software? Can the self-motivated team regularly measure their progress towards a collective goal and the commitments they made with the support of organization leaders? Reflecting on 10 years of agility let’s continue to “inspect and adapt” in our adoption of agile; even in our use of metrics and reporting.
Angela Johnson is an agile mentor and coach, scrum master, trainer and project manager with more than 15 years of experience in software development. She's been asked to share her thoughts and expertise on agile via Magenic's blog. http://www.scrumalliance.org/profiles/32158-angela-d-johnson