DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • Leadership Suite
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More Topics
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Blogs » Culture Change: Where It Matters in DevOps

Culture Change: Where It Matters in DevOps

By: Don Macvittie on June 20, 2017 1 Comment

Red SquareLori and I were in Russia in the late ’90s. It was an interesting dichotomy of life in a changing country. While we were there, the government devalued the ruble—just cut three zeros off the end of everything—to bring it into historical line with other world currencies. It was odd, because there was a mass of old money and a smattering of new, and most systems were not yet reconfigured to handle the new prices. Thus we paid 180,000 rubles to fly from Moscow to Rostov.

Recent Posts By Don Macvittie
  • The Scanner We Really Need
  • Is Your Future in SaaS? Yes, Except …
  • Update Those Ops Tools, Too
More from Don Macvittie
Related Posts
  • Culture Change: Where It Matters in DevOps
  • Can We Stop Talking About DevOps?
  • Why “Enterprise DevOps” Doesn’t Make Sense
    Related Categories
  • Blogs
  • Doin' DevOps
    Related Topics
  • agile
  • Culture Change
  • Customer needs
Show more
Show less

But the physical implications were not the issue. The cultural implications were. We stayed with a very nice host family in Moscow, and talked long with them about pretty much everything. The older generation tended toward the old system, while the younger generation toward the new. Thus, the father of the family, in his 50s, blamed the west (specifically the United States, but since we were from the United States, I think the vodka made him stress that part) for losing his job as an astrophysicist. He also blamed the west for their currency woes. If yesterday, you had half a million rubles in the bank, today it was 500, so his angst was understandable. He blamed trade issues for that. His wife agreed with him, and scolded us for buying them nice things, since they would have to pay to keep them usable.

DevOps/Cloud-Native Live! Boston

Their adult son—and indeed most of the younger  generation—was the polar opposite. The younger generation thrived in the new environment, saw a bright future and laughed at today’s misfortune. It would be better tomorrow, and they were adapting to the new open environment to make sure it was.

No, this is not a “get out of the way with your old thinking” blog. It’s a “be smart with your new thinking” blog. One problem endemic to the youth of Russian culture when we were there was they believed the rules no longer applied rather than believing there were new rules and new ways to interpret the old rules. It got many into trouble.

To Quote a Friend: Culture, It’s a Thing

There are some in the DevOps community who like to talk only about culture, because the non-automation benefits of DevOps are most felt in culture change. This is a not-unreasonable stance, and though I am definitely an aficionado of the automation side of DevOps, I see the benefits of culture change and embrace them where they are most impactful. I also acknowledge that in a full DevOps implementation culture change is inevitable.

One place where most organizations could put more forethought—regardless of how the project is developed/deployed— is in releases. Think this through as a customer, not as a DevOps engineer. You have been burned by companies horribly missing a deadline after announcing features that you were waiting for (most of us have, anyway). By this point you have also been burned by companies releasing with the feature you wanted, only to find that it barely (if at all) worked, but now that it was released, the company would make it better over time.

Now switch back to being an IT professional. We know the pressures and issues around releases.

I think the biggest improvement commercial enterprises can make is to decouple marketing releases from Dev releases—to watch a project go through CI/CT/CD/ARA until it is solid, and only then start planning a release date. While this isn’t fully in tune with rapid delivery, the marketing team has a whole set of activities to perform that are dependent upon a certain level of functionality. Weekly stand-ups and continuous delivery do not make that functionality real on the date it was promised, everyone involved in the process knows that. So planning like it will be is as inefficient as writing code before you have a product idea.

For internal teams, it’s a little bit different. There is the opportunity for Dev/Release engineers to stay in contact with representatives of the customer (normally managers or team leads, but whoever represents the customer), and adjust everything. Expectations can be managed if a certain functionality prove difficult to get working right, or release dates can be managed except in the most politically charged environments, and slight changes can be made to requirements—things such as, “Well, if we do it this way, we can meet deadlines, but it will impact this other thing,” can be brought to the customer. Having a representative of the customers on the team is sort of like disassociating marketing release from DevOps delivery: There is the chance to make sure it’s right before it hits users’ hands.

Oh Yeah, Culture

But I’m not here to tell you how to manage the process, I’m really here to talk about the culture. It used to be that if a needed feature wasn’t ready, the feature was cut or the release was delayed. All that Agile and DevOps have really added at that late stage in the game is a third option—release it with a substandard feature.

In the end, either users (in an enterprise setting) or someone looking out for users (in a commercial setting) need to make that call. Far too often, Dev and Ops are making it, and users are suffering for it. Change that. Give the power to those you are working for. The app you’re developing is aimed to serve a purpose for a set of users. If a new release does not offer them what they need—even if you can check a box and say it’s in there—then don’t release.

The thing combined Agile and DevOps does generally give us is more predictive ability. It’s not perfect, but we do know sooner if there will be problems. Generally speaking, it is easier to slip release dates early in the process, simply because the release is not as anticipated.

It’s About Why

Some teams that used to cut features because they couldn’t meet deadlines are now teams that put in sub-standard features so they do meet deadlines. There are good reasons to plan a graduated rollout of a feature or feature set, but “couldn’t get it implemented” isn’t one of them. The granularity of Agile means that estimates should be tighter, because you’re estimating smaller chunks at a time. The ability of DevOps to deliver a more consistent end product and configured environment should mean there is less delay in the deployment cycle. So the correct answer is to find out what users want, go that route and then examine where you went wrong so you can do better next time. Sometimes “do better” will mean better estimates, sometimes it will mean using less new or questionable technology, sometimes it will mean controlling change in the environment outside the project—or accounting for it in estimates. But improvement should be the goal, all of the time.

In the end, you’re creating a tool designed to serve the needs of a certain set of users. I don’t want to be sold a snappy laptop with an advertised 1TB SSD drive only to get delivered the same laptop with an external, full height, MFM encoded drive touting a whopping 110 MB. So why would it be okay to do the equivalent in software (or, in a couple cases I know the details of, firmware)? Don’t be silly, of course that’s extreme. Maybe the machine comes set up to boot from 5.25-inch floppy instead, to reduce shipping overhead.

— Don Macvittie

Filed Under: Blogs, Doin' DevOps Tagged With: agile, Culture Change, Customer needs

Sponsored Content
Featured eBook
The State of the CI/CD/ARA Market: Convergence

The State of the CI/CD/ARA Market: Convergence

The entire CI/CD/ARA market has been in flux almost since its inception. No sooner did we find a solution to a given problem than a better idea came along. The level of change has been intensified by increasing use, which has driven changes to underlying tools. Changes in infrastructure, such ... Read More
« IT Revolution Announces First Round of Speakers and Early Bird Pricing for DevOps Enterprise Summit San Francisco 2017
BMC Pushes Automation to the DevOps Left »

TechStrong TV – Live

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

Upcoming Webinars

Supercharge Your AWS Cloud Platform With Self-Service Cloud Ops
Thursday, May 26, 2022 - 1:00 pm EDT
Abracadabra: Achieving Zero Downtime With ANY Observability Tool
Tuesday, May 31, 2022 - 11:00 am EDT
Observability Best Practices and OpenTelemetry
Tuesday, May 31, 2022 - 11:30 pm EDT

Latest from DevOps.com

The Scanner We Really Need
May 25, 2022 | Don Macvittie
Could Buying VMware Bring Broadcom Hybrid Cloud Bona Fides?
May 24, 2022 | Dan Kirsch
Competing Priorities Prevent Devs From Creating Secure Code
May 24, 2022 | Pieter Danhieux
DevOps/Cloud-Native Live Boston: Get Certified, Network and Grow Your Career
May 23, 2022 | Veronica Haggar
GitLab Gets an Overhaul
May 23, 2022 | George V. Hulme

Get The Top Stories of the Week

  • View DevOps.com Privacy Policy
  • This field is for validation purposes and should be left unchanged.

Download Free eBook

The Automated Enterprise
The Automated Enterprise

Most Read on DevOps.com

DevOps Institute Releases Upskilling IT 2022 Report 
May 18, 2022 | Natan Solomon
DevSecOps Deluge: Choosing the Right Tools
May 20, 2022 | Gary Robinson
Managing Hardcoded Secrets to Shrink Your Attack Surface 
May 20, 2022 | John Morton
DevOps and Hybrid Cloud: Life in the Fast Lane?
May 23, 2022 | Benjamin Brial
GitLab Gets an Overhaul
May 23, 2022 | George V. Hulme

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

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