Over the last decade, automation has become the norm for most organizations. And if they aren’t fully automated, they are going toward becoming fully automated. DevOps automates the process that connects development to operations, and now that DevOps tools are easy to get your hands on, most people want to be able to say they’re doing it. When you can get a tool to accomplish what it used to take teams full of people to do, and the cloud boosts that process even more, it can seem like a no-brainer to jump on the bandwagon so you can stay competitive and efficient.
In the end, DevOps is about getting your teams to get software out the door faster.
The trouble is that what we see in many organizations now is that they’re using DevOps automation because it’s “the thing to do,” rather than a thing to do that’s tied to a particular reason or business value. So it seems like everyone is doing the right thing, but the truth for many of these organizations is that they’re just going through the motions of these technical practices without a purpose.
It’s great to have a DevOps initiative. But what are you doing? Why are you doing it?
“Because we should do DevOps” is not a good answer.
Are you trying to get software into production faster?
Are you trying to reduce defects?
Are you trying to get your teams to work with fewer dependencies?
What you want to do is actually connect your technology to the real business problems you need to solve. Solve the problems you need to solve and then you can get ROI for adding this automation in the first place.
Without knowing your “Why,” all you’re doing is aiming for completeness. “We do DevOps.” That’s it? If that’s the case, then you won’t have any leverage to have future conversations with the business and leaders about why they should invest in more automation or technology.
Don’t Do DevOps for the sake of DevOps. Do DevOps for the sake of solving a business problem.
What Are You Trying to Achieve?
So when you want to take on a DevOps initiative, you need to start by figuring out what you’re trying to do. What’s your goal? What business value do you need to get from it? If you know what you’re trying to do and then scope your DevOps effort to that, you can begin to see the ROI you get from using technology to solve real business problems.
Here are the 6 most common DevOps goals we see:
Predictability. You want to reliably make and meet commitments to your customers, plus build trust with internal stakeholders, customers, and markets.
Quality. Ultimately you want to get the right features and functionalities released, reduce defects and reduce technical debt so you don’t erode trust and keep a good reputation with customers.
Early ROI. You want to be able to charge for the product sooner, and realize revenue faster. Usually this means building for automation and working in smaller increments.
Cost Savings. You want to release more at a lower cost and focus on real business problems that offer the highest value.
Innovation. You can’t innovate if you aren’t freed up to explore what works.Ultimately software development slows down as soon as you’re afraid of change. You want to make sure you’re always moving forward.
Product Fit. You want to know you are building the right product for your customers. To do this, you need to be able to get quick feedback and change directions quickly to suit any changes.
Coincidentally, these are the same goals organizations usually have for Agile Transformation.
Bridging the Technology-Agile Gap
In recent years as more companies begin to take on DevOps initiatives during Transformation, we’ve found that they’re increasingly constrained by a lack of people with the necessary skills to deliver the type of technical results required. So companies have to make the decision to slow down their Transformation and reduce business value until they can close the gaps between Agile Transformation and DevOps. But Transformations don’t need to be put on hold. There are other ways to solve the problem.
In response to seeing this, we created LeadingAgile’s Studios to address and close these gaps so our clients maintain Transformational momentum by maximizing both velocity and value while the business invests in its employees, grows, and continues Transforming.
How do we do this? We make shifts organizationally to ensure your teams are cross-functional and can work autonomously. But when you change your teams, your code doesn’t just change itself, you have to also change the way you write your code. The catch is that once you change your teams and the way you write code, you’ll have more dependencies. And if you want to be Agile, you have to manage those dependencies or break them. If you have unmanaged dependencies, you won’t have Agility, all you’ll have is continued chaos.
So to make Agile and DevOps work, we start by orchestrating and putting in compensating controls to start managing the dependencies until we can break them. LeadingAgile has a journey we put clients on with measurable steps through what we call Basecamps, a reference architecture in 5 incremental phases. When we move into the last 3 phases of Transformation, where the team is encapsulated and software is too, DevOps becomes easier because it doesn’t have to move the whole world to get one thing done.
We use Agile to stabilize the system we created to make all this work. But at some point there’s only so much you can do with organizational design, reducing batch size, and improving release plans. Unless you can start to remove dependencies and have teams operate autonomously, you are only as Agile as your dependencies will allow you to be.
Aim Toward Outcomes
Ultimately, if you want DevOps to work and you want Agile to work, both of them need to be aimed at solving real business problems. Doing either one just because it’s the thing to do will not get you where you want to be. DevOps is only as valuable as the outcomes you get from it.
