Five modern delivery missteps
Five modern delivery missteps
Insight

Five modern delivery missteps

What's slowing your adoption of DevOps and Agile on the path towards becoming a modern delivery organization?

Enterprise IT used to be the folks who kept the lights on. Now, they're increasingly being asked to move at the pace of product companies. Based on our work with hundreds of the world's largest companies, KPMG offers insight: “What makes it difficult for enterprise organizations to gain agility, to accelerate? What are the top five missteps?”

Watch this video presentation by Mike Wolf or read the transcript below to explore common struggles on the path to becoming a modern delivery organization. 

 

Modern delivery for the modern enterprise

 

 

Video transcript

Mike Wolf, managing director, KPMG LLP

Introduction

The business world is under increasing demands for agility and speed. The advancements in technology have pushed it forward to its edge, but the business still really isn't getting the speed that they wanted. Agile dates back "the manifesto" to about 2001, and then through that period of time that was before the cloud, before things like AI, before technology had embedded itself into everything that we do. Then about 10 years later, in about 2011, we have the term "software is eating the world" as setting the establishment that what we called digital, then was such an immediate prominence.

Now in 2018, with the advent of DevOps and scaled Agile and product centricity, we're no longer living in a world where there's a technical strategy and a business strategy. There's only a strategy. Now, not only is "software eating the world" but "software is eating software". With things like DevOps, and DevSecOps, and all the automation and the DevOps pipelines that are driving that, and the move towards microservices, and the cloud and serverless—this is really pushing to the greatest extent that automation can do.

However, the business still isn't moving fast enough, because we're seeing these as point items, point categories, or “components”. Really, the shift is shifting towards a modern delivery culture, where this culture of the organization sees Agile, and DevOps—and all these advanced technologies—as technical approaches that need to be combined to really get the complete value out of this.

Why is that? The enterprise IT used to be these folks who kept the lights on.,  Now, they're increasingly being asked to move at the pace of product companies. They want you to innovate and move at the speed of somebody like Google or Netflix. They want you to pivot and change your entire business the way that Microsoft or Intuit might, but these are the same people who were keeping the lights on previously.

What that means is the new legacy, the new tech debt is actually culture, its org model, its capabilities, it's your people. And all these things have to come together to shift to yourself to a modern delivery culture. So, working with hundreds of the world's largest companies, we sat down and said, “What are the top five blockers that make it difficult for these enterprise organizations to gain that agility, to gain that velocity acceleration? What are the top five missteps?” We assembled these all together. I want to talk to you about if what we've seen are the "anti-patterns" that people hit, or the struggles.

Let’s start with number five.

Misstep five: A misunderstanding of language

Number five misstep is a misunderstanding of language, because language is important. We know that in our own interactions. You would see a sign. That sign might not be what it means until you understand the complete context. The exact same thing is the case with DevOps and Agile. Gaining this common lexicon, this common language amongst the business and IT, is crucial. I often use the great quote from [the character] Inigo Montoya from [the 1973  William Goldman novel/1987 movie] The Princess Bride. "You keep using that word. I do not think it means what you think it means." I have the business saying "DevOps", and I have the IT saying "DevOps" but they mean almost entirely different things. I've seen it used as a verb. I've seen it used as an adjective. I've seen it used as a noun. I have a customer who thinks that DevOps is literally "development", the entire end and life cycle of development.

Now, why this is a problem is when we're now talking about things like epics, and story points and releases and pipelines? What that means to that different audience is really crucial. So that that way, the development, IT, operations and the business are on the exact same page. To do that, what we found is we need to get to a common language and a way communicate that. We've used things like storyboards, and workshops, and creating dictionaries and lexicon so that we can all make sure that we're on the same page. We're communicating in the same way and that the business understands the IT just as the IT is understanding the business. We're at this great nexus point where increasingly technology is becoming more and more understandable on commodity, while at the same time, IT is understanding they need to understand what drives the business.

So, that's number five. Let's jump to number four.

Misstep four: Not picking the right metrics 

Number four is not picking the right metrics that change the behavior of the organization. What I mean by that is we're increasingly having these different methods for creating objectives. We're seeing the influx of OKR from people like Google, driving into the enterprise as a way to set these top level objectives. But what is an objective for the business might not be the objective for IT. IT is talking about things like SLOs, and SLIs and SLAs. All of these things need to then map to what is the business objective. The business does not care that you released things faster. The business cares that you satisfied needs faster, that you went to market. You did it with safety. You did it with quality, and that they can see an impact in the market. These are not in congruent. They're actually the same goals. It's a matter of coming to those same objectives that you can track against.

If you don't, then you're going to end up with what we call "the frozen middle". This is middle management who says that they are achieving the goals of the transformation. "Look at my colors, they're all green. All my indicators point I'm doing the right things." Well, because no one did value stream mapping to figure out what were the valuable things, no one set a common set of OKRs between the business and development. It's very easy to say, “But look, I'm doing the things I'm supposed to be doing and still make no impactful change.” In part, that's because there's a misunderstanding behind the two sides of what their goals are. Development might say, “I need to have less tedium. I need to be working on more important things. I need new skills, more consistency, higher quality to stop redoing the same things. I need more releases so that way I can enable that. I need all these tools to do it."

The business might be saying. “Actually, I think I've a redundancy in resources. I think I need to maybe do some vendor management so I can have a bit more flexibility. I need to do insourcing, taking some of this work that I could have been doing outside but now that I've removed tedium, maybe I can do some of that stuff that I've used a vendor for and now I can do inside.” These things aren't incongruent but there's so much fear and anxiety understanding those that you really need a partnership that doesn't see this as "going over the edge" from one to the other but sees it as a common understanding, common language, common discussion points to make that happen.

That brings us to number three.

Misstep three: It's not just about the tools

I think that one of our greatest strengths that's pushed DevOps forward is that it came out of a development and operations culture where we live and die by tools. However, that also makes us more likely to jump to the great new tool, the great new solution to move it forward, and it's not just about the tools the enterprise. It's about how you integrate them, how you align on them. I think one of the biggest underestimated undertakings is what's required to bring these tools into the enterprise. You see the complexity in a large organization of bringing in any of these tools and often may take six months or more to pull one in. Well, this culture moves so much faster than that, it's nearly impossible for that to keep up.

We underestimate the difficulty of tying those together in a large enterprise. A lot of these tools were born out of startups and large product companies, the complexity of tying those two legacy systems. Then it's on us. It's on us the developers, on us the IT people, that we jump to that being the solution. We're so quick to say, “But, I put this in place, why isn't it doing?” but I've done nothing to change the culture. I've done nothing to align my group on how to use these tools actually do the things I'm doing. I just said, “Well, I got a tool.” and that's really a short-sighted misstep.

Furthermore, we also missed tool gravity. I often see organizations that will have three instances of a source code management system, three instances of kanbans or issue tracking. The real value here is tool gravity. If you just think to yourself, “How many chat systems do you have that you use on a daily basis to communicate with your friends?” Where you actually see the value there is when you start unifying those and get some tool gravity. We have a common use space, a common understanding, and now how you use those things and I've got all my team in one place, the tool gravity is really crucial in the enterprise.

So, now we're down to number two. Number two: We're almost there.

Misstep two: Ignoring the left while you're shifting left

"Shifting left" is a construct that came out of the testing world. How can we take things around quality that we're occurring at the end of a process and shift that entirely to the left? How can I use DevOps to do things that are highly automated to do continuous testing, to do my CICD, to do my deploy? How can I automate that stuff so I can get releases out faster, so I can start to do the testing earlier?

The great shift left, as we've been referring to it as, because you're doing that, we're using all of this automation do it, we now need to concentrate on all the things on the left-hand side which are nearly impossible to automate. That is product management. That's financing. That is design thinking, etc. All that shift left has to occur and that's a lot of work. It's a bit of a tectonic shift for an organization to say, “All this design thinking stuff, I talked about, now I need to do it. I need to do it to drive requirements. I need to do it to drive business value.”

Things like the Spotify model we’re coming up about, how it can shift a product centricity. All of these things are now enabled that the business can do them because I've removed this tedium with automation. Now, I need to concentrate on that left-hand side. There's a good reason why enterprises have difficulty with this shift. We put a lot of things in place to bring down the risk, to increase the safety, increase the consistency. Things like architectural review boards or CEOs or change approval boards. All of these things have a good purpose, and they were to reduce the risk. They were to increase the quality.

However, that's not incongruent with what we're trying to do with modern delivery. In fact, it actually improves the quality. It reduces the risk because all of those things that were in boards, now of a sudden are documented in code as actions that I can audit against, that I can race against. I can make sure it happens. However, that's a big tectonic shift that the business has to accept—that this provides value to do, including testing as part of that which we know but also shifting risk and security as a component of that.

Now, let's say we do all these things. People are aligning themselves of these goals at the end of the day if I don't shift where people literally sit, who they report to, how the organization is operated, then I'm still going to have the same bad behaviors of who I report to and what my goals are. This is the natural next move from shifting how the work is done to shifting where the work is done and then where those people report to. I think people miss the opportunity to do organizational change while they're doing it. Now, if I had to pick one of these things that is the rock to put at the beginning of the stream, that really segments the change down the chain, it's finance. If you want to see how an organization really works, follow the money back to how they fund projects.

In fact, the mature organizations are changing from funding projects to funding products, and that change changes not only how you fund but it trickles down the whole organization of how the work is done, who that people are and what they do. I think that is a crucial top level change that needs to undergo, that aligns you closer to the way that startups and ventures work from a traditional enterprise of long term multi-year budgets.

Now, we're at the top one. 

Misstep one: Lack of leadership and team alignment

The number one, top of the list with a bullet, misstep or anti-pattern is a lack of leadership and team alignment. That is a number one thing that stagnate it’s progress. If you can make that change to having a transformative leader, that will be the number one blocker that you can remove to push a DevOps forward and modern as a culture to align everything to. There's a good reason for that. If you think through all the things that I talked about. I talked about product alignment. I talked about technology. I talked about organization. I talked about finance. I talked about the difficulty of bringing tools, common language and culture and understanding and goals. If this is done in silos, done in pillars, you will never achieve the agility you want. It's going to take a transformative leader, a servant leader who is going to make that change to align the entire business to break down the firewalls to make this happen.

Conclusion

So, there you have it, five things that you can do today to make an immediate impact on moving your solutions faster with less risk, more safety and security, to make your entire organization successful while satisfying the increasing expectations of your customers and employees for your products and services internally and externally. Now, the job is on you to change how you work and not just what you work with. If software is eating the world and DevOps is software eating software, then I challenge all of us to build a modern delivery culture that drives this change to make us all successful.