Successful DevOps Starts With Organizational Alignment

When implementing DevOps, many companies take a practices-first or culture-first approach.  The thought is that if you can install practices, tools, or a culture that will support DevOps initiatives, the rest will follow. Unfortunately, this is the reason DevOps isn’t working for many organizations. Without the underlying organizational design, systems, teams, workflow processes, and alignment on a business goal, DevOps is destined to fail. The key to setting up DevOps for success is selecting the right approach that’s oriented to business goals.

Video Transcript

If you just Google DevOps one of the first things that’s going to come up is creating a DevOps culture, right? And ultimately at LeadingAgile we don’t believe that you start by trying to build a culture that a culture is going to emerge out of having a system that empowers the organization to do the right thing that puts the right priorities in place and so forth rolling out DevOps from a culture first perspective fails the same way as rolling out agile from a culture-first perspective.

The other way people tend to roll out DevOps is in a practices first way but ultimately those practices aren’t going to survive and aren’t going to thrive if your system the way your software is built, the way your teams are organized, the way things are orchestrated outside the teams if that’s not aligned and conducive to DevOps succeeding then then ultimately DevOps isn’t going to succeed.

(Introduction Break)

Matt VanVleet

Hi, it’s Matt here. I’m here with Rick and we’re here to talk about some things we’re learning about DevOps and how you roll it out successfully to an Enterprise. My background comes from the technical side where I’ve done DevOps, or the precursors to DevOps over the last 20 to 30 years. Where we wanted a team to have push button deployment, we wanted our software to be able to get to production quickly, and over time I’ve seen the challenges of it scaling and rolling out to an overall Enterprise. So, we started exploring why is DevOps failing. What causes it to not succeed, and you know at LeadingAgile we’ve had a similar Journey over the last 20 years with how Agile fails and why it’s hard to roll it out across an Enterprise. So, I got Rick here to have a conversation because Rick has spent years doing Agile Transformations and we want to talk through some of the parallels we’re seeing, some of the challenges we see, and some key points about how to successfully think about and roll out DevOps. Rick why don’t you talk a little bit about your background and what we’ve learned over the years about Agile Transformations

Rick Austin

Yeah, thanks Matt. Yeah something you don’t know about me, Matt, I grew up as a developer too. So even in the 90s we had systems that were doing continuous Improvement or continuous integration builds and things like that. So very old technology back in those days, so I’m certainly not on top of what’s out there today but I spent a lot of time doing Transformative work in a lot of companies. I joined LeadingAgile about 11 years ago and I’ve been doing a ton of work around Transformation for many years now and you know there’s just some core principles that we tie back to. If you’ve listened to any of our talks, especially for Mike, it’s you know, teams, backlogs working tested software. So, there’s some first principles we always tie back to, what gets in the way of those things happening, and I think you’re going to see that the system’s first approach for Transformation is also something that’s truly important for us to do from a DevOps perspective. And tying back to value your organization wants to provide for your customers and what are the things that are getting in the way.

How to Approach DevOps

Matt VanVleet

Yeah, so let’s talk about systems first versus practice first or culture first type approaches. When you’re looking at DevOps, a lot of times if you just Google DevOps, one of the first things that’s going to come up is creating a DevOps culture right? And ultimately, at LeadingAgile, we don’t believe that you start by trying to build a culture. That a culture is going to emerge out of having a system that empowers the organization to do the right thing and that puts the right priorities in place and so forth. So, culture-first DevOps, saying everybody should be worried about the end-to-end of getting their software into production, everyone should have collective code ownership, and everyone should just worry about it. Rolling out DevOps from a culture first perspective fails the same way as rolling out Agile from a culture-first perspective.

The other way people tend to roll out DevOps is in a practices first way. Well, let’s just go buy a DevOps tool, let’s teach people to write automated tests or automated deployments,  let’s just invest into the teams some skills to build these things but ultimately those practices aren’t going to survive and aren’t going to thrive if your system, the way your software is built, the way your teams are organized, the way things are orchestrated outside the teams, if that’s not aligned and  conducive to DevOps succeeding. Then, ultimately, DevOps isn’t going to succeed.

Rick Austin

Yeah, I would agree with that Matt because you know DevOps, and we’ve talked about this, is it’s seen as a kind of a practice approach. But again, if you don’t solve the things that are operating and creating impediments around those teams then you’re limited success right.

Matt Van Vleet

So, in the end, we’re not talking about a single team you know Rick from his background has implemented CI and Development I’ve done it you know before there were tools, we had an application, and we created a system called Smooth Production Updates which we called spew. So, we got this spew releases into production. But ultimately what it did was just automated the steps to get something in production so we could consistently deploy again and again and now there’s tools that do that that make that easy to automate and to scale.

But in the end, doing that across all of the teams is hard and getting it to be federated such that the things are coordinated with each other are hard so the first thing we talk about when we’re talking about assistance first approach to an Agile Transformation, and we’re starting to find the same thing maybe word is slightly different is needed for a systems based approach to a DevOps Transformation, is that you have to anchor on the goal there’s all these reasons you could be doing Agile. There’s multiple reasons you could be doing DevOps. They actually tend to be the same. Rick why don’t you talk about anchoring um to the business goal.

Anchoring DevOps to a Business Goal

Rick Austin

Yeah, so we see a common set of goals that—as you would expect—you know,  there’s quality goals we’re trying to investment, time to Market goals, and productivity; how can we create a Transformation that delivers more value to our customers? So, typically, when we work with a client that’s something that we want to get their opinion on. Why have you engaged us? Why is this thing called Agile something you want to adopt? And what are those business goals? Because then we tie everything back to those business goals. And I think another element of this and I’d like to get your thoughts on this Matt, is when we look at an organization especially a large organization where do you start right? How do you identify the area of the organization that maybe is most critical to your business? Maybe it has capabilities that provide the most revenue or cost reduction. How do you decide which slice of the organization to Transform? What are your thoughts on how to identify that for DevOps?

Matt Van Vleet

Right. I think we start with that goal. Let’s say that the goal was that we want to reduce the cost of getting releases into production. So, we’ve started down this Agile journey, or just the market is causing us to go from putting a release into production a year to 10 releases a year, or five releases a year. So, we’re releasing more often and if we keep doing that at the same cost um it’s going to actually cost more money. And if we can’t do that consistently it gets expensive and it gets very stressful on the organization. What we’d like is those repeatable tasks to go to zero and we can spend all our time building new capability, not managing releases going to production and so forth.

So, if I’m trying to reduce cost, then I’m going to start looking at where in the organization am I releasing the most often. Where is it the most painful to release? And what are the pieces of that right?  What you’re going to find is that there’s a lot of hops in something getting to production right. So, I get the code built and then I need to look at compliance. I need to look at quality and functional testing. I need to look at penetration testing. I need to look at do I have all the right approvals. And what we want is rather than each of those being a step in the process that’s inherently going to slow down our DevOps Transformation. How do we take each of those dependencies and turn those into services that now the teams can consume to say well I’m building code; I know that um we need to check for vulnerabilities. How can I just build into my process checking for those vulnerabilities such that it’s not something that’s going to be expensive and slow me down later? So, each of those things.

So, I’m going to start with what’s our goal what are the things where’s the where’s that goal going to be easiest to recognize so like where I’m releasing a lot where it’s very expensive and then look at each of the hops and then how do I turn those into platform services or into DevOps services that are going to make the overall system flow much better.

Rick Austin 

So, Matt, it that sounds like that all the services that are possible from a DevOps perspective, you would want to, so it’s a menu of things you can pick from. But you might, your roadmap to implementing those capabilities might change depending upon the goal that you’re trying to solve.

Matt Van Vleet

Right. So, if you think of that goal and then you have a set of features or epics that you could Implement to achieve that goal, now we can prioritize them. The benefit of taking this systems-based approach also is now I’m taking a slice through the organization, and I can have the business engaged because the business wants to reduce the cost of release just as much as the technologists. Or the business may want to be able to innovate and touch the market more often just as much as a technologist. So, now I can take these highly technical things, attach them to something that the overall organization can value. And now I can prioritize that alongside my features. So, it’s really critical to take that approach so that things can tie together, and the entire organization can embrace this. Because, in the end, it’s critical to being able to move at the speed organizations need to today.

Creating a DevOps Roadmap

Rick Austin

Yeah. It’s making me think about our approach for doing Transformation. Where we have this initial set of outcomes to help us better understand the business problems for an organization. What their challenges or impediments are. Helping us see a future in which they’re better aligned with their value streams for their customers. It sounds like that’s something we would also do in DevOps. What does the future reality look like and what are the steps you would take to get there? Because in Transformation, you know, some parts of the organization may need to have higher Agility than others. What are your thoughts about that for DevOps?

Matt Van Vleet

Yeah, I think that’s exactly right. So, the thing is you, it tends not to be that anyone in the organization is against doing DevOps. It tends to be that there’s five perspectives on where we should start and there’s a set of perspectives on how we should prioritize things. So, if I’m in charge of security, I want to make sure that security and compliance is in that pipeline and that we’re double checking to make sure that we’re not making things more risky than they were yesterday, right.

If I’m in charge of compute capacity, or in charge of cloud, I’m going to have a perspective on DevOps. If I’m in charge of packages, and updating our packages five times a year, then I’m going to have a perspective on what DevOps should be. If I’m in charge of custom development, I’m going to have a perspective.

So, I have all these types of constituencies that all want to move in this direction and what we’re doing is creating a thread saying well we’re here today what’s the most important thing we should do next, what are the set of things we need to do along that roadmap to get there, and then and let’s do that in a way that we can build on so that we solve more and more of our constituents problems over time.

Rick Austin

Yeah. It makes me think of our, you know, when we think, when we start to do Transformation, we start to lay out a roadmap. So, maybe there’s five slices of an organization that we need to Transform, but there’s a selection process we go through with the client to help understand what’s the first area. What’s the most important area to start with. Do you see that as something that we would want to do with DevOps?

Matt Van Vleet

Yeah, for sure. You know, because you know, ultimately, you know what we want, what we’re trying to avoid is either local optimums where this area invests a lot in DevOps and this area doesn’t. But both areas are required to get an application into production right. But and we want, and we also, you know, we can’t just spread our investment everywhere across the organization.

So where can we make the most progress? How can we then harvest that and learn for other areas of their organization? And how do we make sure that we’re achieving a business outcome and not just a technology outcome as we’re investing in these things?

Rick Austin

It feels like by understanding that we have a really clear sequence of events in which to implement that strategy. What do you think about how do we get feedback in implementing that strategy to make sure we’re adjusting as necessary?

Creating Faster Feedback Loops

Matt Van Vleet

Yeah. Ultimately, just like with an Agile Transformation, you can’t roll out an Agile Transformation in a Waterfall way, right. You don’t go and define this is what Agile is, now everybody go Agile and then let’s go test to see if we’re Agile, right. You’re going to do it iteratively and incrementally. You’re going to say here’s a slice of the organization, let’s figure out how to do better. Let’s install metrics so we get feedback about how we’re doing. And then we move to the next slice and so forth. So, we can constantly be putting things into a machine that’s continuously improving and learning.

For DevOps, it’s the same way, right. So, we’re going to start with this big goal. We want to reduce the cost of a release. Then we say, alright, we’re doing this slice of the organization, well how do we measure the cost of a release? How do we measure the latency so is it the number of weeks it takes to get from code being complete to code being in production? Is it the amount of man hours required in order to do that? And so forth. So, let’s get metrics to understand what we are trying to achieve, let’s then do a series of experiments and implement some things. Let’s measure our impact on those metrics, and then let’s rinse and repeat.

And as we see that now we started impacting those metrics, now we actually have the data to show that our investment is paying off. And then we can move forward and do that in other areas

Rick Austin

I love that. That really ties back strongly to Transformation because we’re measuring the fact that we’re moving across our plan as we expected. We’re starting to witness the skills and capabilities are becoming present in the organization. And then we have metrics to prove that the right things are happening.

DevOps and Agile Transformation Similarities

Matt Van Vleet

Right. And I think that it makes sense that an Agile Transformation and a DevOps Transformation take the same approach and require some of the same things. First of all, their origins are the same place, right. Ultimately, these practices came from people wanting to build things and create things in a in a way and touch the market and get feedback constantly. So, we came up with a set of technical practices and DevOps things we needed to do. We came up with these process things we needed to do. So, they all originated in the same spot. So, it would seem that there’s that commonality. And then, there’s just the physics about how organizations change. How do you you successfully roll out things across an enterprise? And if you don’t do it in slices, if you don’t have metrics to prove that it works, if you don’t have the right governance, you don’t have the right structure, if you don’t have the right metrics, you know, we’ve found that things aren’t going to succeed. And that shouldn’t be any different for a process change or a technical change. And we’re finding that these patterns just emerge. And we see the same failure modes of practices first in DevOps, or practices first in Agile. We see systems first working, you know in both. And so, you know, ultimately, we just don’t see that culture first and practices first is going to scale no matter what you’re rolling out.

Rick Austin

Yeah. I like how you tie things back to kind of first principles, and they all start from the same place. Which, you know, to enable this change in an organization, both of these, Transformation or DevOps, there’s a System of Transformation that we’re leveraging to make sure we have a clear journey to take the client on.

Matt Van Vleet

Right. I think, you know, in the end, like it all comes down to, and we talk about this a lot, you’ve got backlogs, you’ve got teams, and you’ve got working tested software. Now, the challenge comes in that we need those to succeed—and DevOps can help with that, and all these other process practices can—but now we have lots of teams, lots of applications, lots of code. And in order to scale that, you know, in the end, the dependencies are what kill you.

And with DevOps, it’s the same thing, right. We are looking at how do we automate away those dependencies. How do we make them consumable from a set of services? The dependency, instead of being this team needs to call this other team to get data, this team needs to call this other team to get compliance checked, or this team needs to call this other team to get functionality verified, or the team needs to call this other team to get standards checked. So, in the end, we want to do the same thing where we say if that dependency can be moved into the team room, so we don’t have to worry about it, great. But, if not, we need to figure out how do we orchestrate that in the lightest weight way possible. And that’s what DevOps is ultimately trying to do, it’s coming back to how do I break down dependencies because dependencies are what slows down any organization.

Rick Austin

Right. Yeah, so it’s just another tool in our kit to help us make sure we can create teams that have backlog, and they’re able to deliver working tested software.