Skip to main content

Don’t Do DevOps Just So You Can Say You Do DevOps

Reading: Don’t Do DevOps Just So You Can Say You Do DevOps
Don’t Do DevOps Just So You Can Say You Do DevOps

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. 

Next Rethinking Agile Principles for the Modern Business World

Comment (1)

  1. Matthew Boon

    Interesting but I have some questions needing clarification and would love your feedback: When I read this article and think of DevOps, I think of Prosci’s ADKAR. As we develop, we want to make operations and end-users AWARE of changes, enhancements, (or if I deploy 100’s of time per day, make them so small they go unnoticed but get used) I want to provide the DESIRE the why, to experiment, use my developed changes, and provide them with the KNOWLEDGE required regarding how to use the changes developed, provide the ABILITY, the time to test the changes, and finally REINFORCE the positive gains we have produced, to gain momentum for our changes. We all know users can sabotage awesome code if the resist change.

    I believe what you are really writing about is CI/CD, to increase predictability through testing for instance multiple operating systems, and browsers, with faster deploys which are smaller in nature leaving less room for issues, and a more rapid early return on investment if I have also thought about ADKAR in the process.

    Perhaps the Dev in DevOps is defined by CI/CD, not sure if they are the same thing or an extension of DEV process, but the Ops is truly Gemba, and ADKAR. If you have a why with CI/CD/DevOps, how are you measuring it’s effectiveness? Has to be in OKR’s or changed behaviors right, based on the hypothesis of why you started working on the EPIC.

    By the way, does working with Apps slow down or place huge dependencies on CI/CD/DevOps with it’s highly structured deployment process? I’m currently reading about monthly deploys with Salesforce apps after elaborate or old school testing procedures and wonder if this can be true in our economy. Salesforce is too popular for monthly deployments, correct?

    Thank you for any feedback!!


Leave a comment

Your email address will not be published. Required fields are marked *