Coen Meerbeek

Adidas DevOps Maturity Framework and capability models

Coen Meerbeek -

It used to be very common to look for a maturity level framework to have an indication on which level you are and which level you wanted to go. When looking at the different levels you were always thinking like “Oh, for that I am in level 1 and for that I’m in level 2. How is that possible?”

Maturity levels oversimplified things and live appeared to be a little different then the maturity models that were build. OK so now what?

Let’s talk Capability Models. They are much simpler and dynamic and allow you to mix and match the capabilities you think you should work on. Also Capability Models are easier to implement and can be a nice waiting of motivating your teams to improve their way of working.

So how do do you build a capability model?

First you start defining the capabilities you need for a certain category. For example in the category Development you have a capability saying “Use Version Control for all production artifacts.”

Second. For each capability determine 3 levels or where you could be. Say for the above mentioned capability level 1 is “No Version Control”, level 2 is “Source code or other assets under version control” and level 3 is “Source code or other assets under version control and all production artifacts versioned and stored in the corresponding artifact repository”.

Third. Rate yourself for each capability on the level you’ve just defined. So for example you say that for version control you are on level 2.

Now you have a capability model defined you can start working with it.

Based on the blog I’ve written how I try to be productive you can, for example, pick 3 capabilities each 13 weeks with your team. You can pick capabilities for any category.

Make sure it is a team effort so everyone clearly sees why the teams wants to do this. Make sure that only one team member is responsible for a selected capability! He doesn't have to work on it alone but he is in the end responsible.

Find out on which level you are if you didn’t do that yet and create clear actions to get that capability to the next level.

Monitor those actions closely with the team. If you use SCRUM for example you can check in the Sprint Review what you've done and you can plan actions in the sprint like regular work.

Adidas DevOps Maturity Framework

I recently came across a very neat capability model from Adidas. They call it the Adidas DevOps Maturity Framework and you can find it on GitHub.

What I like is how they called their levels; Crawl, Walk, Run. How a baby learns to walk :-)

They have categorized there capabilities; development, product and process, management and monitoring, culture, architecture. Good that they focus not only on tools but also on things like process and culture which is often overlooked.

Let me highligt some capabilities which are often overlooked:

  • Support test data management > if there is any proper testing done data automation is often missed. Being able to reproduce test data is vital even for other capabilities like proper monitoring.
  • Include NFR’s in Definition of Done > Non-functional requirements are important because, for example, finding out that monitoring is not in place when your application is in production is costly.
  • Have a lightweight change approval process > How often do you see organization switching to agile while maintaining their ITIL change processes as they were? This is holding back innovation because either new code is in production after some days instead of minutes or hours or the whole change process is bypassed and other things go wrong.
  • Build it and run it > this one is interesting. When I propose to change the permission model of Splunk (the product I work with) people are hesitant by default because they don't trust the people who built stuff. I think there is no alternative. If you can't build and run it, you don't own it.

The framework is easy to read and explain and you can start working with it right away. I highly recommend sharing and discussing it with your team if you are working in software development.

Conclusion

A Capability Model is much easier to create, maintain and follow. There is no discussion on which level you are on and where you need to go. You are flexible to work on the capabilities you think are important in a specific time.

The Adidas DevOps Maturity Framework is a good example of a capability model. It is easy to read and use. You can focus on the things your team thinks is important.

I hope you find this useful! If you have any questions please contact me on Twitter!