1. Exquisite Tweets from @bguthrie

    blechCollected by blech

    Today I'm going on a rant about the term DevOps. Join me, friends! Here's the rant: the term DevOps originally had a completely different meaning from how it's now commonly understood, and I'd like to talk a little bit about why that matters, and what you can do to change it. /1

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    First, a definition: "DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality." That's from 2008. en.wikipedia.org/wiki/DevOps /2

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    That's what DevOps is: a set of practices that encourage continuous integration into production. Here's what it's not: a job title, a software tool, a team name, or magic enterprise fairy dust. No practices, no DevOps. /3

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    More than that, it's a mindset. If you think Devops is something you get by sprinkling DevOps Engineers into your organization without buying into the mindset then you're never going to get the benefit from it that you're hoping for. /4

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    If you think DevOps is a toolkit and not a practice you're missing the point. If you think it's a role and not collaboration between roles you're missing the point. If you think it's a team and not an organizational feedback loop you're missing the point. /5

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    The goal of that journey is the acknowledgement and recognition that software is safer when people with complementary skillsets in technical operations and software development work together, not apart. /6

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    The role of engineering leaders in that journey is to encourage collaboration by creating the right feedback loops. "Balance of power" theories of team structure are dead. The organization doesn't win unless everyone is deploying safely, all the time. /7

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    If you create a DevOps team, but don't create the right feedback loops, you end up right back where you started: with people in camps that have competing motivations and orthogonal skillsets. Your delivery process might get incrementally better, but the org won't. /8

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    Here's how you know it's gone wrong: DevOps engineers don't trust product engineers to deploy and don't understand the changesets. Product engineers don't trust the deployment process and don't understand the mechanics. Deployments are unreliable. Nobody is happy. /9

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    Because DevOps has become a title and not a way of thinking, there is now so much skillset—rather thank mindset—junk attached to the job that we've lost the plot almost completely. The fact that the above failure states are all too common is testament to that. /10

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    So what can you do to change it? I'd suggest walking away from DevOps titles, but that ship has sailed. Instead do what you can to inhabit the practices on both sides of the aisle within your organization. /11

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    Don't accept the answer that your responsibilities are completely isolated from, or dedicated to, DevOps. Inhabit the practice of collaboration. Share every last bit of knowledge you have with your neighbors. /12

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    If you find yourself in a DevOps team then ask yourself: Am I creating incremental change that serves my customers? Am I creating the right incentives for the teams I support to do the right thing? Am I teaching others how to write deploy scripts? /13

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    If you find yourself in a product engineer team then ask yourself: Am I taking responsibility for change? Am I keeping my changesets small? Am I willing to go on call, or build empathy and share the journey with those who are? Do I understand if my software is healthy? /14

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    The secret sauce of software development—the philosophical origin of most advancements in thinking over the last 20 years—is incremental change, tight feedback loops, shared knowledge, and mutual respect. /15

    Reply Retweet Like

    bguthrie

    Brian Guthrie

    bguthrie

    Brian Guthrie