Why successful DevOps implementation requires a “cultural change”
Source – techrepublic.com
TechRepublic’s Dan Patterson spoke with New Relic’s chief product officer Jim Gochee to explain how companies can improve the way they implement DevOps into their company culture. Below is a transcript of their interview.
Patterson: DevOps, a process that amalgamates software development and operations, is one of the most effective methods of iterative product development. But implementing DevOps, while it can aid your company’s digital transformation efforts, usually requires entire team buy-in. For TechRepublic and ZDNet, I’m Dan Patterson. We’re speaking today with New Relic chief product officer, Jim Gochee. Jim, what are a few best practices for CEOs looking to adopt DevOps as part of their digital transformation initiatives?
Gochee: Yeah, Dan, it’s great talking to you by the way. We see a lot of digital transformation projects and we get asked quite a bit how we do DevOps. I know that there’s a real hunger out there for best practices in this area. Right off the bat when I talk to an executive the first question I like to ask is, “Who’s taking the pager call?” I think this really more so than anything else tells me what stage of the journey they’re at, because in traditional operations you would have an operations team that was separate from the development team, and they were the ones that would take the pager if the site had an issue.
That doesn’t really scale that wall between operations and dev. So when you really look to do kind of peer DevOps, you want a development team also responsible for operating the service, and they should be the ones taking call. There’s many downstream positive things that happen when a development team is responsible for taking call, like they care more about the customer experience, they’re going to fix those issues that keep dragging things down, and they’re going to eventually start to move at a higher velocity. This is our thing, when teams move at a high velocity, they’re likely to introduce defects and bugs. And so the team that introduces those defects needs to be the team woken up at 2:00 a.m. in the morning to fix those defects. It’s really the only viable thing. So that’s why I start, “Who’s taking the pager call? Who feels that operational responsibility? Is it the ops team or is it the dev team?”
Patterson: What are some of the best ways of communicating the goals of DevOps from the C-level down to various decision makers within the organization, as well as communicating some of the end goals. I understand that Agile development is a part of DevOps, which has some of that communication built into the development process of software, but how do C-level executives communicate the goals across the team and remain consistent?
Gochee: There’s a couple things here. First, what we’ve seen is executives who need to make a cultural change, who need to change a culture usually have more success if they bring in a change agent into the organization who’s an executive under them, who’s done this before, and who can really go through a change management process of converting an older culture. One that’s not agile, one that doesn’t use DevOps, to a much more modern culture. That’s just in terms of how to get the organization ready to do this.
Once you have an organization that’s ready to do this, what we do is we have a master prioritization list across all of our teams. Our teams are Agile and we have about 47 separate teams at New Relic. But what we need to do is coordinate their activities, and make sure it’s aligned to what the business needs. We have a master prioritization list that the teams look at, and that way if we have a crosscutting project where every team has to do some work, we know we can get that work scheduled very quickly at the next iteration. The next brand for teams through this like being very explicit about the global priorities for the whole organization. If teams don’t have anything to work on in the global priority, then they’re free to go back to their own local priorities, making their own part of the product or system better against their own backlog.
Patterson: In your experience what are some of the problems, flaws,or road bumps in not just DevOps, but that companies could experience while implementing DevOps?
Gochee: There are many hurdles to overcome in a transformation. The biggest is culture, honestly. If you don’t have a culture of teams that want to move quickly, take responsibility for the pager, that right away is usually a bump along the way. And it can be a big one. More so than any one, I talk to our customers who are undergoing a transformation and they ask me on the cultural element “How do you do this? How do you get a culture where people want to try something new, and they want to do something differently?” So again, I think that’s where the change agent comes in.
Also, do teams want to instrument things and do they want to look at data, because if you’re making rapid iterations and changes to your software, and if you don’t have any instrumentation, then you’re flying blind. This is where New Relic comes in as an instrumentation company. We see those two things connected: The more you change things, the higher the likelihood something will break at some point.
With data, you can detect when that happens and you can roll a change back. But sometimes we see companies try to move fast without any instrumentation, and then they just get themselves into trouble and then you get the naysayers who may think, “Well, this is what you get for trying to move too fast. We told you it couldn’t be done.” So having that data to support teams is a critical part of being able to do DevOps and Agile, and move quickly.
Patterson: What resources are available to me? Where can I go to learn more and get started with DevOps and digital transformation?
Gochee: One of the books that I read recently that I would definitely recommend is the Google SRE book. It’s been out for a couple of years, and it really is probably only applicable as they lay it out to a company the size of Google, and so you have to sort of read it and read between the lines of how would it apply to me. But this whole site reliability engineer role, which Google kind of coined and I see a lot of companies using it, is very clearly spelled out in the book and is definitely a great read to sort of level set in terms of how modern operations DevOps can be done. I love that.
In terms of digital transformation I think there’s so many case studies being done right now. We put out white papers about the companies that we work with, and how they’re transforming. There’s a lot out there. I feel more sort of anything just looking on Google to see what’s being published, attending conferences, attending meetups, and networking with your peers who are also undergoing. Everybody’s undergoing some form of digital transformation right now, and so as an executive find your peers and have open dialogue with them. They’re probably struggling with some of the same things that you are as well, because I think there are very few companies that are sort of doing it really well at this point because it’s such a new and fast-moving thing.