How Do You Measure Agile Maturity?

How Do You Measure Agile Maturity? During my interactions with top client leaders whether it is along user story workshops, projects retrospective or simply customer development conversation, I used to always come across one question in common. "We have invested a lots of money and resources to make our company purely Agile. It has been couple of months/years that we have been allocating budgets every year for this agility initiative. We have n

During my interactions with top client leaders whether it is along user story workshops, projects retrospective or simply customer development conversation, I used to always come across one question in common. “We have invested a lots of money and resources to make our company purely Agile. It has been couple of months/years that we have been allocating budgets every year for this agility initiative. We have no idea on how many more years it would take us to become Agile.”

Well! I think that is a valid concern. If I’m a CIO of a company, I wouldn’t put my money, where I have no idea of the progress being made. 

First of all, let me counter the basic assumption of a company being purely Agile. I would certainly treat Agile as an enabler of accomplishing business goals, not just Agile being the end goal by itself. A company with a vision of being purely Agile sometimes may not withstand the costs of upgrading forever. For example, in many organisations it might have started with Scrum and jumped into other frameworks like extreme programming (XP) and later a mix of both (like we do at New Bamboo) or they might look at SAFe and other emerging models.

A company which had been working in Agile way over the past several months, really wanted to understand the realised business benefits from this transformation. However, people with full visibility like an Enterprise Agile coach, very often find that Agile adoption is “unevenly spread” in various parts of the organisation. This lead to the concept of having in an Agile transformation, multiple coach at different point in time in the transformation. I will blog soon about Agile coaching.

The successful approach to adopting Agile acknowledges Agile is not just fad or a quick fix

Second, “how do I know my business goals and track them by deploying Agile?”

In fact, that is very easy and straight forward. Few examples of business goals are; Increase in time to market for product releases, gaining competitive advantage, promote innovation in product development, respond faster to changing business and customer needs and being highly quality conscious. All this is very fact base and very rational, so every business should track these key performance indicators.

So I believe every organisation needs a continuous improvement framework to track the progress of their business goals after deployment of one of the agile frameworks.

I would like to propose here couple of frameworks to measure continuous improvement, one at team level and the other one at enterprise level.

At team level, I like comparative Agility, a free tool (http://www.comparativeagility.com/) . This is the pet framework of Mike Cohn, one of the contributors to the invention of the Scrum software development methodology. The tagline is very catchy “Are you Agile enough. “ I like this one because it will make senior management to understand and remove the bottle necks and help teams improve over a period of time. It also compares a team’s progress within a company to themselves and external agile practitioners.

At an enterprise level, I like Enterprise Balanced Score Card of Dean Leffingwell. He reused the same concepts for building enterprise metrics during transition to SAFe model (Read my blog about Scaling Agile Frameworks). You can find glimpse of those metrics on Dean’s website. This webpage just contain an overview of the metrics, however for detailed implementation of these metrics you have to read his book, “Scaling Software Agility.” This is the best book I recommend to understand the challenges of Scaling agile in a larger organisation.

It’s clear, there is not a one-size-fits-all way to define Agile success. Every organisation is different, every Agile team is different, and every software development project is different. Each organisation has to figure out how to pilot, extend and excel at Agile. Distinctively measure Agile performance within an organisation is paramount from my perspective, a team can find it’s own ways and make the most effective use of team members to meet their commitments. In true empowerment style, ensuring everyone’s full involvement in this rather critical exercise.

The successful approach to adopting Agile acknowledges Agile is not just fad or a quick fix, it is part of an ongoing dialogue of what’s working, what’s not and what are we going to change.