Leveling up your software delivery capabilities (part 2)

Previously (part 1) I showed my view on using maturity models in improving software delivery capabilities. In this blog, I will show how I use these models to improve maturity.

Working with maturity models

In the past ten years, I have worked with a wide range of software delivery maturity models. Once you internalized how maturity models progress it becomes part of how you naturally plot growth in teams and organizations. Simply put: in any growth situation, you immediately plot a roadmap from less mature to a self-optimizing end goal. It is that mentality that pays off. Secondly, the realization that the journey to self-optimizing is important itself. In many situations leap-frogging to a more mature situation, without passing through the maturity phases limits your performance and overall maturity. The process of self-improvement brings culture change and makes sure you embed a fundamental improvement philosophy in your organization. One could say that the journey is just as important as the destination.

I regularly search for new maturity models that aid in my domain of application engineering. Models get re-invented and maturity levels get rebalanced. What is mature eight years ago is beginner level today. Organizational dynamics, technologies, and processes change at least every five years depending on how ‘modern’ your environment is. I found it pays off to merge industry-standard maturity models to create a situational model.

My go-to overall process

So to give you some reference on how I think all these models can still deliver a lot of value. Below the steps are explained in more detail.

Using Maturity models to increase performance

1. The first one is setting an ambition that is contextual to the situation. We should not all strive to become the Spotify or Netflix of DevOps maturity so it makes sense to set a realistic expectation. On this ambition and context, the right maturity matrix can be constructed (out of industry standards) creating a custom and situational maturity model. The key here is to don’t be dogmatic but to be contextual.
2. One of the often-overlooked steps is the identification of anti-patterns that might exist that currently limit our capabilities to mature on our model. This is a topic that deserves a blog on itself. But it’s fair to say that especially the organizational context surrounding technical teams need to be aligned to the desired improvements. Another example is that high technical debt is sabotaging lots of great improvement ideas.
3. The next step is to baseline a current maturity level. While the result of this baseline is immensely valuable when comparing improvements in the future, it also has lots of spin-off benefits. Asking teams to reflect on their own ‘state of affairs forces them to look up from their daily affairs and I have seen it sparking a ‘growth mindset’. The plotting of maturity levels is a huge radiator of a pending culture of change. It sets the stage for what’s to come.
4. The next step is to optimize maturity in all different capability areas. As mentioned before this is a process where maturity levels can best be incremented in a level way. So practically, make sure you level up your organization and culture in equal increments to the technical software improvements.
5. Once you reach a decent mature state one can shift gears to a phase of optimization based on metrics. The four key metrics from Accelerate are a nice default, however, I would consider alternatives as well. At this level, a team can inspect and adapt its process and technology. Adapting culture and organization are sometimes still more difficult for individual teams, as they often require managerial influence. Furthermore, I advise adding the additional maturity goal of resilience. Optimizing only on key metrics can always lead to surprise when external factors suddenly overthrow your status quo. You might feel you are doing a decent job, but adding resiliency goals will make sure you can sleep at night.

Wrapping up

Fundamentally I hope I convinced you to take the take a holistic view of your improvement process. It always takes the triplet of process, technology, and people to get a balanced holistic view of improvement. Improvement frameworks come and go, they grow in maturity together with the needs of modern software teams. It might not be a silver improvement bullet but I am convinced that maturity models provide a place of learning and reflection when put to good use.