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 » Culture Change: Where It Matters in DevOps

Culture Change: Where It Matters in DevOps

Avatar photoBy: 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
  • Looking Ahead, 2023 Edition
  • Don’t Hire for Product Expertise
  • Complexity is Still With Us
Avatar photo More from Don Macvittie
Related Posts
  • Culture Change: Where It Matters in DevOps
  • 3 Ways to Develop the Perfect DevOps Culture
  • DevOps with Purpose: It’s about your culture!
    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.

TechStrong Con 2023Sponsorships Available

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

« 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

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.