“To be or not to be” was a profound question that Hamlet struggled with. Agile and DevOps coaches struggle with a far less weighty but vital question: whether to use maturity models or not.
We all know that maturity models have some weaknesses: they can easily be gamed if they are used to incentivize and/or punish people; they are very prone to the Dunning-Kruger effect and are often vague. Of course on the flip side, maturity models allow you to position yourself, your team or your company across a set of increasingly good practices and striving for the next level could be the required motivation to push ahead and implement the next improvement.
At one of my clients, we performed several maturity assessments across a wide variety of teams, technologies and applications. Of course, such large scope meant that we did not spend a lot of time with each team to assess the maturity. Not surprisingly, we got very different levels of responses. We heard things like, “Of course we do Continuous Integration. We have Jenkins installed and it runs every Saturday.” Had this team not mentioned the second part of the sentence, we would have probably ticked the Continuous Integration box on the maturity sheet!
A few months later we were back in the same situation and needed to find a way to help teams self-assess their maturity in an environment where DevOps concepts are not well known and different vendors and client teams are involved, which means the actual maturity rating can become political. I was worrying about this for a while and then one night, while playing on my PC, inspiration hit me—I remembered the good old Civilization game and its technology tree:
Now, if I could come up with a technology tree just like this for DevOps, I might be able to use this with teams to document the practices they have in place and what it takes to enable the next practice. Enter the DevOps technology dependency tree (sample below):
For each leaf in this tree, we created a definition and related metrics and now each team could go off and use this tree to chart where they are and how they progress. This way each team chooses their own DevOps adventure. We also marked capabilities that the company needed to provide so that each team could leverage common practices that are strategically aligned (like a common test automation framework or deployment framework). This tree has been hugely successful at this specific client and we continue to update it whenever we find a better representation and believe new practices should be represented.
Now, who would have thought that playing hours of computer games would come in handy one day!