devopsy.kinsta.cloud

Tag: manifesto

  • BizOps Coalition Publishes Manifesto

    BizOps Coalition Publishes Manifesto

    The BizOps Coalition, which advocates for fundamental change in the way IT teams and business users collaborate during software development, today published a BizOps Manifesto framework that identifies 12 principles that focus organizations on business outcomes versus merely attaining and maintaining service levels.

    The goal is to close the historic divide between IT and the rest of the business by encouraging IT teams to work more closely with business leaders, who need to make informed technology investment decisions based on real-time data analytics to drive business growth, improve customer experience and increase profitability.

    BizOps Manifesto authors include Dr. Mik Kersten, founder & CEO of Tasktop; Serge Lucio, vice president and general manager of the Enterprise Software Division of Broadcom; Patrick Tickle, chief product officer of Planview; Sally Elatta, CEO of AgilityHealth; Evan Leybourn, CEO of Business Agility Institute; Tom Davenport, distinguished author and professor; Dave West, CEO of Scrum.org; and Kevin Surace, chairman/CTO of Appvance.ai.

    Lucio said even after a decade of advancements in best DevOps practices, far too many IT teams behave as though they have no vested interest in the outcome of an IT project. In fact, there’s far too much focus on requirements at the beginning of a project because too many IT teams believe that as long as an application is available, their task is complete, he noted.

    The BizOps Manifesto encourages IT organizations to assume requirements can and should change frequently as business conditions evolve. IT teams that focus too much on requirements upfront are essentially applying a waterfall mentality to software development no matter how agile their software development processes are, Lucio said.

    In general, he noted, there’s a lot more focus these days on software development. The biggest immediate hurdle is the terminology being employed to address this issue. The IT vendor community is employing catchphrases such as “value stream management” and “software delivery management” to describe essentially the same issue, he said.

    More organizations than ever are finally coming to terms with these issues as they seek to accelerate the rate at which applications can be deployed in the wake of the economic downturn brought on by the COVID-19 pandemic, Lucio said, noting the BizOps Manifesto is intended to facilitate those conversations.

    It’s not clear to what degree a manifesto can change mindsets within IT teams. Too many IT professionals view themselves as being part of the IT industry rather than the industry its employer is in. As a result, there’s often not a deep appreciation for the unique business challenges an organization faces within the IT department. Arguably, that divide is not as wide as it was at the start of the last decade; nevertheless, the issue persists. A manifesto is as good a place as any to start a conversation that in many organizations is long overdue.

  • Why Is There No DevOps Manifesto?

    Why Is There No DevOps Manifesto?

    Let’s start with a brief story:

    There’s a scene in a movie called “A Few Good Men” in which a lawyer is questioning a cadet. The lawyer directs the cadet to turn to the page in the thick Marine Code Manual that explains where to find the canteen. And the cadet replies, it isn’t in there.

    And the lawyer says, “Well, you eat, don’t you?”

    And the cadet says, “Yes, sir, three times a day!”

    The meals for everyone aren’t served by the book because the canteen isn’t included.

    This isn’t a history for the term DevOps or of the many people who’ve led, presented, written and interviewed about the DevOps movement. I’ve got a footnote below with some pointers for that. This is simpler than that: It’s why today there is no DevOps Manifesto and why I don’t think there will ever be.

    Now, I think I understand the desire for a DevOps Manifesto. I’ve met a lot of folks, company executives and analysts, who still dis DevOps a bit because it lacks a certified definition, an official manual or a definitive statement. Basically, a manifesto; you know, a canonical thing you can put on a shelf.

    Manifestos can be nice. They lay down the vision, the intent, the mission. They can appeal to a wide range of people, from revolutionaries to functionaries to dignitaries. It isn’t for sparking conversations so much as for orderly setting down of intent. A manifesto can bake in the meaning and content of something.

    A manifesto has that “rule of law” book feeling to them. Manifestos also have provenance and pedigree—some group of some renown sat down to discuss some topic for some specific resolutions and wrote the sum of it up. Manifesto wording can be checked to ensure real-world compliance.

    You can almost slap a copy of a Manifesto on a table to settle an argument about the manifesto’s topic. And assuming the words were crafted carefully enough, it will be the end of discussion. And that’s exactly the problem with a manifesto with respect to DevOps.

    I say: That’s not what DevOps is about.

    DevOps begins with stopping the nightmare scenario pitting Ops against Dev—or any other part of the organization. But it comes so much further. It’s for a new age of computing at webscale, using tools, teamwork and techniques to get to better, happier, more engaged outcomes for customers. Some of it is so new we are still figuring out words for it.

    The DevOps movement isn’t slowing down, either. Analysis of the Google results page shows it:

    DevOps searches over time Sep2015

    In all of this time, no one of any significance in the community has attempted to create a “manifesto for DevOps.” I’d say the Godfather of DevOps himself, Patrick Debois, was super insightful on how he went about ensuring no official manifesto could get written. (I’m not going to review the lessons learned from “The Agile Manifesto,” although good lessons were learned from the things created in the wake of having an Agile Manifesto.)

    If you have a manifesto for something, then all conversation in the domain will, rather quickly, go back to the manifesto for resolution instead of everybody working together. That’s not handy in an ever-fluid, often on-fire, scale-up fast, resilience-oriented, rapidly changing and evolving IT situation.

    As Andrew Clay Shafer (@littleidea) said recently, DevOps is about optimizing for people. With the pace of IT and tech ever accelerating, no manual or manifesto could keep up. Which reminds me of one of my favorite quotes:

    Companies die because their managers focus on the economic activity of producing goods and services and they forget that their organization’s true nature is that of a community of humans.

    — Arie De Geus

    One thing you should know for sure about DevOps: The community likes to enhance, educate, enliven, inform and energize people. Basically, everyone is wide open to embracing anything that helps out because webscale is hard. So yeah, DevOps now aligns with “microservices” because microservices can further the DevOps cause. Just like kanban, Docker containers, automated configuration and InfoSec. And anything that enables Dev and Ops to deliver more, better, faster to customers. It’s about serving the customers.

    Meanwhile, if you’re looking for more, you’ll usually find a bunch of folks … figuratively speaking … over in the kitchen at the canteen, serving up awesome and working hard on doing it better and faster.

    And everyone interested is welcome to sit down and enjoy what’s served.

    Seriously. Join in. You do not need a manifesto to.

    P.S.  It was with deep hesitation that I wrote this. There are simply so many awesome people who’ve made all this happen and I am not one of them. Literally the finest collection of technologists—and in many cases, human beings—I have the honor to know who make this community what it is.

    You should check out, in no particular order:

    • The amazing (and amazingly modest) Patrick Debois
    • The writings and teachings of Mark Burgess (one of the most under-recognized geniuses I have encountered)
    • The CALMS write-ups by John Willis (@botchagalupe) and Damon Edwards (@damonedwards)
    • Damon’s five-minute video on DevOps history
    • John’s frank exploration of the issue of burn-out in IT (and that is directly related to why we are having DevOps conversations)
    • Mary Poppendeick’s lean development work
    • John Allspaw and John Hammond’s 2009 Velocity keynote that sorta kicked this whole thing off
    • Ben Rockwood’s (@benr) comprehensive LISA11 keynote
    • The many videos of Andrew Clay Shafer (@littleidea) and his brilliant guidance. Sometimes with katana and sometimes with gattling gun.
    • Jez Humble’s books (particularly “Continuous Delivery” and “Lean Enterprise”)

    And works from folks including:

    • Jeff Sussna (@jeffsussna)
    • James Turnbull (@kartar)
    • Adam Jacob
    • John Vincent (@lusis)
    • Bridget Kromhout
    • Adrian Cockcroft
    • Gareth Rushgrove
    • Kris Buytaert
    • J. Paul Reed
    • Ernest Mueller
    • James Wickett
    • Ines Sombra
    • Karthik Gaekwad

    I mean, this is a global phenomenon, were you expecting a short list? This isn’t even complete!

    Oh, and the VisibleOps guru Gene Kim, who came and showed us all a way to really blow the doors off the DevOps news.

    These people are helping all of us do better Dev, better Ops, better IT, better business so that you can have better customers. It’s amazing. It really is. And it’s wonderful.

    Also, if you get a chance to spend time at a DevOps Days anywhere, you should.