Rescuing DevOps (From Myself)

Rescuing DevOps (From Myself)

I have wasted more time than I care to admit arguing about the definition and proper use of the term "DevOps". I will confess to having uttered the words "if you have a DevOps team then you're doing it wrong". Over time I've grudgingly given in to various redefinitions, the saddest one being that DevOps - and its offspring SRE - are just new names for the same old IT departments and practices.

For better or worse, I still can't keep myself from reacting to the red cape being waved in front of me. In a recent conversation, a colleague used the term DevOps in a context that didn't make sense to me. I was about to object, when I realized something that might actually be useful.

My colleague was specifically referring to tools, activities, and organizational structures that make it easier for applications teams to achieve fast flow. He was thinking about SRE/Platform Engineering/Cloud Engineering fulfilling their intended purpose. When he said "DevOps", what he meant was Operations on behalf of Development.

The DevOps portmanteau has always been confusing. My colleague's definition fits nicely with the fact that Ops is the natural noun in DevOps. It's also compatible with the Team Topologies framework. IMHO that framework is the most practical application of DevOps for real-world organizations. It goes beyond admonitions to "break down silos" and provides a healthy model for dedicated infrastructure/operations teams. Platform and enabling teams fulfill the intent of the dreaded DevOps team. They reduce cognitive load so stream-aligned product teams can increase flow.

DevOps as "ops in support of developer flow" may still lose some of the framers' initial intent. For me, at least, it promises some peace of mind. I can stop worry about whether someone is polluting or diluting the word. In my experience, most current use of the term is highly compatible with ops for the sake of dev. As a result, when people say "DevOps" I can respond with "OK" instead of "yes, but…", and we can all get on with our jobs, which is satisfying customers by continuously delivering valuable software.

P.S. it's entirely possible that everything I just said is obvious to everyone but me. If so, then I appreciate your patience while I catch up with the rest of you in public. ??

Sebastian Schulze

Unlocking DORA Metrics for Enterprise DevOps Performance

1 年

Wise words

回复
Andi Mann

Enterprise Technology Leader - Transformation Expert, Innovation Driver, Revenue Accelerator, Global Communicator, Strategic Advisor

1 年

I truly hate this perspective, but appreciate the post. Good discussion topic at very least.

回复
Fredrik Matheson

Leads design at Aneo Renewable :: Runs IxDA Oslo

1 年

I like this approach!

回复
Andy Morgan

A leader of technology focused teams with three decades of experience across multiple aspects of technology delivery.

1 年

Welcome my friend. ??

要查看或添加评论,请登录

Jeff Sussna的更多文章

  • Cracking the Jobs to Be Done Mystery

    Cracking the Jobs to Be Done Mystery

    "Jobs to Be Done" is a powerful framework for shifting focus from product features to customer needs. Applying it…

  • How Do We Know When We're Done?

    How Do We Know When We're Done?

    More than 20 years after the Agile Manifesto was published, and more than 30 years since the introduction of Scrum…

    1 条评论
  • A Manifesto for Outcome-Driven Agile

    A Manifesto for Outcome-Driven Agile

    We are uncovering better ways of creating customer value by doing it and helping others do it. Through this work we…

    2 条评论
  • EmpathyOps: Serving Customers By Serving Each Other

    EmpathyOps: Serving Customers By Serving Each Other

    The DevOps community has been exploring the idea that DevOps is really bigger than dev and ops. If this is true (I…

    2 条评论
  • Snowballs, Jobs To Be Done, and the Four Dimensions of Service

    Snowballs, Jobs To Be Done, and the Four Dimensions of Service

    At their re:Invent user conference this year, Amazon Web Services touted their Snowball data import service. Microsoft…

  • Design Thinking In Three Words

    Design Thinking In Three Words

    There are as many definitions of design thinking as there are articles about it. Its power and its curse lie in the…

    3 条评论
  • A Better Approach to Bimodal IT

    A Better Approach to Bimodal IT

    I first encountered the ideas behind Bimodal IT about two years before Gartner coined the term. I was doing a speaking…

    1 条评论
  • Why the CIO Needs to Become the Continuous Design Officer

    Why the CIO Needs to Become the Continuous Design Officer

    I recently participated in an episode of the #c9d9 podcast hosted by Electric Cloud. The topic of discussion was the…

  • Agile, Have You Met Design Thinking?

    Agile, Have You Met Design Thinking?

    In a recent blog post, Joshua Kerievsky introduces what he calls “Modern Agile”. In his words, modern agile “simplifies…

  • DevOps As Design

    DevOps As Design

    The DevOps movement has encountered a certain amount of criticism for not being more prescriptive. “The principles…

社区洞察

其他会员也浏览了