My (dodgy) agile maturity model

Recently, some people asked me if I used an agile maturity model.

I guess this should not come as a surprise because agile has gone mainstream.  Organisations are now struggling with how to create a consistent and effective approach to implementing agile practices.

A maturity model is a good way of assessing whether a team is using bad practices, good practices or excellent practices.  It moves from “adhoc” to “do it OK” to “repeatable and reliable”  and finally to “awesome and continually improving.”

I am not against doing this, but I do see an issue with two statements being made at the same time:

• We see agile as a mindset; and
• We are building a maturity model to ensure everyone adopts exactly the same agile practices in the same way without variation

I guess my problem is that I don’t think the agile mindset is to be consistent and compliant.

To me adopting an agile mindset and related practices means being  curious and evolving continuously.

This implies that existing good practices will become outdated while new and useful approaches will appear as the context of the team changes.  I don’t actually think that “best practice” agile exists, rather we have “the best we know of, here and now, in our current circumstances.”

So here is the maturity module that I provided to the team I was talking to.  I said I would publish it and here it is – official and fully endorsed.

Agile Maturity Model

Best practice for this team, today, according to me.

Based on my opinon. Not endorsed by anyone international or important.

• Level 0 – Not knowing that agile exists
  • Hearing that others are agile and worrying about whether you should be
  • Tell people you have adopted your own approach to work but secretly feel you are missing out
  • Start asking people what agile is and hope that you can do it soon so you can hang out with the cool organisations
• Level 1 – Implementing agile in theory and rigid practices in reality
  • Tell the team they need a new mindset – this time it will be “agile”
  • Restructure the team and tell them that to get their old job back they need to convince you that they have the correct agile mindset that you agree with … or you will fire them
  • Implement strict agile practices that must be adopted. Do not actually train people in those practices
  • Hold the team accountable for what happens but do not allow them to choose how to implement agile or approach the work they are doing
  • Do not let the team work with their customer directly to understand what really matters
  • Adopt a maturity model based on blind compliance with what you learned in the latest conference or what you implemented with the last team
• Level 2 – Honestly trying to become agile and help the team
  • Honestly try to help the team become agile
  • Find a best practice approach to agile. Try to adopt it. Feel guilty when you fall short.
  • Agree you are not agile enough and keep trying
  • See some benefits and keep going.  But calm the team down when they feel guilty and admit that it will be a long journey
  • Focus on short term goals that benefit the team, the customer and then the organisation
• Level 3 – Wait – agile is an adjective
  • Realise that agile is an adjective – “able to move quickly and easily”
  • Treat agile as a good idea, but more a means to an end rather than a goal on its own
  • Try to adopt the agile practices that will make it quicker and easier to get work done
  • Find out what others are doing and see what you can adopt locally
  • Adopt new things but learn that integrating new ideas takes time and practice
  • Realise you are not there yet, but that there are things you can do to improve
  • Keep implementing things that make work quicker and easier while feeling guilty that you should be more agile
• Level 4 – Hang on agile is a toolkit or a mindset or both
  • Realise that agile is an attitude or a way or working
  • Realise that your team are not a bunch of tools who need to do agile better
  • Realise that the goal is not for you to become agile at all
  • Adopt things that help you – demanding that agile practices work for you and not trying to make the team use practices for their own sake.
  • Realise that you need to start where you are today.  Consolidate what works now and look for what will make things better tomorrow.
  • Re-frame the agile practices as a toolkit you can draw from.  Use role definitions as examples that might work and techniques as useful ideas when the are used in the right context
  • Explore what “agile mindset” means, rather than just saying it matters.  Start by exploring what the team think and what seems to make sense to them in their environment.
  • Do not try to adopt someone else’s agile mindset, instead look within for what you and the team think it means.  Work on that.
• Level 5 – Trust the team and make value explicit
  • Realise that the challenge is not really about being agile at all.  It is that your team are doing a difficult job in a rapidly changing, competitive and challenging world
  • Go to the team and admit you do not know the answer
  • Have the team work out what “value” means in their context, who that “value” matters to and what is impeding their ability to deliver that value.
  • Throw out all the maturity models (including this one) and ask the team for help
  • Work with what you have, keep making mistakes and keep refocusing
  • Use the agile toolkit the best way you can, keep asking for help and keep looking at what other people are doing rather than having to invent everything yourselves
  • Teach the team to use the agile toolkit and update it as the team try new ways of doing things
  • Teach the team to research and learn better practices
  • Build the resilience in the team to recover from failure and to drop performance from time to time while you learn.
  • Experiment when you can and practice what works
  • Realise that you can actually experiment most of the time if you customers trust you and the team trusts itself

Rather than trying to standardise practices (like standardizing the word standardizing the right way) this model is based on a series of epiphanies (or aha-moments or “wait, bugger, hang on” moments).

These are the realisations I think you should adopt rather than the specific practices. Otherwise you will be stuck at level two forever.  And everyone knows that in every maturity model you want to get to three and then work towards four and five.

Applying the model

Pick where you want to be and move to that level of “aha I get it”

The end

The associated body of knowledge

You will need a body of knowledge to implement this.  We call it the “SYSK” or stuff you should know.

The complete knowledge required is found in two evolving repositories

• Ask your team what they think
• Look outside at what others do with a fierce curiosity

Ongoing releases and support from the dodgy maturity model community

I am happy to come and assess your team … or you can ask them understand where they are at , where they want to get to and how to get there.

I also have some friends that can help if I am busy or we don’t hit it off.

But you can also go to your team and see how they feel about their progress.  Then give them space to grow and kick them in the pants  tell them you are disappointed if they do not take you up on the opportunity.