In this article, part of my series explaining better ROI from software development, I’d like to look at maturity models.
“A maturity model is a business tool used to assess an organization or process” Wikipedia
A maturity model allows you to assess how well you are doing in a specific disciple.
It is intended to provide you framework in which to evaluate your current competencies along with guidelines on how to improve towards greater mastery.
A maturity model shouldn't be seen as a judgemental tool. Rather just an indication of current location in a longer journey.
This can be important if you look to review your process against a maturity tool.
Any assessment can produce anxiety to the team responsible for the system. It needs to be clear to them that this is about improvement – not as a means to attack the team’s competencies.
Any assessment is more accurate if the team are providing accurate answers rather than “inflating” to make everything look better than it is.
In my article ROI of building the thing right, I talked about how important that you have a "well oiled IT".
A maturity model is a method of assessing your proximity to that best practice.
It can be a useful exercise to have good strategic review of capabilities and competencies.
A maturity model isn't the only method by which to do this. There are a number that I’ll try to cover off in the fullness of this series.
I've seen various types of maturity models. Some are aimed at particular disciplines, some are aimed at organisational characteristics.
For this article however I will be focused on the Agile Maturity Model as described by ThoughtWorks Studios.
ThoughtWorks Studio’s are a consultancy organisation focused on software development. They provide various software services and, at the time of writing, have 3600 employees in 12 countries based in 34 offices. They are well known within the software development community as providing best practice advise.
Disclaimer; I have no affiliation with ThoughtWorks. I have never worked for them or with them. I have benefited from a number of articles & presentation that have been produced by them.
In the article, the authors define their ideal state to be …
“Ideally, each change made to your application, its environment, or its configuration should go through an automated process. This process should create binaries, run automated tests against them, and inform all relevant parties of the results of this process. We call such a system the deployment pipeline. It should also be possible for developers, testers, and operations people to have not only visibility into this process, but also to be able to self-service processes such as deployments to testing and environments and the release of applications at the push of a button. Such processes also form a part of the deployment pipeline. ”
A number of the terms listed maybe new to you – don’t worry too much about that at this point. I’ll go over the core principals below (along with why they matter).
The key here is that the authors are attempting to provide an ideal that is based on best practice as the software development industry currently understand it.
These will invariably lead to better ROI.
I personally see great value in having reached the point where you can disagree with a model.
It means that you have gone through an assessment process, you will have really thought about what is good practice and how you stack up to it. That exercise is where you get value – not from being able to tick a box on the model.
So there is definitely nothing wrong (in my opinion) from not religiously following a maturity model.
I would however ask you to look again.
Within martial arts, there is the concept of Shu-Ha-Ri (I believe I've talked about this before, but can’t for the life of me remember which article)
“Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
Ha: At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
Ri: Now the student isn't learning from other people, but from his own practice. He creates his own approaches and adapts what he's learned to his own particular circumstances.” Martin Fowler
Be very careful of not falling into the trap of believing you have achieved mastery early and dismiss a powerful tool purely because you don’t understand it.
The maturity model is a matrix made of 5 sections – each measured to provide a level.
The 5 levels are labelled as:
The 5 sections are:
Within the matrix, the authors provide a small description for you to apply to your organisation. If it’s a good fit then you can get an idea of which level you are.
For this to work well, this needs to a collaborative open conversation. This shouldn't be done in isolation. Personal bias should be removed as much as possible.
I would also recommend when you have arrived at a specific level for a specific section you document why. This makes for a really useful reference when you review again in the future. 6 months down the line, no one is going to remember why you gave Testing a level 1 grade.
If you have multiple software development teams in your organisation, you might want to collaborate between to produce a consistent benchmarking. (Also a great way of sharing good practice between teams).
From the assessment, you may then build up an action plan to improve one or more sections. If you do, I would recommend being very focused. Look at one section and build a plan to move that to the next level.
Trying to jump multiple levels or work on multiple sections can be a very difficult task.
Be realistic in your planning. If you are a Level -1 for all sections, you cannot expect to get them all to Level 3 with weeks. In most cases you will be looking at months or even years dependant on your software size and complexity.
Dependant on any plan, you should then arrange to re-assess the maturity on a regular cadence. This way you can ensure that it doesn't just disappear off into obscurity.
In this article I've looked at one way of measuring if your software development is working best practice.
Each of the sections covered by the Maturity Model helps with better productivity and thus ROI.
Over future articles, I will dig into some of the specific terms mentioned.