Agile enters a new age

The Second Age of Agile: measuring success with meaningful Agile metrics

Charlie Ponsonby
© Shutterstock / Rachel Juliet Lerch

The Agile manifesto states: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. Agile itself is currently in a unique position. In this article, Charlie Ponsonby discusses the “second age of Agile”, as agile methodology approaches late-adoption maturity.

As all LOTR fans will know, the Second Age in Middle Earth lasted 3,441 years – from the defeat of Morgoth to the first defeat of Sauron. Lots happened in Middle Earth during the period and many chickens came home to roost (metaphorically speaking).

In many ways, Agile is entering a similar age. It’s been more than 15 years since the Agile Manifesto was conceived and adoption has been very rapid. It is estimated that 88 percent of all US businesses are involved in some form of Agile methodology in some part of their technology operations.

As such, Agile finds itself approaching the top of the “S” of the adoption curve (see below). As with all innovations approaching late-adoption maturity, the honeymoon period is over and businesses working in Agile are under increasing pressure to demonstrate that their Agile transformations are successful and adding real business benefits.


Agile software development methodologies – penetration in businesses globally

The lack of Agile metrics platforms

Technology teams are very familiar with measuring output, performance and quality and are not short of quant data. Surprisingly, however, there are very few BI solutions available that aim to measure the overall effectiveness of Agile software development teams across the full delivery cycle– from ideation to deployment.

SEE ALSO: Effective strategies for monitoring containerized environments

The solutions out today there tend to focus on one element within the overall Agile process – e.g. code quality tools (focused on coding itself), and workflow management plug-ins that look at certain aspects of the development process, yet often exclude pre-development and post-development stages.

Indeed the “Agile metrics platforms” or “Agile BI” sector is so embryonic, that analysts like Gartner do not yet track it. The closest related sector that Gartner analyses is “Enterprise Agile Planning Tools, which, although related, is focused on planning rather than the efficiency and quality of the output.

Fortunately, newer solutions are emerging vying to answer this unmet consumer need. To create a balanced set of Agile metrics that track overall effectiveness, look for new systems that ingest and analyse data from a variety of tools that software development teams use in their everyday work.

What should you measure?

It is reasonable to assume that all Agile transformations broadly aim to deliver against the Agile Manifesto’s number one objective: the early and continuous delivery of value. As the Manifesto states:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.

The Manifesto’s subsequent aims support this guiding principle and can be summarised as:

  • flexibility – actively including changing requirements and involving stakeholders
  • Frequent deployment of working software
  • Self-organising, small and motivated teams working at a sustainable pace
  • Simple, good design
  • Constant self-assessment and self-improvement.

The challenge and key question is how do you measure these objectives and demonstrate that “Agile is working”? This opens up the contentious subject of Agile metrics.

Navigating the politics of Agile metrics

Why are Agile metrics contentious? There are many protagonists within large technology teams. Each has their own distinct views as to:

  • whether measurement (including comparison across teams) is desirable and/or possible
  • which metrics are meaningful at the team level
  • which metrics are meaningful when aggregated across teams and workstreams

This makes selecting Agile metrics extremely important. Unless the process involves the key protagonists (from teams to delivery managers to heads of engineering) the metrics may not be accepted or trusted. In those circumstances, there is little point in collecting metrics, as teams will not drive to improve them and show the desired progress.

Meaningful Agile metrics

This is our take on a meaningful set of metrics for Agile development teams to track and demonstrate improvement over time.

SEE ALSO: Why every developer should use a time tracking tool

As the table shows, some of the metrics are used by the team only and will not be compared across teams. Some can be aggregated across teams in order to give managers an overall view of progress.

Team view Agile metric set


These metrics are by no means definitive and readers will doubtless disagree with some. Since they have shown to be deterministic of outcomes, however, they provide a very useful starting point for development teams in this ‘Second Age of Agile’.



Charlie Ponsonby

Charlie Ponsonby is co-founder of Plandek, a leading Agile metrics BI and Analytics platform for helping large Agile technology teams demonstrably improve their effectiveness. The company works closely with technology teams faced with the challenge of managing complex Agile projects and delivering against the ever-increasing expectations of the business.

Inline Feedbacks
View all comments