Grinning by nature, leisurely on a table in a grassy

Agile doesn't work...

I hear it more and more.

When I use root cause analysis to find out what the problem is, it's usually due to a combination of

  1. An Agile implementation that's not very agile.
  2. No metrics in place to measure success or improvements.

Going agile without agile values

Most organisations who ‘go agile’ forget the Agile values:

1️⃣ “Responding to change over following a plan.”
2️⃣ “Working software over comprehensive documentation.”
3️⃣ “Customer collaboration over contract negotiation.”
4️⃣ “Individuals and interactions over processes and tools.”

These agile values apply to how you implement Agile as well.

Don't put the scrum guide, SAFe Consultants or any other process or tools over your team and their interactions.

It means that it is both:

  • a balancing act, ‘do the first thing and don’t forget the second thing.'
  • and continuously improve both the product and the processes you are a part of. (retrospective!)

It means you should write documentation, but it is not your team or task's critical, singular deliverable.

It means you should write good user stories but start with documenting the Who, Why, What, and How and move on from there.

However, like any approach, agile is not a one-size-fits-all solution and may not turn out the way you want it if you ‘forget’ the agile values it is based on while implementing it.

Measuring Agile values

A great way to continuously check how the organisation is doing is to use metrics and KPIs based on the agile manifesto. Let’s go over them one by one:

1️⃣ “Responding to change over following a plan.”

Insight into the feature development balance allows you to react to a change in focus and steer the backlogs and teams when needed. This is how that works:

When working in a sprint (or in the continuous flow of kanban), you must, at some point, know what the ‘type' of work is that your teams are working on. How much time is spent on feature development, and how much is spent on maintenance or non-feature development? Agile Analytics' Sprint Insights feature is a deep learning A.I.-based technology that will measure and report on the balance between Feature Development and non-feature development. It works by categorising (using deep learning) each update to tasks in a project management system like Jira. It will report how much focus was on feature development vs non-feature development. Also, you can see how much time was spent on each of these categories.

2️⃣ “Working software over comprehensive documentation.”

By measuring the SLOs of the ‘working software’, you will have instant and constant feedback about your production state and if the teams are focussing on ‘the right things'.

Using the SRE practice of Error Budgets and the Agile Analytics' unique feature of Software Stock, you can now keep track of the continuous ‘working software’ by measuring SLOs 24/7 and being alerted in real-time when an Error Budget runs out! This gives the teams the empowerment and autonomy to respond to service-level changes that warrant a refocus of the work.

Additionally, by measuring how much software is ‘in stock’, as opposed to delivered to production, you make sure the operation is continuously optimised to provide a constant stream of working software as fast as possible. Measuring this is critical to objectively measure the software organisation's agility: Using ZEN Software’s Agile Analytics Software Stock feature, you will be able to do that!

3️⃣ “Customer collaboration over contract negotiation.”

By working closely together with your customers and being transparent about service level and productivity using the industry-standard DORA Metrics. You will quickly build trust and close collaboration with your customer(s).

Additionally, the DORA Metrics allow you to optimise internally to value the quick response to failed deployments and a cycle time that is no longer than the industry standard.

4️⃣ “Individuals and interactions over processes and tools.”

By measuring the atmosphere on communication platforms like Slack, Teams or Discord, you’ll be able to see if teams are celebrating successes and rewarding good behaviour.

Using Agile Analytics' amazing Kudos Feature, you’ll be able to see using leaderboards who tops the charts and who awarded who with a Kudo.

Does it ‘not work’?

So while some of the teams that utter “Agile does not work” are snowflakes bemoaning how special they perceive themselves to be. Sometimes it is because of a bad implementation that takes the processes too literally. An Implementation of Agile that really ‘does not work’ causes an organisation to (dis)function identically. However, now all the non-agile processes contain agile labels; this is referred to as Agile In Name Only (or label-writer-agile)

When you do not measure the ‘before’ and ‘after’ situation using relevant metrics, it remains a best guess as to how the performance improves. Using our amazing platform Agile Analytics, you’ll be able to measure all the critical aspects based on the Agile Manifesto for your agile software development organisation. You can now objectively measure whether the teams are improving or needing attention.

Increase Engineer Engagement by measuring what matters