In this DevOps Chat, Akshay Anand, ITSM product ambassador at AXELOS, and David Crouch, senior advisor at Beyond20, join Mitch Ashley to share best practices and learnings from introducing and adopting Agile and DevOps in large organizations. Akshay and David discuss overcoming change management challenges and obstacles to increase adoption.

Transcript

Mitch Ashley: Hi, everyone. This is Mitch Ashley with DevOps.com and you’re listening to another DevOps Chat podcast. I’m joined by Akshay Anand, who’s product ambassador with AXELOS, and David Crouch, who’s a senior advisor at Beyond20. Welcome. Good to have you on, good to be talking with you.

Akshay Anand: Thanks for having us.

David Crouch: Thank you.

Ashley: Great. Would you first both start out – let’s do a little bit of introduction just to introduce yourself, a little bit of what you do and a little bit about the company that you’re with, if you want to start Akshay.

Anand: Sure. Yeah, my pleasure. Thanks for having us, as I said. My name is Akshay Anand. I’m the product ambassador for ITIL, working for Axelos Global Best Practice. Axelos was a company that was formed about five years ago as a partnership between Her Majesty’s Government and a large private sector company called Capita. We like to think of ourselves as the custodians of best practice bodies of knowledge, not just ITIL. We also manage PRINCE2, which is our project management, MSP which is Managing Successful Programmes, which is our program management, and a few others besides.

Before joining Axelos I was a consultant for most of my career in the IT service management space across both the US and the UK. I spent a couple of years as the head of service management for Macmillan Publishing as well. And that’s me.

Ashley: Great. David?

Crouch: Hi. My name is David Crouch, affectionately called Lower Baltimore at the office because that’s where I live and where I’m coming to you from right now.

Ashley: [Laughs]

Crouch: It doesn’t come with a _____. I spent about 20 years at Johns Hopkins University and Hospital before coming to Beyond20. Finished my time there working in the IT solution center which was our service management center for excellence. At Beyond20 we are a company that focuses on digital transformation. At the core of it we really try to improve the way people and organizations work by looking at their digital transformations and looking at how to improve their IT service management processes. We do consulting work, we do training, and focusing on ITIL but also project management and Agile and DevOps and these other areas as well, and we also have a team of folks who implement IT service management tools.

Ashley: Excellent. Perfect timing for our topic today. So let’s kind of jump into that. We’re talking about Agile and DevOps and ways that that’s introduced into companies’ best practices, learnings from adopting or not [laughs] those different practices. Maybe we can start with how we introduce or you’ve seen companies introduce either Agile or DevOps or both into organizations and kind of thinking probably larger organizations where there’s more change management involved. I imagine that’s a lot of work you get into, David. Is that correct?

Crouch: It is. You know, we see a lot of organizations who know a little bit about DevOps and a little bit about Agile but haven’t really adopted an Agile mindset and don’t really have the full understanding of what organizational structure can really support DevOps, and yet they need these things to really support a digital transformation. So typically we’ll start with doing some sort of assessment to see where they are now to see what pain points they have right now, and then try to figure out, okay, does it make sense to introduce Agile, where does it make sense to introduce DevOps, and how quickly can that be done or how gradually do we need to introduce these concepts?

Ashley: How about you, Akshay? I’m sure you worked with plenty of organizations that have introduced this and gone through that process.

Anand: Yeah. I’ve actually seen broadly two major patterns. The first being where the organization transformation is driven top-down, so it’s usually a board of directors or whatever governance structure says, “Look, you know, this is the vision of what we want the company to be,” and the senior-most leadership team says, “Well, in order to be able to do that we need to be able to iterate faster, we need to be able to have much more of a focus on pushing out digital products and services,” and that change then percolates through the rest of the organization, so very much a top-down thing. The other major pattern that I’ve seen and experienced is where you might have a small team who with the help of let’s just say a more enlightened manager is given the freedom to start to experiment and innovate and change ways of working while sort of at the same time remaining compliant with the rest of the organization’s policies and what have you, and they’re able to demonstrate improvements in either efficiency, productivity, experience, whatever it might be, to the point where the rest of the organization says, “Okay, so what are these guys doing and what can we learn from that and how can we start to pick up some of those changes ourselves?”

So in a way at that point, it’s a branch, that sort of new ways of working or new principles of working start to diffuse horizontally, so there are other sorts of teams, engineering teams, operational teams, et cetera, who start to think and work in those ways. Or it could be that the stories of that change percolate upwards, where the middle management or the senior management say, “This is interesting. Are other organizations doing something like this? Would it benefit us to roll this out a bit wider and give it the sort of support and evangelism and investment that we need in order to create a larger change?” So that’s the sort of branch, but broadly it’s two parts—top-down, bottom-up.

Ashley: You know, I think one of the biggest challenges with introducing any kind of fundamental change like Agile or DevOps is sort of crossing that chasm between saying we’re doing it and kind of really truly embracing the spirit or the concepts or the culture of it. Have you found that also to be true?

Anand: Well, yes there’s a difference. The way I reconcile this difference perhaps is in the following way and David probably has a completely different experience from his vantage point but for me one of the biggest challenges that organizations face or at least let’s say practitioners face, and then I’ll come to organizations—one of the things that I think practitioners are challenged by is in a way thinking that everybody understands things and just gets it. Everyone understands why we have to be Agile. Everyone understands why DevOps is important. And the truth of the matter is not a lot of people understand that and even if they do understand the words they don’t necessarily understand the implications to the rest of the organization.

So there is a little bit of this need to manage upwards, need to manage outwards to be able to champion the need for that change, the need for these new ways of working. The other thing which I think organizations and practitioners are challenged by is understanding where these new ways of working will succeed and where they would not succeed, and this is some of the things that we do actually talk about within the sort of ITIL 4 library of guidance that digital transformation or these new ways of working are really important, yes, but in a certain context they can be a hindrance rather than a boom, and organizations need to understand where these sorts of things can work. If the work that’s being done is highly predictable or has very long cycles of work and feedback then perhaps trying to break it down might only go so far, but if you try to overengineer or impose an Agile way of working you might actually end up doing more harm than good, even though you’re starting out with good intentions.

Certain things, to put it bluntly, don’t care how the work is being done. Once you start reaching the level of governance or supplier management or whatever it might be, in a way yes the CIOs today might say, “DevOps is really important, Agile is really important, et cetera,” but if you press them about what exactly is being done – look, I just say based on my conversations with other leaders I understand this is important, but the exact mechanics of how we’re actually going to execute on this I leave to the team who’s actually doing the work. So you’ve got to understand that change is difficult. The further up you go in an organization the harder it is going to be to try to convince somebody about the nitty-gritties that need to change, and you’ve got to be able to understand your audience, understand what they need to hear, understand how to convince them, and that aspect of communication is one of the critical components of organizational change management. It’s one of the places where I see the failure of organizational change management most commonly occur.

Ashley: Interesting. How about you, David? Share some of your experiences.

Crouch: You know, I think some of the more challenging but also more interesting from the consultant point of view situations are dealing with some companies that have been around for 80, 100, 150 years, and then I think folks pretty much around the globe would know some of these companies and they’re very mature in some respects. They’ve built their brand over time. But then when they start to suddenly – you know, some of them suddenly wake up and realize, “Oh, wait a second. We have gotten out of touch with what our customers really need, our external customers really need and what they want, and there are competitors that we never even dreamed of before that are entering into our space.”

They suddenly wake up and realize not only do we need new products and new services but we also need to work in a different way to produce those because customers change their mind a lot, customers are fickle, and I don’t mean that in a bad way. We want to understand what our customers need. And then the challenge becomes, okay, well if we haven’t been doing this right now it’s necessary but not sufficient just to provide training in these areas. Training goes so far. That’s very useful, but then also where are we going to have an area where doing something like Agile software development really makes sense?

I worked with an organization where any of what are often referred to as systems of record, so these are internal systems that keep the company running, their software team was actually doing a fairly good job because they worked in a relatively Agile way. It wasn’t 100 percent of what you would describe as Agile, but it was pretty darn good. And yet they would often run into roadblocks when they got into the more, for lack of a better term, traditional change management or as we call it these days change engagement processes where they were actually analyzing risk and managing risk all throughout the process because they were doing an Agile approach, and yet sometimes they would have this long delay at the end of the process when they got to their change control board in that company.

On the other hand, that company almost overnight experienced some significant financial losses and significant layoffs and they very quickly needed to develop some, what we call, systems of engagement, systems and tools that their third-party paying customers would use and would purchase, and in that case, the organization bypassed their internal IT entirely and just went to a third party because the third party really was already doing some version of DevOps in that case for years. Then the question becomes does their existing IT shop still have a reason to be? The answer, in that case, was yes, but it becomes very difficult because if you tried to apply that to the entire organization, particularly overnight, I don’t think it would’ve worked very well.

Ashley: Oftentimes in those situations, you also see people _____ project if it is an internal group just to try to isolate it and minimize the overall organizational reaction. Some people call them the corporate antibodies that tend to kick out and respond to change.

Anand: SIt’s interesting you say that, Mitch. What I’ve also seen though is that can also work but it has to be done very carefully because – who was it, which book was it? I think Geoffrey Moore – was it Geoffrey Moore? Yeah, I think Geoffrey Moore wrote an entire book about this phenomenon, a book called “Zone to Win,” and what he was talking about in that book with numerous examples, which I’m sure we’ve all experienced, is that skunkworks, that innovation lab does really well as the innovation lab, but the moment the organization says, “Okay, how do we now scale this new innovative feature, this new innovative product and industrialize it to the point where we can offer it to our thousands, millions of customers,” that’s when it falls down because you’re changing the constraints within which a product exists, if you will. It no longer exists as a small experiment measured in terms of success as an experiment.

It’s now got to be able to stand up to the measures of being like this industrialized product or service. So if you’re moving the yardsticks, is your product capable of actually bridging that—moving across—I don’t want to use the word bridging the chasm—is the product actually capable of moving across into that industrialized state? And what we’ve also seen through some of the research that went into ITIL 4 as well is a lot of organizations failed to make that bridge between that innovation lab and the industrialized operation.

Ashley: I appreciate you sharing that too. It could happen very well to the external group that gets formed as well. How do you reintegrate that, repatriate it back into the organization?

Crouch: And there’s a Harvard professor that famously kind of describes some digital transformation experiments as kind of like attaching a speedboat to an aircraft carrier. You know, they move at different speeds, and although the speed may go really fast, try to get that to translate into the aircraft carrier. It’s probably not going to happen. So it becomes—you know, the challenge is do we do a proof of concept, which sounds like an experiment to me, but if we do that can we really translate that into larger organizational success? And hard to say to come up with a definitive answer, but for larger organizations I think that what I’ve seen is that it’s been very difficult for them to do that successfully, so they have to find other ways of doing it.

Ashley: There’s a lot of things you can look at. You can look at sort of historical what’s worked, what’s failed in the past, you can look at—I call flow—what is the momentum of the organization? Are we a metrics, are we a finance, are we—what are decisions driven by? One of the things that can also help with that is also alignment. It’s why are you introducing Agile? Other than this being an IT fad, which it’s not just that, but it could be just for that reason.

Usually, it’s not a great reason to introduce it. You’ve got to have some real true business drivers like your example, Akshay, of we’ve got to respond to these things in market, right? The customers’ expectations have changed. That creates a sense of urgency but also purpose, like what are we trying to do differently and why and then how do we apply this?

Anand: There’s an additional wrinkle or complication, if you will, for publicly-listed companies as well where they’ve got to report certain metrics, and if you look at any company’s quarterly filings or annual filings where they talk about the year ahead or the quarter ahead, they are using certain types of metrics to communicate their direction and their results to their shareholders, to the market, and you might say, “Look, these measures are no longer relevant for what we’re trying to do or for where we’re trying to go,” but then what does that do to the company’s confidence as a shareholder? The example I cite is when the New York Times tried to move to the digital subscription. You can’t translate print subscribers into digital subscribers or engagement.

How do you measure the success of the digital engagement because you’re not delivering hard copy newspapers anymore? But the investors were used to seeing those sort of subscriber accounts and subscriber churn and all these sorts of things as forward-looking guidance. So there’s an additional complication from a governance and a reporting mechanism, especially if you’re a publicly listed company, and that’s why people like David have so much fun going into these companies trying to help them figure out, well, it’s not just about changing the ways we’re working; how do we educate our peers, how do we educate our managers, how do we educate our suppliers, how do we educate our consumers, how do we educate our shareholders? There’s all these different stakeholders. It’s not just about changing the way your software development is done. It has massive ripple effects across the ecosystem.

Crouch: Well, and what’s really interesting about like New York Times is that they were still successful with their print publication, one of the few, when they began their digital transformation. So you have a tremendous amount of courage to be able to say as the leader, “You know what? We’re successful now but this is not going to last. We can see it in the marketplace. So what we actually need to do is intentionally set up a parallel operating model and say we’re going to move in this new direction.”

And that means that that’s in their case going to siphon away, intentionally siphon away over time the way we do business now and it’s probably going to hurt in the meantime, and we’ll use any of the profits from our existing model to move over to this new model. But gosh, if you’re an investor you have to be pretty nervous about that unless you’re really in it for the long term and you say, “You know what? They’ve seen this and other companies have tried this; how do I know that New York Times is going to be successful when some of their peer publications have not been when they try to do this and for a variety of factors?” It seemed to work for them but it’s pretty daunting.

Ashley: That’s what I would call the disrupt yourself before you’re disrupted model, right? Because usually it’s much more painful when you’re reacting to someone else who’s coming in and taking market share or whatever. That’s a really good example too of in the print media going into digital, it’s not the same product, it’s not the same consumers, it’s not the same behavior. The market really has changed, or maybe you’re just really going after a different market who would never now buy print but they would just use that example.

So a lot of it can be driven by those things that we’ve answered about strategy or understanding of the market or shift’s that are occurring and tie those reasons as part of why we need to create software faster or why we need to create it in waves of some smaller increments to be able to respond to really rapid shifts or experiment in market. That’s another great reason to do that.

Anand: Absolutely.

Ashley: Well, talk a little bit about—you mentioned the speedboat. I can just imagine it tied to the aircraft carrier, kind of sort of like the fly tied to the string, right? How do you start to introduce speed into a larger organization that has a lot of momentum around the way they’ve been doing things that’s worked for them probably very successfully? How do you start introducing something like speed to say, “This is super-critical and here’s how we’ve got to operate now?”

Crouch: I think it starts with trying to understand what they’re primarily trying to do. Where does having more speed make the most sense? So it could be we’re in a consumer marketplace and the customers are changing their minds a lot and there may be a way to develop something more quickly to respond to that need or in the perfect world to actually kind of predict and shape that demand for the great digital masters. On the other hand, some companies may say, “Well, maybe we’re not in a strictly business-to-consumer marketplace but we need to increase operational efficiencies in some areas,” and so maybe speed is more important there. And then for a few companies out there it may be both, right?

It may be if we increase operational efficiencies on the inside of the company we can also drive the outside third party customer, and that’s no easy way to do that, to figure out where speed is going to be appropriate and where doing things quicker might actually get in the way in some cases. Akshay, I don’t know what your experiences have been there.

Anand: I mean, look, there’s a lot of great organizational change, organization design, literature out there for people who want to read up more about this sort of thing. The Satir change model or Kotter’s Seven Steps or whatever else it might be. In my experience, one of the first steps I’ve seen in any successful change is – to use Kotter’s language – creating a sense of urgency. I guess this is something I remember from my time living in the US. Wasn’t there this sort of tagline that the first step to recovery is admitting you have a problem or something along those lines, right? So it’s kind of like that.

The first step towards creating a change is to acknowledge that you need to change, because once everyone acknowledges that you need to change you can start to think about, well, what sort of change do we want to have? And this has to be a highly collaborative effort. It’s not just your CXOs locking themselves in a conference room at a resort for two days and whiteboarding this out. This has to be a truly collaborative exercise across the entire organization. There may need to be some constraints that are in place, and what I’ve typically seen is a board of directors might say, “Look, this is where we want to be five years from now,” not necessarily saying how that needs to be achieved but saying this is where we want to be.

That in combination with creating that sense of urgency says, “Look, if we need to hit this sort of a target we need to be able to develop software faster or close out outages quicker or have a more Agile procurement process or whatever else it might be,” and that’s when you start to identify these sort of strategic and tactical initiatives. Because you’re working collaboratively you’re dispersing that cognitive effort, if you will. So it’s not just somebody from one particular vantage point saying, “As a CFO I think we are giving away too much money so we’re going to be cost-cutting only.” That’s a singular perspective. But once you distribute perspective you can then say, “Right, if we are supposed to meet this we have to change here, we have to change there, we have to modify that,” and so on.

For me that is the essential first two steps; create that sense of urgency and then distribute the cognition of what needs to change. Create that collaborative series of committees, councils, call it what you will, that will help you identify in different areas what needs to change, and then you start investing to execute on that series of tactical initiatives or programs of change.

Ashley: When I first learned about change management—David, maybe you can comment on this—we used the phrase “the burning platform.” What’s the burning platform that we’re on that’s forcing us to change or really compelling us to make a change? It can be as dangerous as are we going to exist but also it could be here’s why a two- or three-year strategy makes sense. Let’s not just communicate this strategy; let’s communicate the why.

What’s changing? What evidence do we have of this? What do we want to get ahead of or prevent ourselves from experiencing? Have you seen that as a successful strategy for helping create that burning platform or at least the sense of it?

Crouch: I think so. I mean I think the top level of support from the leadership is absolutely critical, but when it comes to defining the problem getting down to as specific as you possibly can. It’s not just a matter of we’re not getting new products out to customers quickly enough or it’s not just a matter of we’re not implementing enough infrastructure changes within a certain period of time. It’s a matter of exactly what about that isn’t going well and why would improving that be made better? In some cases it’s obvious. In some cases, for example, it’s not so obvious, and when people think of Agile and DevOps one of the first things that comes to mind is speed, we’re going to get more speed.

That’s an important part of it. It’s not the only reason why you might use some of those techniques. To use a simple example, if I need to be at the theater for a show—not these days—but if I have to be there at 7:00 PM and I only live 15 minutes away, driving faster won’t necessarily improve my results. I get there—it still doesn’t start until 7:00 PM. If I get there at 6:00 PM I guess I get a good parking spot. So speed is just one element, but think about with Agile doing things in smaller iterations, controlling the risk, controlling the scope. All of these are considerations in addition to just speed.

Ashley: What –

Anand: And the other thing that I think the research shows us—sorry, I didn’t mean to –

Ashley: No, no. Go right ahead, Akshay.

Anand: I was going to say one of the other things that our research has shown us as we’ve been working on ITIL 4 and other bits and pieces, even frameworks like managing successful programs and so on, is organizations need to figure out the right duration of their strategy cycle. Now if your company is a two-person company then maybe your strategy cycle is measured in days or weeks, all the way up to if you’re the government of India and you’re trying to manage—not manage, but govern one-point-how-many-ever billion people then your strategy cycle is likely to be measured in years, if not decades. Well, hopefully not decades. So I think the other aspect that we’ve seen, at least in typical organizations, strategy cycles have gone from being sort of this thing that happened every five years to maybe things that are happening every three years because the world’s changing too fast for a five-year cycle to make sense.

We may see a point where three-year cycles are deemed insufficient and we need to move to two-year or one-year cycles. But that’s the other trend that we’re also seeing, that strategy cycles themselves are reducing.

Crouch: I’ve seen that a little with managed service providers, for some of the managed service providers. Even one year seems to be an awfully long time for some of them, you know? So there’s this kind of blend between are we talking about strategy or tactics here, but I agree; the timeline is becoming shorter and shorter it seems.

Ashley: It certainly has, and of course our current COVID situation, I’ve seen some resource. I know some of the sources of this, but some have said, “We’ve accelerated as much as six years in our digital transformation strategies in the last six months.” Probably not everybody has, I imagine. Well, this has been great talking with you both. I know you mentioned, Akshay, Geoffrey Moore’s book “Zone to Win” as a great resource. Any other resources on introducing Agile and DevOps or on change management that you guys can think of might suggest?

Anand: Well, I think I would be very remiss if I didn’t actually mention ITIL 4, which is the product for which I’m an ambassador.

Ashley: That was a setup question.

[Laughter]

Anand: Easy question, though. So look, there are a couple of really good books in ITIL 4 which talk about this. Two books in particular that I’d like to highlight. The first is “High Velocity IT” and the second is “Digital and IT Strategy.” “Digital and IT Strategy” actually does refer back to some of the content in “High Velocity IT.” “High Velocity IT” is more focused on the tactics and operations aspect of introducing these new ways of working and managing the changes and the implications therein to the rest of the organization. “Digital and IT Strategy” is more about the governance and strategy and the interface to tactics, so it’s about how do you determine what’s the appropriate business model, how do you create a change in your business model and from that create a change in your operating model, from that figure out where Agile and DevOps make sense and where it doesn’t make sense and so on.

So it’s very much the sort of top-down but the leader’s perspective of things, whereas “High Velocity IT” is the practitioner’s perspective of things. I think those two would definitely be really good. I’d also plug a couple of books like “Team of Teams” I think is really an interesting read, talking about how especially in an organization like the US Army, which you would typically think is very large and flexible and so on, how they were able to create that kind of a change, not necessarily with software development but around ways of working from across multiple teams, across multiple time zones, so that’s also a really good book to check out.

Ashley: Yeah, I’ve not read that book but I’ve heard it’s good. I think it’s by Stanley McChrystal, right? General McChrystal?

Anand: That’s right.

Ashley: Great author. I think he uses his whole military experiences, examples of that, so I’ve heard him speak about it. How about you, David? Any suggestions?

Crouch: I would just say that, you know, as one of the authors of the ITIL “Digital and IT Strategy” book I’m going to put in a plug for that. I’m just a little bit biased, even though it probably took several years off of my lifespan to help write that—I’m kidding. But no, that’s really talking more about the strategy side of things. I recall reading an article years ago as part of one of his classic books. Michael Porter talked about IT is not strategic, and I struggle with that. I agreed kind of at the time and now I don’t know, and I think if IT is now strategic in this era of digital transformation it really comes down to things like high velocity IT to DevOps to Agile to some of the techniques that we talk about in the “Digital and IT Strategy” book and “High Velocity IT.” You know, I would suggest reading that.

Anand: There’s probably a couple of other plugs to make just before we go, sorry.

Ashley: You bet.

Anand: For those who want to read a little bit deeper into some of the more cutting-edge, I would say, thought leaders, read up on Simon Wardley, Wardley mapping and his whole strategy cycle stuff. He publishes that on his blog. There’s tons and tons of material on his blog, which I think he started condensing to a series of medium articles. But there’s also YouTube talks that he does. Amazing stuff. And the second is Dave Snowden and the Cynefin framework. It’s getting a lot of attention in the Agile space especially, but it’s a decision-making framework. It’s a sense-making and a decision-making framework and it has applications from business strategy to project management and everything in between, and I think that’s another –

Ashley: Excellent.

Anand: – at the moment cutting edge but hopefully a soon mass-market approach.

Ashley: Oh, those are some fantastic resources. And maybe a parting thought for all of us is I don’t know if IT is strategic but I’m pretty sure software is strategic these days that’s driving – really fueling our digital transformation.

Anand: Absolutely.

Ashley: So a topic for another conversation. Well, thank you, gentlemen, Akshay Anand, who’s product ambassador of Axelos, and David Crouch, senior advisor Beyond20. Thank you so much for sharing your experience and your thoughts on this topic. I’m sure it’s been really helpful.

Anand: Thanks for having us, and to the audience, you can find me on Twitter @bloreboy if you care to follow me, and I’d love to hear some feedback either through Mitch or directly, however you’d like. I’d love to know what you thought about what we were talking about today.

Ashley: Wonderful. Happy to do that. And I’ll pass that along if we do. David, do you want to share any contact information?

Crouch: Yeah, same here. I’m on LinkedIn. A slightly younger, bow-tied version of myself is on LinkedIn. Feel free to connect with me. Certainly visit our blog at Beyond20. We’re always writing articles, trying to grapple with some of these issues, changing our mind some of the time, but you find a lot of what I write there.

Ashley: Excellent. Well, we’ll look forward to talking with you both again soon. Take care. Have a great day.

Anand: Thank you.

Ashley: You’ve listened to another DevOps Chat podcast. This is Mitch Ashley thanking everyone for joining us today. Be safe, be careful out there.