DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DataOps
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • Techstrong.tv Podcast
    • Techstrong.tv Video Podcast
    • Techstrong.tv - Twitch
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Content
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Techstrong TV
    • Techstrong.tv Podcast
    • Techstrong.tv Video Podcast
    • Techstrong.tv - Twitch
  • Media Kit
  • About
  • Sponsor
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DataOps
  • DevSecOps
  • DevOps Onramp
  • Platform Engineering
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps
    • ROELBOB
Hot Topics
  • Cisco Bets on OpenTelemetry to Advance Observability
  • 5 Technologies Powering Cloud Optimization
  • Platform Engineering: Creating a Paved Path to Reduce Developer Toil
  • Where Does Observability Stand Today, and Where is it Going Next?
  • Five Great DevOps Job Opportunities

Home » Blogs » Enterprise DevOps » DevOps and Change Management

DevOps and Change Management

Avatar photoBy: Scott Rogers on May 1, 2014 Leave a Comment

In “The Phoenix Project”, the character Erik introduces the underpinning principles of DevOps as “The Three Ways”.  Let’s talk about the First and Third Ways and how change management works with DevOps, but first let’s spend a few minutes talking about baseball caps.

Recent Posts By Scott Rogers
  • Systems of Things
  • DevOps and The Goal
Avatar photo More from Scott Rogers
Related Posts
  • DevOps and Change Management
  • The Art of DevOps
  • Q&A: BDO’s Coffman on Change Management, Security and DevOps, Part 2
    Related Categories
  • Blogs
  • Enterprise DevOps
Show more
Show less

Last weekend I was looking for my Atlanta Brave’s baseball cap and found three as I expected for a family of three with two adults and one child.  Since they all looked alike, I compared sizes to figure out which one was mine and was surprised to find they were all the same size!  How can one size fit three very different sized people?  The answer was simple: They have an adjustable strap.  Let’s use this idea to explore the relationship between DevOps and change management.

TechStrong Con 2023Sponsorships Available

One size fits all with an adjustable strap

IT is being asked to iterate faster and keep our systems highly available while doing so.  Those two ideas seem at odds: How do we fail fast and keep our infrastructure highly available?  Change management can help!

Many people I speak with view change management as an anathema, as being incompatible with the principles DevOps.  The word “onerous” comes up a lot.  Inflexible is also quite popular.  I understand the sentiment and would like to help the community see change management differently.

I think of change management as a continuum spanning rigorous to mild, heavyweight to lightweight.  Just like the baseball cap with an adjustable strap, change management can be adjusted for as needed.

The First Way

When describing the First Way, Erik invokes Deming’s quote, “appreciation for the System”.  In “The Top 11 Things to Know about DevOps” Gene Kim refines the idea as, “seeking to achieve profound understanding of the system”.  In my article on DevOps.com titled “Systems of Things”, I assert that understanding the system is required before improving the system.  It seems pretty clear the First Way is about understanding the system we want to improve.  It is also about delivering business value to the customer.

The Third Way

The Third Way is about encouraging experimentation and building a culture that rewards risk as a way to speed maturation.  Rajat Bhargava expands upon that idea in his article, “DevOps Demands we Fix Twice” where he asserts that we should release quickly to speed product maturation.  It seems pretty clear to me that the Third Way is about speeding maturation of the features and functionality that deliver value.  The Third Way suggests we iterate faster, accepting some amount of risk as a trade-off.  I assert this risk is solely focused on features and functionality and not infrastructure.

Tighter for infrastructure and looser for features

After reading “The Goal” I began to think of code, the features and functionality that is ultimately delivered to the customer, as the material that flows through the factory and IT infrastructure as the machinery in the factory.   The machinery factories only exist to process material.  IT infrastructure is analogous to machinery; it only exists to allow features flow through to customers.

In a well-run manufacturing facility the material flowing through the factory and maintenance on the machinery are both governed by well-defined and well-understood processes.  These processes are the analog to IT change management.

The machinery should only be down for maintenance at very specific times.  At all other times the machinery should be ready to produce widgets.  The same is true for the Ops part of DevOps; Ops exists to allow feature and functional to flow through to the customers.  Ops should endeavor to keep the systems up and available for Dev to push code.

Practical Application

In practical terms, this means that infrastructure changes and code releases should be treated very differently.  The frequency and timing of code releases should be decoupled from the frequency and timing of infrastructure changes.  Infrastructure changes should not impact code releases and vice versa.  Infrastructure changes should come with a high amount of rigor while feature functionality should come with much less.

A single change management process accomplishes this by:

  • Decoupling code releases and infrastructure changes when possible
  • Allow the frequency and timing of code release to be independent of infrastructure changes
  • De-conflicting infrastructure changes and code releases

I think my colleague Stephen Fishman summed it up nicely, “The mission of Change Management… is to simultaneously increase the frequency of intentional change executions while reducing the duration and impact of interruptions for services provided….”

Rent to own

It can be tough to see change management and DevOps as compatible.  Instead of agreeing or disagreeing, just try the concept on for a while.  Rent the idea (it’s free) that change management rigor is a continuum, an adjustable strap and see how if it works for you.

Filed Under: Blogs, Enterprise DevOps

« Q&A: Bill Burns on Security Within DevOps
DevOps and PaaS: ‘Give me a platform. Let’s rock, let’s rock, today’ »

Techstrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Automating Day 2 Operations: Best Practices and Outcomes
Tuesday, February 7, 2023 - 3:00 pm EST
Shipping Applications Faster With Kubernetes: Myth or Reality?
Wednesday, February 8, 2023 - 1:00 pm EST
Why Current Approaches To "Shift-Left" Are A DevOps Antipattern
Thursday, February 9, 2023 - 1:00 pm EST

Sponsored Content

The Google Cloud DevOps Awards: Apply Now!

January 10, 2023 | Brenna Washington

Codenotary Extends Dynamic SBOM Reach to Serverless Computing Platforms

December 9, 2022 | Mike Vizard

Why a Low-Code Platform Should Have Pro-Code Capabilities

March 24, 2021 | Andrew Manby

AWS Well-Architected Framework Elevates Agility

December 17, 2020 | JT Giri

Practical Approaches to Long-Term Cloud-Native Security

December 5, 2019 | Chris Tozzi

Latest from DevOps.com

Cisco Bets on OpenTelemetry to Advance Observability
February 7, 2023 | Mike Vizard
5 Technologies Powering Cloud Optimization
February 7, 2023 | Gilad David Maayan
Platform Engineering: Creating a Paved Path to Reduce Developer Toil
February 7, 2023 | Daniel Bryant
Where Does Observability Stand Today, and Where is it Going Next?
February 6, 2023 | Tomer Levy
Five Great DevOps Job Opportunities
February 6, 2023 | Mike Vizard

TSTV Podcast

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays

GET THE TOP STORIES OF THE WEEK

Most Read on DevOps.com

OpenAI Hires 1,000 Low Wage Coders to Retrain Copilot | Netflix Blocks Password Sharing
February 2, 2023 | Richi Jennings
Automation Challenges Holding DevOps Back
February 1, 2023 | Mike Vizard
Cisco AppDynamics Survey Surfaces DevSecOps Challenges
January 31, 2023 | Mike Vizard
Red Hat Brings Ansible Automation to Google Cloud
February 2, 2023 | Mike Vizard
Three Trends That Will Transform DevOps in 2023
February 2, 2023 | Dan Belcher
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2023 ·Techstrong Group, Inc.All rights reserved.