How Agile are you

KPIs for agility

When looking for agile KPIs I get lots of links with charts, tables, and metrics. And those are important to see how a team is performing and as part of conversation starters (maybe what is being charted is not right…). But what can tell us if we are actually “agile” in our approach. Does a smooth burndown chart suggest agility or just a creative scrum master? Do sprints and scrum ceremonies make you agile?

There are 3 things that I found helps us determine if we are acting in an agile fashion or if we are just using agile nomenclature for an essentially non-agile process.

• Certainty about what is being built
• How we handle scope changes
• Resource utilization

Certainty

When we are have an agile mindset there is a constant tug and pull with respect to what it is that we are actually building. We are responding to customer feedback and we have a mindset to embrace change.

If we notice that certainty behaves differently, for example we start with high certainty, then nose dive into low certainty as developers actually dig into requirements and then we establish waves of high certainty as initially questions are resolved which then lead to more issues — then we are not agile. We are setting out to do more than we understand, which means that we have plans that are bigger than the product and the knowledge we have right now. As a result, as developers dig into things, plans unravel, new things have to be thought of, which seem to address the core questions only to reveal even new gaps in understanding.

If certainty is a constant mild ebb and flow, then your team is in an agile space. If your team constantly wrangles with mountains of uncertainty then you are leaning towards a waterfall methodology.

Scope Changes

When we are agile the backlog is constantly being filled and prioritized. As developers we absorb new requirements in a constant and general way. If scope changes balloon and then collapse we have the corollary of the above — where questions lead to re-design, changes the fundamental nature of things, and eventually someone says “no more scope changes” and we accept it.

Resource Utilization

Agile should provide a near 90% constant utilization. 100% means we have no room to stretch, learn, or experiment. Too low below 90% and your developers are probably getting bored. In a waterfall situation you tend to start with high utilization when developers dig into the requirements, then a period of low utilization as scope changes and the resulting questions are being resolved, and then over-utilization to meet the initial deadline.

These are three metrics I noticed that let us know if we are embracing an agile mindset or just an agile vocabulary. What are your thoughts?