Common Challenges for Leading a DevOps Transformation
Common Challenges for Leading a DevOps Transformation
Undergoing a transformation while having to continue business-as-usual is a major challenge. Change causes anxiety, which is a major threat to a DevOps transformation.
Join the DZone community and get the full member experience.Join For Free
Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market.
We recently kicked off our 2017 season of our Continuous Discussions (#c9d9) video podcast with an episode featuring a panel of speakers from DevOps Enterprise Summit (DOES16), discussing Leading Change (the key theme for the conference this past year).
Our expert panel included:
Nicole Forsgren, CEO and Chief Scientist at DORA.
Paula Thrasher, Director of Digital Services at CSRA.
Pauly Comtois, VP at Hearst.
Ross Clanton, DevOps Fellow at Verizon.
Steve Mayner, Agile Coach, Mentor, Thought Leader, and Strategist.
Our very own Anders Wallgren and Sam Fell.
During the episode, panelists highlighted common challenges in aligning teams, managers, and executives around a DevOps culture and proven patterns for success in leading a DevOps transformation in large organizations.
The hour-long discussion with some of the best DevOps mind in the industry was packed with great insights and best practices.
In the first part of this two-part blog series, we highlight the challenges that the panelists discussed. Stay tuned for the second part, where we cover the patterns for success they shared with us.
Communication is a major challenge Forsgren has seen in her research: “A lot of the challenges that I see when people are trying to lead change in organizations is around communication. How can we get everyone on board? How can we help everyone see where it is we’re trying to go and where we are now? How do we communicate that? How do we motivate everyone? Essentially, it still comes down to needing to get a bunch of people to believe in the same mission and the same goal, and want to be a part of that team and align themselves to that same goal.”
Comtois discusses the challenges his teams have been facing at Hearst: “A big challenge for us is that change is occurring at such velocity that we’re finding it difficult to keep communication current. We are trying to help teams move away from that classic written documentation method of communication, that “Sunk Cost Fallacy” of holding on to the SharePoint server as the single source of truth just because of the sheer volume of content in it. You still document what needs to be documented, of course. But, it’s been a huge time suck for us. It’s been wonderful to get that time back and say, ‘Oh, yeah; if we just talk to each other, we sit together, use Slack every day, use Bots to automate away all of the ancillary stuff that would have eaten hours out of every day.’ That’s been great for us in building momentum.”
Treating your pipeline like a product is crucial but requires some work, explains Fell: “When you think about your pipeline, what you use to deliver your product — is in itself a product. You should have a list of things that you want to improve in your pipeline, you should be measuring it, you should be understanding what works, what doesn’t work. It is a very critical part of your application. If you don’t ship, no matter how much work you do on the front end, no one’s going to see it.”
Clanton says that the constant changes happening in the industry are particularly challenging to keep up with: “I think one thing that’s increasingly challenging is the number of change programs, and the number of things that are changing in the industry right now, and how that’s all infusing. You’ve got this massive move to Cloud. You’ve got the way roles and responsibilities change for individual product or development teams — they have to secure their stuff, they have to run their stuff. It isn’t just about writing code and passing it onto the next person in the queue. You’ve got the cultural transformation that’s associated with moving towards DevOps and Agile, and I think it can be overwhelming for an organization to deal with all of that together.”
Wallgren mentions that culture change is the biggest challenge he sees in large organizations: “It’s so easy to get stuck in that sort of cargo-cult mentality. ‘We do stand-ups, therefore we’re Agile.’ ‘We do stuff in the Cloud, therefore we’re DevOps.’ We say things like this and don’t really focus on the things that cause change, and help change become permanent. We’re stuck. The most common mode of failure I typically see is culture failure, or failure to adapt the culture.”
Thrasher talks about the struggles of collaboration in large organizations: “We have to have the great collaboration tools and the great practices around collaboration. When you’re in a large organization, you need specialists. You won’t get away from people that have specialized expertise. Just because you have all those organizational groups doesn’t mean you can’t collaborate. That’s where we are really trying to spend our energy is in organizing the collaborative teams.”
Getting leaders to change their mindset from delegator to student is particularly challenging, explains Mayner: “When it comes to driving to a different culture, like a DevOps implementation, this cannot be delegated. You have to know what it is that you must do. That means you have to be a student first. You have to understand it. That doesn’t mean you’re going to be writing Chef scripts. But, it means you have to understand what’s different about where it is we’re trying to go from where it is that we’ve come, and you’ve got to be the chief cheerleader. You’ve got to exemplify the mindset change, the behavior change. You’ve got to show that you’re in the fight with everybody else, that you’re right there, as a servant leader, a transformation leader. You need the understanding for what you can do with the leverage you have, to be able to support, enable and empower everybody that’s fighting, day in, day out, trying to drive this change across the organization. Which means you’ve got to be authentic, you’ve got to set the example first.”
Another challenge Forsgren points out is that people can only be motivated by themselves: “My background is also actually in Knowledge Management and Motivation Research. The key is we can’t motivate other people; we have to help them motivate themselves. All of the motivation research shows that everyone really has to motivate themselves. So, as leaders, and even as someone who’s a team member or individual contributors and practitioners, we need to ask, ‘How can we help our fellow practitioners buy in? How can we help everyone else understand the greater goal, the greater mission, so that everyone can have that drive from within?’”
Comtois has this to say on the misconceptions of DevOps: “I have found a lot of misconstrued notions on what DevOps is and how fast you do it.. It’s not an off-the-shelf software package you install that fixes all of your problems overnight, or even in a year. The patterns and culture that you have in your organization have taken years to develop. Changing that doesn’t happen overnight.”
Combating resistance to change is another challenge, per Clanton: “I think the challenge is figuring out how to simplify the people side of the transformation — the skills and practices, the culture, the operating model, and how you think about your teams so that you can help a large scale organization go through that level of change. I think that’s probably one of the hardest things I’m working through right now. I also think figuring out how to get inertia. You’ve got to figure out how to continually energize the masses, the people that are passionate about change, while you’re continuing to fight the changing battle at the same time.”
There are tendencies to rule out the necessity of leaders and managers, but Mayner says that shouldn’t be so: “In our Agile and DevOps circles there’s a spirit of self-organizing and self-managing, which is all fine. However, there’s often a too strong of a pendulum swing to the other side that we have seen in some circles. We hear, ‘We don’t need managers. We don’t need leaders. We’ll just let teams do it. You guys just get out of the way.’ Well, when you’re running multi-billion dollar global organizations it just doesn’t work that way. We need leaders. We need managers. They play a very critical role in a transformation, like a move to DevOps.”
Undergoing a transformation while having to continue business-as-usual is a major challenge, per Wallgren: “A syndrome that I see quite a lot is the ‘I’m too busy drowning to learn how to swim’. You’re not going to stop the clock while we do this transformation. Challenges continue, competition increases, and costs have to be controlled. That seems to be a problem in the trenches, but, I think that’s more of a universal problem all up and down the chain. It is definitely a problem of, ‘How do we change the tires on the car while we’re driving on the freeway?’”
Change causes anxiety, which is a major threat to a DevOps transformation, according to Thrasher: “We talk about having an impetus for change. Which is usually an industry crisis, merger, or something like that. Something happens that causes management to say, ‘Oh no, we need to do the DevOps.’ The problem now is that you’ve created anxiety. Most people don’t like change. There is a population of people that like that novelty, but the majority of the population does not like that novelty — they like predictability. Novelty is anxiety producing. There’s this presumption that when you have novelty you have fight or flight. However, there’s actually three things: fight, flight, or freeze. I think what happens in a lot of our organizations is freeze. Very few people react with ‘Okay, crisis. Let’s go get it!’ The more common response, I believe, is that people freeze.”
To see more and watch the full episode, go here.
Published at DZone with permission of Anders Wallgren , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.