DevOps Is Not Tools: It’s a Delivery System

Why DevOps Continues to Fail (Even with the Adoption of Tools)

Many organizations think they are doing DevOps, because:

• They’ve bought CI/CD tools,
• They’ve moved to Using Containerization,
• They’ve automated their release processes.

But, releases continue to be painful, as do spikes in incidents during the release process; Engineering Teams continue to work beyond their limits (overloaded with work).

Although this sounds like DevOps based on what the average organization thinks DevOps is, it isn’t true.

The challenge for most organizations is not based on the tools that they have adopted, but instead, their misunderstanding of what DevOps actually is.

DevOps is not a Tool Chain; it is the Structure for a Business to Deliver Value.

We’ll talk in detail about the reasons why DevOps ‘fails’ when it is viewed as a means to acquire tools, what DevOps is really about and how High-Performing Teams leverage DevOps to be able to deliver software in a reliable manner on a Non-Stop Basis.

The Misguided Efforts of Many Organizations Trying to Adopt DevOps Due to an Overemphasis on Tools

Most of our DevOps adoption experiences start by doing something like this:

“Let’s add to our work with CI/CD”,
“Let’s start Utilizing (Kubernetes)”,
“Let’s move to Using (Terraform)”,
“Let’s standardize on Jenkins, GitHub Actions, or GitLab”,

This practice of creating tools is fine; however, the majority of these steps will only get you part of the way to achieving the overall goal of having DevOps.

While it is true that tools are important for DevOps to work, they are only one piece of the equation.

When Organizations Focus on Tools Before Everything, They Appear to Be Automating Broken Processes Without Actually Fixing Their Broken Processes (Failures In The Automation).

Defining What DevOps Actually Is.

Because we keep saying this, we can simply define DevOps as the Method that Follows a Non-Stop Model For The Delivery of Software.

To achieve this objective through proper utilization of the DevOps model, we will keep things simple:

DevOps aligns all items related to Delivery from Idea through to Production Through To Production Through To Production.

DevOps is about the flow of the Development Process to the End-User. DevOps is about the outcomes that are associated

Why DevOps Should Be Seen as a System of Delivery, Not as a Role or Tool

1) DevOps is the Complete Lifecycle of Software Development

DevOps provides for the complete lifecycle of computer programs:

• Creating Code
• Testing
• Delivering
• Monitoring
• Handling Problems
• Improving Continuously

If any section of this chain fails, product delivery will slow.

Simply putting tools into one part of the system does not fix the entire system.

2) DevOps Is About Flow, Not Just Local Efficiency

Many teams optimize the different “phases” of software development:

• Builds done faster
• Deliveries done faster
• Provisioning done faster

DevOps looks at your entire product’s workflow:

• How long from idea to product?
• Where does work sit?
• Where do transitions create friction between phases?

When you optimise locally, and don’t think about the impact on the overall flow of your process, you create additional bottlenecks elsewhere.

The True Purpose of DevOps Is to Improve the Following (these cannot be improved with tools)

DevOps exists to improve:

• How often code is deployed
• How long it takes for changes to be made
• How many times a change results in failure
• How long it takes to recover from a failure (Mean-Time-To-Recover)

These outcomes are based on how you align your processes, and are not determined solely by the tools you use.

Why a Tool-Focused Approach to DevOps Will Fail

Failure Pattern #1 – Attempting to Automate Processes That Are Broken

A slow-release process can be attributed to processes that are still manual (approvals), complicated (unclear requirements), or done too late in the process (Quality Assurance); you will only be able to automate the delay if you attempt to implement Continuous Integration/Continuous Delivery in this scenario.

Failure Pattern #2 – Building a DevOps Team

Developing a “DevOps Team” can result in:

Creating a new silo
Creating ticket-based production operations
Slower product delivery

DevOps is not a department; it is a way of establishing your responsibility as a team member.

Failure Pattern #3 – Measuring Activity Rather Than Outcome

Some activities that do not achieve results are:

Measuring how many times you delivered a product instead of calculating the revenue impact

Measuring how many times people have used the tool, not how quickly they were able to recover from a failure

Celebrating automation when the results weren’t reliable.

When measuring success for DevOps, it should be based on business results, not dashboards.

Connection Between Product & Engineering (DevOps)

DevOps begins before code is written.

To achieve extreme performance, DevOps teams have to:

Divide work up into small predictable increments, with potential for release.

Align technical priority with business objectives.

Limit batch size to minimize risk.

Large releases mean failure in your delivery capabilities.

Continuous Integration (CI) Requires Discipline

• CI is not simply running builds.
• Successful CI means:
• You use trunk-based development (TBD).
• You receive immediate feedback on each change.
• You write tests your team trusts.
• You fail quickly and learn fast, rather than fail late and be surprised.
• Slow continuous integration pipelines impede progress.

Continuous Delivery With An Emphasis On Safety

• Continuous Delivery means confidence, not just speed.
• Important aspects of continuous delivery include:
• Automated Testing.
• Feature Flags.
• Incremental Rollouts.
• Rollback Procedures.
• Shipping fast with no safety increase leads to outages.

Observability + Feedback Loop

If you can’t see what’s occurring in production, you cannot improve your delivery capabilities.

The foundations of observability and feedback loops consist of:

• Monitoring.
• Logging.
• Tracing.
• User Feedback.

Feedback closes the loop between Learning and Monetisation.

Incident Response As A Learning System

• An incident is not a failure.
• An incident is feedback.
• To achieve extreme performance through DevOps, teams should:
• Respond to incidents in a timely manner.
• Minimize assignment of blame.
• Leverage a learning-based approach.
• Continue to make improvements to the delivery system using a continuous improvement model.

The cultural component of DevOps must change for any of the tools/development strategies to be valuable.

The Cultural Layer Cannot Be Provided For By Tools In DevOps

To be successful with DevOps:

• Trust exists between teams.
• Accountability is shared.
• Organisations allocate appropriate resources for change management.
• Organisations allocate resources for leadership support.

If culture does not change, tools for DevOps will simply be shelf ware.

DevOps Compared to Other Delivery Models

Traditional model

• Team to team handoffs
• Big “batch” releases
• Manual approval of releases
• Long recovery time

DevOps Model

• You will share ownership of your work with your team and be responsible for the quality of your work.
• Quick, small releases
• Automated quality checks release
• Fast recovery time.
• DevOps is a better way of delivering business value, not a new job function.

Before using DevOps to make your business better, you need to understand how DevOps will impact your business:

• Reduce time to market
• Reduce number of failures
• Improve the Customer Experience
• Reduce Engineering Burnout
• Increased Speed of Innovation
• DevOps is a business enabler and not a cost center.

Technical Debt in DevOps

• DevOps does not eliminate technical debt, however, it does provide:
• Visibility to your debt
• Reduced cost of change
• Continuous improvements
• Over time, when you do not pay down technical debt, it will break the flow of delivery.

DevOps for Startups vs. Enterprises

For startups:

• Faster experimentation
• Ongoing learning
• Less overhead

For Enterprises:

• Safer releases
• Less impact from outages
• More alignment between teams
• DevOps scales in different ways but retains the same delivery principles.

What does a true DevOps transformation look like?

A real transformation in DevOps will start with value stream mapping, remove the “bottlenecks” that are slowing down delivery and creating a positive environment for all involved.

Measuring success is based on the success of the organization and not by the amount of work being done.

Continuous improvements are key to a successful transformation in DevOps.

Common Misconceptions about DevOps:

DevOps is not only Continuous Improvement/Continuous Deployment
DevOps does include the components of CCDC (Continuous Integration and Delivery) but does not equal it!

DevOps does not require constant delivery.
With DevOps, you will deliver with greater safety and predictability.

Tools do not equal maturity.
Maturity comes from your business processes and culture.

A Simple DevOps Self-Assessment

• How long does it take to ship a small change?How often are incidents caused by a deployment?
• How quickly can we recover from failure?
• Where are people waiting the longest for their work?
• Are teams sharing responsibility for their results?

Your answers will reveal if you’re using a delivery system or a tool.

DevOps is a Delivery System

DevOps isn’t a technology upgrade; it’s an operating model.
While tools support DevOps, they don’t define it.

Organizations that see DevOps as the means to deliver:

• Deliver faster
• Fail less Often
• Always Learn
• Outperform their Competition

While organizations that see DevOps as simply tools will continue asking “Why didn’t anything change?”

Extended FAQs