ileezhun - Fotolia

Never mind the DevOps maturity model, focus on principles

Gary Gruver shares his thoughts on the DevOps maturity model and why focusing on DevOps principles of ownership and flexibility is more important than following a rigid roadmap.

There are few names in DevOps as big as Gary Gruver. He's an experienced software executive with a knack for implementing continuous release and deployment pipelines in large organizations. In fact, he literally wrote the book on the subject. His latest, Starting and Scaling DevOps in the Enterprise,'is an insightful and easy-to-read guide that breaks down DevOps principles by putting them all in a context enterprises can use to gain alignment on their journey to continuous delivery.

Gruver, president of Gruver Consulting, sat down with DevOpsAgenda to discuss the DevOps maturity model, core DevOps maturity principles, and how small and large organizations must take different paths on their DevOps journey.

What's your take on the DevOps maturity model? Can that stymie DevOps adoption in large organizations?

Gary Gruver: A lot of people come out with these maturity models and say, 'We had some success in DevOps, and now everybody has to do what we did.'

If you don't start with the changes that are going to benefit people the most, you're going to lose the momentum in your transformation.
Gary Gruverpresident at Gruver Consulting

And what I find when I go into different organizations, or even looking at different deployment pipelines within organizations, [is] that the things impacting productivity are fundamentally different. You look at a DevOps maturity model and it might claim, 'You need to have Infrastructure as code, automated deployment, test automation, and this and that.' I think that overlooks the actual problem each different deployment pipeline might have.

This is about organizational change management, and it's about getting people to work in different ways. If you don't start with the changes that are going to benefit people the most, you're going to lose the momentum in your transformation.

Therefore, I think it's important to start with DevOps principles so people can pick the changes that'll make the biggest difference to them, so they will take ownership for implementing the changes into their organization.

How does scale affect success in DevOps?

Gruver: If you're a small team and you have four or five developers, then DevOps is about just getting people to embrace and take ownership of code all the way out to the customer. It's making sure the code is meeting the needs of customers and stable in production. Then, it's responding to that feedback and taking ownership. It's a lot about helping these developers become generalists and understanding the operations piece of this puzzle.

But if you have a tightly coupled system that requires thousands of people working together, then there aren't that many people who are going to know the whole system and be able to support it in production. In these situations, someone needs to be responsible for designing how these complex systems come together and continually improve the process. It is going to require more specialists, because it is hard for everyone to understand the complexities of these large systems. The ways you coordinate five people are a lot different than coordinating a thousand.

Simon Wardley's Pioneer, Settlers and Town Planners model
Maturity models aren't the only models of use. Organizations can turn to the Pioneers, Settlers and Town Planners model to reach DevOps efficiency in the best, most organic way for them.

What are some of these difficulties applying DevOps practices from small- to large-scale organizations?

Gruver: What I hear a lot of people in large organizations do with DevOps is they look at what the small teams are doing, and they try to replicate that. They try to reproduce and figure out how to make the small-team strategy work in a tightly coupled system, instead of really looking at the issues blocking them from releasing on a more frequent basis.

They're not asking, 'What are the ways we can address this waste and inefficiency and take it out of the system so we can release more frequently?' They figure if they just do what the small teams are doing and try to replicate that and create a DevOps maturity model, by some magic, they're going to be successful. Instead of doing that, they should focus on principles to figure out what's going on in their system.

Large organizations should break it down as small as you possibly can, because smaller things are much easier to solve, maintain and manage. So, if you can break your system down into microservices and make that work, those teams are always going to be more efficient. That said, rearchitecting a large, tightly coupled system can be extremely complex and time-consuming, so it is typically not my first choice.

Additionally, there are a lot of DevOps practices that can be successfully implemented in large, tightly coupled systems. In fact, I would argue that applying DevOps principles in these complex systems will provide much greater benefits to the organization just because the inefficiencies associated with coordinating the work across large groups is so much more pronounced than it is with small teams.

Next Steps

To build or buy? That's the DevOps toolchain question.

The three types of DevOps work: feedback, triage and automation.

It's easier to train essential DevOps skills than to hire them.

This was last published in November 2017

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How can we assess DevOps capabilities without limiting ourselves to maturity models?
Cancel
The problem I have with maturity models is that they assume everyone should start in the same place and journey to maturity on the same path.  My experience is that each deployment pipeline I examine at different companies have different issues that are impacting their ability to deliver code on a more frequent basis (DevOps). I also feel that if you are going to create the momentum required for a successful transformation you need to start where you can provide the biggest benefits the quickest.  Instead of a maturity model where everyone does the same thing in the same order my "Starting and Scaling DevOps in the Enterprise" book recommends mapping out each deployment pipeline to identify which improvements would provide the biggest benefits for each deployment pipeline.  
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchITOperations

SearchMicroservices

TheServerSide.com

SearchDataCenter

Close