In our first episode of Continuous Discussions (#c9d9) for 2017, we had 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; and, our very own Anders Wallgren and Sam Fell . In the first part of this blog series , we discussed the common challenges we face when working in or with large organizations undergoing a DevOps transformation. This second post covers the best practices and patterns that they shared for a successful DevOps transformations at scale.
Key Takeaways from Continuous Discussions (#c9d9) Episode 60: Leading Change
Part 2: Patterns for Success
You have to create space for a #DevOps transformation to work - whether it's physical, temporal or emotional @anders_wallgren #c9d9 pic.twitter.com/qMsXsnNkYT
— CloudBees (@electriccloud) January 17, 2017
Per @nicolefv - one of the things that people don't realize is that metrics is a form of communication in the organization #c9d9 #DevOps pic.twitter.com/xHeHIgkK3h
— CloudBees (@electriccloud) January 17, 2017
"To be a change leader, you need to set the example first" @stevemayner #c9d9 #DevOps #business pic.twitter.com/uVxzAzBxl1
— CloudBees (@electriccloud) January 17, 2017
Thrasher emphasizes the importance of training middle-managers : “Train your middle managers to be change agents. Is your management team training program thinking about training people in change leadership skills? Because it's not just the top leadership, it's the middle tier. Giving that middle manager (who's more connected to the work) the skills to manage their team through the transformation is really beneficial. We weren't born knowing how to do these things, so we can all grow and learn together. If you invest in helping your managers understand how to be better servant-leaders, everyone benefits.”
Create metrics for culture and collaboration , suggests Forsgren : “I started talking about how communication and collaboration and getting everyone on the same page is going to be super important. One of the things that people don't always realize is that metrics are a form of culture and a form of communication. Metrics and finding some way to baseline and assess where everyone is at is a huge benefit. Understanding where you are and using that set of benchmarks and measurement is as a way to communicate what's important around the organization. Use that as a way to solidify and let everyone understand not only what's important, but what it is you're talking about.”
Even though collaboration is a big part of DevOps, it’s important to focus on the individual as well , explains Clanton : “I think there's two parts to the ‘Why do DevOps?’ question. I think one is organizational purpose and what we need to help the business win. I think the other thing that needs to happen is you got to help people understand what's in it for them, personally. Why is it a good change for them as individuals to go through? Generally, there are really good outcomes associated with DevOps from a personal experience perspective, if it's done well. So helping people understand that, I think, helps some of that change occur.”
Make sure everyone in the organization has a voice, advises Mayner : “A best practice that I always recommend is, as part of the transformation, identify a sounding board group . I'm talking about people at all levels of the organization and give them the form of an advisory panel, or some way to incorporate them, and really go to them with open ears. Say things like, ‘Tell us how this is going. What are we doing well? What are we not doing well? Is this message coming across? How could we do better?’ Because our views are jaded, and we can't un-jade ourselves, we've got to have those folks who can give us real, authentic, untarnished feedback as to how things are going. You need to set that up if you don't have that venue.”
Comtois emphasizes the importance of empowering developers : “We keep saying and hearing that we want to empower people, but that implies that they didn't have power to begin with. We've been working to acknowledge that our engineers have power through their own passions for creating software, and we've started to change that vocabulary around this approach. We work towards allowing everyone to be leaders, and make decisions on their own as a team. We focus on team-based objectives and minimize individual goals to the point where it should all feed towards the greater good of the team.”
Make it safe to transform, says Wallgren : “You have to create space for DevOps to work. That means, in some cases, physical space. Sometimes it means temporal space, sometimes it means emotional space. You have to somehow get to a place where we feel safe to make the changes, feel safe that it's okay that these changes are happening, or it feels like they're happening to us. You need to create a safe space or it won't work. You'll be dragging everybody to the dinner table to eat the meal, and they're not going to enjoy it, and it won't be fun, and they're going to be crabby about it. Walk a mile in somebody else's shoes - that works not just down the chain of responsibility, but also up.”
Fell encourages overcoming thoughts of doubt : “Nicole and the DORA folks are trying to get that data around where people are and what/how they're doing DevOps. I think there's a lot of trepidation about, ‘I don't feel like I'm ready to get started yet, so I'm just not going to get started.’ Or, ‘I've got lots of people inside of my organization and they've already gotten started, and they're all doing whatever they're doing. Eventually it may impact me, but...’ You need to start wherever you are, not where you want to be. take the plunge.”
Make it safe to change and fail, but most importantly make that message authentic , advises Mayner : “The resistance to change and fear is a huge part of organizational failure. Something that I coach leaders to do in terms of, ‘What is your message to the organization?’ is you have to make it safe to change. It's okay to fail. Don't keep failing in the same way over and over again, but you got to say, ‘It's okay. We understand. Your velocity, your ability to achieve is going to go through that J curve as you learn new patterns. We know that's going to happen. We expect it, and it's okay.’ That message can only come from the top, and there's got to be an authenticity behind that.”
Focus on the small successes , says Forsgren : “Big, massive successes are awesome, except those are so rare, and you probably don't know what actually led to that. What you want are small improvements that build up over time to give you that awesome mountain of ‘amazing.’ So, having measurements that everyone understands and what those small measurements are means that when we do have those small setbacks everyone can get on board and understand what that is.”
Reduce the anxiety of change by making changes smaller and more manageable advises Thrasher : “The more you can help remind people what's the same, and what part doesn't need to change, I think the more you can help them change the things you need them to change. That's a really tough balance, but that's why you should really focus on training the leadership to know how to do that, so they can manage their teams through this sort of anxiety. The smaller you make the change, the less anxiety producing it is. If it's a small little thing you can all agree on, it's not as anxious as this big bang. Which is why I think that continuous improvement is really the only path to success.”
Comtois emphasizes the importance of taking risk and have entrepreneurial spirit : “I think the most important bit for us is feeling safe to take a risk, and that has been our DevOps change multiplier . That's been the thing getting people on board with the idea that it's okay to take a risk and fail. I call it the entrepreneurial spirit. We need more of that. Even though we're an enterprise organization, we need to think that way internally, so that we can go out and take some risks, try new software, get the team excited about an idea and then go off and do it. If it works, you get funding and literally treat it like a startup internally. we actually spun up applications that we now sell off of that idea, and it all came from someone feeling safe enough to take that risk.”
Steal a page from Verizon’s DevOps book and gamify your DevOps transformation! Clanton explains: “Verizon gamified DevOps to solve problems of how we're building skills and capabilities and infusing the culture. We came up with what we called a DevOps Cup, an annual Cup that's run. It aligned all these skills and capabilities that the team should improve upon, which aligned with how you want to improve yourself from a DevOps perspective. As teams demonstrated their improvements throughout the year, they built points. They were even encouraged to steal other people's ideas and patterns and how they did things. I saw it have a major impact on how that organization has evolved over the last couple of years.”
Watch the full episode:
Want more Continuous Discussions (#c9d9)?
We hold our #c9d9 podcast every other Tuesday at 10 a.m. PST. Each episode features expert panelists talking about DevOps, Continuous Delivery, Agile and more.