Recently, I had a customer ask me for a way to understand how they were doing on their “agile journey”.

I know there is some debate on maturity models. And I do agree with some of the positions against them – as a business analyst by trade, my answer to a lot of direct questions has always been, “it depends”. And in the case of an agile transformation, that answer couldn’t be more accurate. Agile transformations are complicated and very specific to an organization’s unique environment. What works for one company might not work for the next.  

The cons for maturity models, as I see them, are:

• They imply a “command-and-control” sequence of steps of the agile journey, which seems to be contrary to agility.
• They typically require heavy executive commitment if you are going to formally assess your organization against the levels.
• They imply a “one-size-fits-all” approach to agility.

However, I think it is important for a company, team, or department to be able to gauge their current position (AS IS), where they want to go (TO BE), and also have a view of their progress along the way in their journey. People often need guidance to help determine some of the behaviors they need to target to “be more agile”.

So, in response to my customer’s request, I sat down to put something on paper that outlined options to consider in their agile journey, not a prescribed sequence of events. (And, if my customers ask me for something – odds are high I am going to follow through with their request if I think it would be helpful for them.)

I like Martin Fowler’s take on it: “the true outcome of a maturity model assessment isn’t what level you are but the list of things you need to work on to improve.”

I originally started out by evaluating a few of the publicized maturity models to see if there was one that I would recommend, but I found pros and cons for each of them. I mostly found that business agility and the existence of references to a good business architecture were missing from many of them. So, I set out to put something together that made sense to me, based on a mash-up of my experience as a business analyst, a project manager, and an agilist. I added in the experience of some of my coworkers and clients, and the Agile Manifesto. I wanted to share in case it might be of use to anyone else!

I want to walk through the guide to help you understand how you can best apply it in your world. 

Agile Maturity Level Guide Structure

I thought it was interesting to separate maturity into two aspects: one for the IT Project/Initiative-Specific and one for overall business agility.  They aren’t actually separate, they complement each other. An IT group or project team can ‘boost’ their agility by also working within an organization that is striving to be agile holistically.

Agile Maturity Levels

For a while now, I’ve been working with a good friend and consultant with a large children’s hospital’s HR department. Most of the work we did was to move them to work in a more agile way so they can better meet their customers’ needs (isn’t everyone?). After doing some initial research and analysis to understand their starting point, we outlined specific actions and behaviors that they could adopt to get them to the next level in their adoption. These levels were for the department to Crawl, Walk, Run, and Fly. These terms were chosen because it we were trying to understand the learning to achieve at each agile maturity level, not just to reach some number.  This approach resonated with them so well that I decided to apply it here in a much broader sense.

Standstill (or backwards)

At this agile maturity level, the team either doesn’t know or has rejected the Agile values and principles. The team is often “sluggish”, slow to pivot, and struggles to deliver value quickly.

• IT and business teams do not work well together. Their relationship is antagonistic, and they often blame the other for failed efforts.
• Either project requirements are non-existent, or they are so massive that they are difficult to digest by both the business and IT.
• Leadership is at a Management 1.0 or 2.0 level. It is very command-and-control and hierarchical. People are afraid to make mistakes, so decision-making is very slow. The metrics available are often used for punishment.
• Teams in other business areas compete to get their initiatives done.
• A lot of people don’t like their jobs. They are over-worked, unmotivated, and stressed. There is a lot of infighting.

Crawl  

The team is starting to try one or more agile frameworks in pockets and are seeing some successes. However, it is usually difficult because the teams applying the framework aren’t supported by management and may tend to slip backwards.

• An agile framework, like Scrum, is being practiced within pockets of IT but is being done mechanically, without really applying the Agile principles.
• Teams aren’t applying the practices that enable built-in quality.
• Work-in-progress levels are still too high. This leads to teams struggling to finish their work and people bouncing between projects and being pulled in different directions.

Walk

Management is starting to support agile efforts more as they are seeing successes. Other teams are also seeing success and want to be agile, so some scaling of agile starts.

• Teams are starting to apply a test-first approach, resulting in faster development and higher quality products. They are starting to invest in test automation.
• The discovery of defects is being celebrated. There is a common understanding that this is how we learn and improve.
• Dependencies and risks are managed well.
• Teams are targeting their efforts for reusability.
• The agile frameworks are beginning to be customized to best fit the organization.
• People understand the Agile Principles and are starting to “live them”.

Run

Projects are assigned to small teams delivering a product or service in small chunks that are short-term. Progress towards strategy is constantly evaluated and the organization adjusts accordingly. Teams are thriving.

• The business architecture, strategy, and mission are well-known and shared throughout the organization so that all teams are focused on the goal and there is high reusability on projects.
• Unsuccessful products are rare. However, when they do emerge, they are seen as opportunities to learn.
• The organization has found its own ‘flavor’ of agile that works for their environment. However, they still constantly adjust it as needed.

Fly

The entire organization is thriving; it’s common to hear, “I love working here; I love my job.” Everyone understands and has an innate desire to work towards the goal.

• The entire organization is geared toward delivering continuous value.
• Everyone is seen as valuable, diversity thrives, and everyone sees themselves as equals.
• Metrics are being used strategically to promote continuous improvement.
• Hierarchical boundaries are being broken through servant-leadership. Sometimes it is hard to tell who the boss is.
• Teamwork is thriving as IT and the business are considered “one”.

If you are interested in understanding how your organization fits into this model, or how you need to adjust it specifically to your needs, Netmind can help. We can help you understand your current state, understand the problems you are trying to solve, and then formulate a plan for how to follow your own, best-suited agile journey. That may be following this guide, another industry-standard (like the SAFe Implementation Roadmap), or your own custom model.

— Ali