The publication of the Open Organization Maturity Model reminded me that we had the goal to use a similar approach.
Why do we want to use a maturity model?
A maturity model is, as said on Wikipedia, “a measurement of the ability of an organization for continuous improvement in a particular discipline”.
So, our goal in defining such a model is to help a part of the organization to identify improvement opportunities. For that organization, we defined a specific organizational structure to serve it needs to curate and build technology in the open and to deliver a tested and trusted product to serve the needs of customers.
The organization is composed of cross functional groups, with an emphasis on self-organization, and continuous improvement. The transition to that model shows different levels of understanding and adoption.
For example, retrospectives were strongly encouraged from the beginning. Some groups are sticking to 2 weeks scheduled retrospective enjoying the benefits, while other groups did not grasp how the practice could help them in improving their way of working.
Introducing a maturity model could help to focus on a limited set of characteristics, and could help the different teams to identify the one thing they want to focus on improving during their next cycle.
The maturity model is meant to be used by the team itself to self-assess where they are. It is not a measurement tool, and there’s no need to look shinier than you are. There’s nothing to be ashamed of. The results and the actions that you will take to work on one thing are specific to your group.
The main categories of the maturity model will need to be specific to our organization. And, for each group in our organization, the position they will find will be specific to them, and to what they are delivering in the organization.
If I take the example of cars, main characteristics could be:
- speed
- safety
- reliability
- efficiency
- comfort
If one car is reaching a top speed of 20 miles per hour, we could want to improve it. But when it reaches 90 miles per hour, it is definitely not the area where the focus should be. It that case, I should probably have start with safety 🙂
So, introducing a maturity model, we are looking at conversations that will lead to improvements.
The language used in the maturity model should reflect outcome and not practices we would like to encourage. Looking a few paragraphs above, you will get why it’s important: if we are encouraging retrospective, we are pushing a practice and we could never get to the outcome we are looking at.
Thoughts on that? Recommendations to make?
Please comment, tweet, email…
The header picture is from Ryan McGuire.