Maturity models are frequently used as tools to help assess a process or an organization.
In Agile implementations, it is not uncommon to use check-lists, health checks, maturity models with a similar goal in mind.
Why are Maturity Models useful?
Agile implementations, or similar big fundamental changes, to the way we work, take time. While we start with some desired state in mind, we usually evolve to that stage over months and sometimes years.
Having a maturity model or a similar tool helps us look at the big picture, to see areas where we are making good progress and areas which need more TLC.
Maturity models are also a great way to keep the end (-ish, because the journey doesn’t really ever end) in full view for all. It shows what we are gunning for.
Building a Maturity Model
While a maturity model may actually assess process maturity, it is important to have the outcomes as the primary focus.
This way, even if our process or practices change, we can still use the basic framework of our maturity model which is based on outcomes.
For instance, if one of the reasons for doing an Agile Implementation is to improve the team’s ability to respond to change, then we would like the maturity model to show how the team is maturing in “Responsiveness to Change”. Or if delivering high quality software is a desired long term outcome, then we would like to visualize through the maturity model, how far along we are in the journey in “Quality”.
So, step 1, is to pin down the desired long term outcomes we are trying to effect through the Agile implementation.
So the outline of the maturity model after this step may look like this, for instance:
Once we have the outcomes pinned down, we need to actually build the questions using which we can assess process maturity – towards our outcomes.
For instance, if the team believes that Pair Programming improves the Quality of our software, then the maturity model may have a question asking specifically “Does the team use pair programming regularly for writing code?”
Or if the team works in short sprints to make us better suited to respond to changes, a question like “Does the team work in sprints that are 2 weeks or shorter?” may find place in the maturity model.
So step 2 is to figure out what are the questions that help us assess the process maturity which helps us make progress towards the outcomes we have in mind.
So the Maturity model at this stage may look like this:
Now comes the “maturity” part of the maturity model.
A maturity model recognizes that change takes time and process maturity evolves.
How a team behaves when starting with an Agile implementation and how an experienced team behaves, are vastly different. So the questions in the maturity model need to reflect this growth in maturity.
So step 3 is to take the questions and order them by “maturity”.
For example, a new scrum team may simply start having daily scrum meetings as a practice without fully extracting the value from it. So a question about “Does the team meet daily for a 15-minute daily scrum meeting?” may be appropriate in early days. But as the team matures and learns the value of the ceremony, a more relevant question might be to ask “Does the team challenge and improve the process of the daily scrum meeting?”
For each of the outcomes identified in step 1, we would have a list of questions ordered by maturity.
It also allows us to categorize the questions according to maturity – for instance “Beginners”, “Experienced”, and “Experts” or similar.
How do we score the questions? We keep it simple.
We design “Yes or No” questions with a score of 1 for Yes and score of 0 for No.
This now helps us identify where on the chart we would be if we answered yes for all the “Beginners” questions, and so on.
The maturity model may look like this at this stage:
Finally …Color codes and their significance
Visually, it is important to color code the stages of maturity. However we do not want to fall into the RAG (Red-Amber-Green) trap.
Being a beginner is not a red status – it simply shows where we are in the journey.
So we use any colors, other than the RAG scheme (or schemes with similar connotations) and keep any misinterpretation of the model at bay.
Here’s the maturity model in its full color and splendor:
Maturity Model Do’s and Don’ts
Often, a well-designed maturity model can be defeated by poor usage.
Here are some tips to using one:
- Use it frequently but don’t overdo it – so once in 2-3 months, just before a retrospective is probably a good place to assess the maturity. The maturity assessment can be a great input for the retrospective.
- Answer the questions together as a team with a facilitator helping you discern the questions when required. This is also a good opportunity for the facilitator to improve the teams’ understanding of the process and to show the end goals to the teams (give them something to aspire for).
- Use the maturity assessment outcomes to find the areas needing extra attention and look for improvements there.
- Do not use it as a governance tool for management – management may however look at accumulated trends across the organization to draw improvement items for them to act upon.
- Do not use it to evaluate or compare teams – every team is on their own journey with their own contexts, strengths and constraints.
- Don’t sweat the details – exact scoring, minute variations etc do not matter in the larger scheme so just ignore them.
Here’s what a maturity model with assessment done may look like:
So in summary, here’s how to build an Agile Maturity model:
- Step 1 – Identify the long term desired outcomes
- Step 2 – Identify the practices that help us go towards our desired outcomes – translate them to simple “Yes/No” questions
- Step 3 – Order the questions by maturity levels and group them
- Step 4 – Have a clear visual representation of your maturity model and assessment