devopsy.kinsta.cloud

Tag: state of devops

  • The State of DevOps Is Just Fine

    The State of DevOps Is Just Fine

    There is a growing amount of hand-wringing about the state of DevOps; that adoption is not progressing apace, or that the full benefits of the methodology are not being realized by the majority of adherents. That we can and must do more and do it better, etc.

    That is just stupid. Or, my first reaction: “Bunk!”

    Yeah, I called an idea stupid. No, I didn’t call you stupid. Don’t give me a reason to. The world is full of stupid ideas, and this is one of them. Here’s why.

    DevOps has seen a decade of unprecedented adoption – yes, unprecedented. PCs were not adopted by businesses at the rate that DevOps was adopted, once it caught on. Virtualization took the business world by storm and, frankly, wasn’t even close to the adoption rate of DevOps. Agile greased the wheels and got people thinking about better ways; we all knew the weaknesses of how we were doing things, and DevOps gave us an option that addressed those weaknesses. We took it. We ran with it.

    So talking about how it is stalled, when adoption is darned near-ubiquitous? Silly.

    Those concerned are further zeroed in on one aspect of DevOps – not enough culture change. Let’s face it—automation is easier, the ROI is more obvious and even when ROI is vague, the elimination of busywork from the schedule of developers and operations alike is huge. Some organizations were never going to move beyond that point; others eventually will, but aren’t in a rush. Organizational changes do not define DevOps any more than automation does—DevOps is the process of streamlining software creation and delivery—and both automation and culture change contribute.

    The “full benefits” of DevOps are … what, exactly? That is another silly part of the proposition that a slowing of DevOps adoption is negative. Automation improves the creation and delivery of software, silo elimination improves the creation and delivery of software… The full benefits of DevOps are improvement. That has always been the stated goal—to make it better, smoother, more repeatable. Wherever an organization is on implementation, it is almost guaranteed that their creation and delivery is “better, smoother, more repeatable.” So, benefits are accruing.

    And each organization has different needs. DevOps is a methodology. It has never been the perfect solution to every IT problem—though there are still pundits that will try to tell you it is. Automation is always a positive; Agile and DevOps—well, that is less true. You know your organization and your apps, so the “right methodology for the job” is absolutely your call, not some vendor’s or pundit’s. So, “adoption slowing” partially represents orgs/projects/apps that have opted not to pursue some of the more radical changes DevOps implies (yes, radical. Automation is just a logical extension of scripting; redesigning team organization and reporting relationships is absolutely radical by comparison).

    Which is a good place to leave off. Your apps, your org, your environment. You know what is going to do the most good. So keep doing it. Push for it if the org isn’t there yet, be the change that is needed. But be aware of cost/benefit. Sometimes, the changes being asked for just aren’t worth it. So make sure they are before you push too hard, and if they’re not, make sure you’re comfortable with why and can defend that decision.

    And keep rocking it. Those apps are delivering to users, no matter where you are in DevOps adoption. And that says it all about you and the team. Thanks, for all of your users that never think to say it.

  • What Is DORA and Why Should You Care?

    What Is DORA and Why Should You Care?

    Many of you may already know that Gene Kim, Jez Humble and Dr. Nicole Forsgren launched a new company called DORA. DORA stands for DevOps Research and Assessment.

    Some of you probably also know that DORA and the individuals behind it have been providing a lot of the science and analysis behind the State of DevOps survey and report for a number of years now. But beyond the 3 rock star founders, what is DORA really about? What is the business model to generate revenue? I had a chance to sit down with DORA CEO Dr. Nicole Forsgren and find out for myself.

    nicole forsgren DORAI actually caught up with Nicole when she made a pilgrimage to the DevOps Mecca of Miami. Well OK, Miami may not be a DevOps Mecca, but we do have good Cuban food. It was the Cuban food that got her. Over a delicious lunch on Calle Ocho in Little Havana, Nicole explained to me what DORA is all about.

    Dr. Forsgren is CEO of the company and currently wearing multiple hats (you have to love the smell of startup in the morning). Jez Humble is now also full-time with DORA and is working away building out the backend here. Gene is also very involved, but as you can imagine, his time is pretty tight these days.

    DevOps Assessments

    While developing the annual State of DevOps Survey and then analyzing the data is a job in and of itself, that is really just the jumping off point for DORA. By taking the data from something like 25,000 responses over the past years, DORA has been able to create baselines and models from which they can compare how your organization compares to others who have taken the survey. They can pinpoint where you are lacking or not performing up to par, as well as where you are over performing. The entire process is built on rock solid statistical modeling and has already proven itself with several large enterprises.

    DORA’s business is in providing assessments and surveys of organizations to see if you are a high performing IT organization or where you might need help and attention to become even better. When should you consider a DORA assessment?

    Consider a DORA Assessment if you have problems:

    • Improving technology and organizational performance

    • Prioritizing improvement efforts

    • Attracting and retaining talent

    • Establishing your brand as a high-performing organization

    How it works:

    Running a DORA Assessment follows four stages:

    1. Decompose an Organization
      • Identify the Lines of Business and teams to be assessed
    2. Prepare for Assessment
      • Socialize the survey and prepare email distribution lists
    3. Take the Assessment
      • Everyone takes a 15- to 20-min survey
    4. Generate and Deliver Reports
      • Team capabilities and outcomes benchmarked against the organization

      • Team capabilities and outcomes benchmarked against the industry

      • Prioritization analysis, with capabilities arranged by impact to Technology Performance

    As I mentioned earlier, the results have been pretty impressive to date. For good reason too. DORA is sitting on a treasure trove of data and Dr. Forsgren has the chops to perform the analysis that makes it invaluable. With Gene Kim and Jez Humble, this analysis can be and will be turned to helping others improve their business performance by utilizing the insights gleaned from all of that data.

    It is only a matter of time until their benchmarks and modeling become the industry standard.

    But wait. there’s more. Dr. Nicole also told me about some white paper and book projects on the boards at DORA. Again, analyzing the data of all of the State of DevOps reports they are going to shine a light on the ROI of DevOps (I can’t wait for that one), as well as a book by all three DORA co-founders due out this summer further explaining the science and findings behind their research.

    Best of all, because Dr. Forsgren is a PHD professor, most of their work has been collaborated and peer reviewed by some of the leading people in our DevOps community.

    Right now DORA maybe the best kept secret in DevOps, but I suspect before long it will be a household name for those who are striving to be part of high performing IT teams.

    — Alan Shimel

  • How I Bet on DevOps – and Won

    How I Bet on DevOps – and Won

    One evening in late 2015, after the kids were in bed, I sat down next to my wife and said, “I’d like to do something irresponsible. I want to gamble some of our savings on DevOps. I’d like to buy some stock.”

    Nicole Forsgren’s 2014 presentation, “DevOps and the Bottom Line,” opened my eyes to the business impact of DevOps. Then the 2015 State of DevOps Report rolled out with the following tucked into a footnote:

    The publicly traded companies that had high-performing IT teams had 50 percent higher market capitalization growth over three years than those with low-performing organizations.

    I believed the data. It matched my intuition and experience.

    DevOps and the Market

    Companies doing DevOps win in the market. In a world where digital transformation has made competition between companies increasingly dependent on their ability to differentiate through technology, the ones who do best in tech are likely to win. As I heard an executive at an airline put it, “Anyone can spend tens of millions on a new Boeing or Airbus jet. There’s no sustained differentiation there. But a great booking experience … a great mobile app … that can win loyalty.”

    So I found myself thinking that I sit in the middle of a DevOps community and know which companies are bragging about their DevOps successes. I truly believe it helps the business win.

    The Bet, and Winning It

    So that brings me back to that evening in December and the proposal I took to my wife.

    1. This was gambling. We’d risk only a fraction of our savings.
    2. We would buy and hold for one year, then re-evaluate.
    3. I would do no research on the companies we’d invest in outside of their DevOps practices. We would assume other public information would be priced in by professionals acting in an efficient enough market.
    4. Investments would be in companies “doing,” not “selling,” DevOps. No vendors.

    After getting the green-light, I bought a dozen stocks based mostly on the “who talks DevOps at conferences a lot” criteria: Amazon, Bank of America, Capital One, Cisco Systems, Etsy, Live Nation Entertainment, Macy’s, Netflix, Nordstrom, Sherwin-Williams, Target and Verizon Communications.

    So let’s talk about a few of these companies. Amazon and Cisco arguably violate the “no vendors” rule. Amazon I’ve excepted, as the company has a good reputation for DevOps internally, and many of the other retailers included are motivated to DevOps by fear of Amazon. They’re included as a hedge against Amazon killing all retail. In fact, Amazon was my only retailer to beat the S&P. Over the past three years, I found Cisco’s talks of its transformation at conferences (including IBM’s) compelling. Further, the hardware-to-network functions virtualization (NFV) transformation they’re going through seems similar enough to a retailer’s brick-and-mortar to e-comm to warrant inclusion.

    My employer, IBM, is not included because it is a vendor and as an employee its performance already has a big effect on my life. Etsy and Netflix are my “unicorn” contingent. Etsy crushed it for the year (+38 percent). Netflix underperformed (+6 percent) and was a major drag through the first half.

    Retail and e-commerce was generally a weak segment with Live Nation (Ticketmaster), Macy’s, Nordstrom, Sherwin Williams and Target all underperforming the S&P 500. Compared to a retail index fund (XRT), all but Nordstrom and Target came out ahead, though. It was a rough year for the segment, but those investing DevOps seemed to outperform their competition.

    All in all, the approach beat the S&P 500 by about half for the year, albeit with considerably more volatility.

    Good Sentiment, Sketchy Investment Strategy

    That said, a deeper look at this approach makes me think it was more luck than skill. While I believe that high-performing IT yields business wins, I didn’t actually know which companies have high-performing IT. The DORA team has the best data. I don’t. A big financial institution is likely to have more techies than Facebook. Do a handful of them presenting at conferences really say much about their thousands of colleagues? I have doubts.

    DevOps transformations, like Agile transformation, are hard to do at scale. It’s the scale that counts, and will generate the business differentiation. Some transformations led by brilliant champions will end up failing. Mid-year, I was at one of our DevOps networking events talking with someone from one of the companies in this list and suggested that they must be nailing DevOps given what I heard at conferences. The answer was, “Not really … we’re kind of starting over and the people championing DevOps have all left.” I’m not surprised that company is one of my underperformers.

    Sophisticated investors will point out approaches for managing exposure to segments and better isolate DevOps effects from overall market moves. Not researching and using those is another flaw in the approach.

    And yet, if picking stocks at random would yield average results, but DevOps helps company win, and people talking about DevOps likely represent companies with more DevOps than others, it’s not shocking to see this strategy happen to get lucky.

    What Will I Do Next?

    My focus will remain on ensuring the IBM UrbanCode business embraces DevOps practices, mindsets and approaches in every way and supporting IBM’s overall transformation. While transforming myself, I’ll remained focused on helping my clients with their own transformations.  Check out some DevOps success stories.

    As for investing, I’m not a gambler at heart and may simply close down this experiment while I’m ahead and pick a nice index fund. Or, I may refine the picks to only take those that are publicly talking about how they spreading these practices to thousands of practitioners.

    Disclaimer: I’m a techie, not a financial advisor. I recommend improving your own business with DevOps. I do not have a recommendation for how you should invest. Past performance is not indicative of future results. This experiment could have gone badly, and for a while in the first quarter, it looked as though it would. Please don’t take risks you can’t afford based on the experience of a rank amateur investor like myself. This experiment was mine and mine alone. I speak for myself, not my employer.

    About the Author/ Eric Minick

    Eric Minick is a technical evangelist. He joined IBM through its acquisition of UrbanCode. He has spent the last 10 years helping organizations large and small adopt continuous integration, delivery and, now, DevOps. He is a frequent speaker on the topic, and co-authored “Application Release and Deployment For Dummies.” Prior to consulting, Eric was a developer, test automation engineer and support engineer, and has contributed to multiple generations of UrbanCode products. Follow him on Twitter at @ericminick.

    — Eric Minick

  • Puppet 2016 State of DevOps Report Addresses the Most Pressing Issues in DevOps Today

    Report Helps Organizations Understand the ROI of DevOps, Why Quality and Security Should Be Built In, and More

    PORTLAND, OR–(Marketwired – Jun 22, 2016) – Puppet, the standard for automating the delivery and operation of the software that powers everything around us, today announced the findings of the 2016 State of DevOps Report. Over the past five years, Puppet has surveyed more than 25,000 technical professionals, making the State of DevOps Report the largest, most comprehensive and longest-running study on the topic of DevOps. Written in partnership with DevOps Research and Assessment (DORA), the fifth annual State of DevOps Report includes findings on some of the most debated topics in DevOps, including understanding the ROI of DevOps; how building quality and security into the development cycle affects business outcomes; the role of lean product management; and the relationship between employee engagement and organizational success.

    “Today, every company is a software company. Yet there’s a huge delta between the organizations that get it and are able to ship software on demand, and the organizations that take days, weeks or even years to ship simple upgrades,” said Nigel Kersten, CIO of Puppet. “The 2016 State of DevOps Report shows that gap is widening. We hope the report will help organizations identify their own inhibitors of change so they can drastically increase their competitiveness and ultimately, their revenue.”

    The Widening Performance Gap
    The 2016 State of DevOps Report shows that high-performing organizations are widening their lead against lower-performing organizations. Compared to low performers, high-performing organizations deploy 200 times more frequently, have 2,555 times faster lead times, and recover 24 times faster from failed changes, with three times lower change fail rates. Because high performers build quality into each stage of the development process, they also spend 22 percent less time on unplanned work and rework than lower-performing organizations, and thus are able to spend 29 percent more time on new work.

    Understanding the ROI of DevOps
    Since the first State of DevOps Report was published five years ago, it’s been widely accepted that DevOps significantly affects IT performance and organizational performance. The 2016 State of DevOps Report builds on this body of knowledge and provides example formulas (based on survey findings and industry averages) to help organizations understand the potential cost savings of DevOps practices, and the additional value to be gained from investing in DevOps.

    Security
    All too often, security testing is tacked on at the end of the delivery process, leading to expensive and painful fixes once development is complete. The 2016 State of DevOps Report confirms that integrating security into each stage of the development process has a positive impact on IT performance and security outcomes. Organizations that better integrate information security objectives into daily work spend 50 percent less time remediating security issues than low performers.

    Employee Engagement (eNPS)
    Employee engagement is more than a feel-good metric: Companies with highly engaged workers have been shown to increase revenues two and a half times as much as companies with lower engagement levels. The 2016 State of DevOps Report found that employees in high-performing organizations are more than twice as likely to recommend their organization to a friend as a great place to work. This indicates a high level of engagement and identification with the company, and as many business studies show, highly engaged employees are more productive and creative, and provide better experiences to customers.

    Lean Product Management
    The 2016 State of DevOps Report looked at lean product management practices to see if changes upstream in the product management process affect downstream business outcomes. Analysis shows that teams that implement continuous delivery practices and take an experimental approach to product development build higher-quality products and feel more connected to the overall organization.

    The 2016 State of DevOps Report also reveals:

    • Respondents who report they are part of a DevOps team increased from 16 percent in 2014 to 22 percent in 2016.
    • High-performing organizations get more new or planned work done, because they have less unplanned work to cope with.
    • And more insights into how organizations are transforming their cultures and outcomes.

    Sponsors
    Atlassian, Automic Software, CA Technologies, Hewlett Packard Enterprise, IT Revolution, Splunk Inc., and ThoughtWorks

    The full 2016 State of DevOps Report is available for download athttps://puppet.com/resources/white-paper/2016-state-of-devops-report

    Additional resources:

    About Puppet
    Puppet is driving the movement to a world of unconstrained software change. Its revolutionary platform is the industry standard for automating the delivery and operation of the software that powers everything around us. More than 32,000 companies — including more than two thirds of the Fortune 100 — use Puppet’s open source and commercial solutions to adopt DevOps practices, achieve situational awareness and drive software change with confidence. Based in Portland, Oregon, Puppet is a privately held company with more than 400 employees around the world. Learn more at puppet.com.

  • State of DevOps Survey – The Ultimate Feedback Loop

    State of DevOps Survey – The Ultimate Feedback Loop

    If there’s any consistent criticism of the larger DevOps movement, it’s that the talking heads and industry gadflies are driving the conversation, not the people in the trenches.

    All the thought leadership panels and “how-to” content (including the written and AV materials on this very site) make for great watercooler discussion, but lack the input of those dev, ops and IT management pros who are actually living the DevOps experience, some critics have said.

    Well, fair enough. Talking heads are paid to talk. Thought leaders are chosen to lead the debate at conferences and on webcasts. Bloggers blog. Reporters report. This is simply the way of the world. Certain voices are heard via the channels they frequent. It is, as so many people are fond of saying these days, what it is.

    So what about everyone else? What of the people reading this stunning prose and listening to these talks while rolling their eyes based on the connectivity of it all to their real-world experience? How can their voices be heard?

    Independent of jumping into the blogsphere or applying to speak at said industry events – which you should, btw – there’s one significant opportunity available to anyone who cares to take the time – participating in industry research.

    Over the next few business days, citizens of the DevOps world will have their last chance to contribute to the industry’s most widely read and respected research project, the State of DevOps Report.

    If you haven’t done so already, take the time to fill out this year’s survey, and make sure that your voice is heard when the subsequent report is published in June. Sure, it takes a little time, about 15-20 minutes; but that’s because it goes to the trouble of exploring the real-world issues that weigh most heavily on today’s practitioners.

    Why is this particular project so important, or even credible? Consider that the minds behind the survey and analysis resulting in the 2016 State of DevOps Report are those authors and talking heads that actually get the most respect.

    Backed by DevOps Research and Assessments (DORA), the independent think tank operated by a partnership of Jez Humble, Gene Kim, and Nicole Forsgren – perhaps the most respected voices on the landscape, along with Nigel Kersten, the project is categorically aimed at surfacing the truth about DevOps adoption today – not merely promoting the interests of vendor sponsors.

    Like previous iterations of the report, the 2016 edition will focus on topics including IT performance, technical practices, culture, lean management, and organizational performance. This year’s survey also examines several new areas, including the ROI of IT performance, security and compliance, and containers.

    To further entice participation, project leaders are also offering free tickets to the DevOps Enterprise Summit, along with forthcoming books from some of the industry’s leading advocates to a lucky few who take the time to get involved.

    DevOps success is fundamentally based on the notion of increased collaboration and continuous feedback among the people scattered across the SDLC. Likewise, the legitimacy of this research project is utterly dependent on the input of as many real-world practitioners as possible.

    If you’re one of those individuals, and you really care whether or not everyone else involved in the advancement of DevOps understands what this all means to you, do yourself a favor and participate.

    Much like an application being built using DevOps practices, this quality of this project will be directly determined by the degree to which anyone with insight is willing to get involved and build toward optimal results.

    Take the 2016 State of DevOps Survey… today!

  • Puppet Labs Launches Annual State of DevOps Survey

    Puppet Labs Launches Annual State of DevOps Survey

    Puppet Labs has announced its 5th annual State of DevOps Survey. In the past five years, we’ve surveyed more than 20,000 technical professionals around the world, spanning all industries and companies of all sizes. We’ve captured a tremendous amount of data about how IT performance, culture, technical practices and organizational performance intersect.

    What sets our survey apart from the many other surveys out there is that it’s science-based. Yes, there is a science to creating surveys and analyzing data, and there’s also an art to translating all of that amazing data into something that’s useful to the industry at large.

    This year, we’ve partnered with DevOps Research and Assessment (DORA), founded by our friends Gene Kim, Jez Humble and Nicole Forsgren. If you’ve been following the DevOps conversation for a while, their names should be familiar. Together, our goal is to help advance the DevOps community and help technology organizations improve their practices through rigorous scientific research.

    Through our analysis, we’ve been able to quantify IT performance. We know that high-performing IT teams deploy code 30 times more frequently, with 60 times fewer failures, and they recover 168 times faster. We also know the factors that predict IT performance—technical practices such as continuous delivery, cultural norms and lean management—which in turn predict organizational performance.

    This year’s survey seeks to dive deeper into each of these areas, while also shedding light on new areas of research, including:

    • ROI of IT performance. What can you expect from your investment in DevOps? Our goal is to understand how throughput, stability and quality affect the bottom line.

    • Security and compliance. What role do security and compliance play in a DevOps environment? Some people see security as a roadblock to DevOps, but we want to investigate if it has to be that way.

    • Quality. So you’re deploying code faster than ever. What’s the quality of that code?

    • Containers. How do containers affect IT performance? Are they making IT’s job easier?

    • Lean management. Last year we found that lean management practices such as limiting work in process and creating and maintaining visual displays showing key quality and productivity metrics predict IT performance. This year’s survey looks at additional lean management practices to help us better understand what it really means for a technology organization to go lean.

    The survey seeks answers to questions we get all the time and we believe they reflect the broader concerns of the DevOps community. Your experience matters and we hope you’ll share it by taking the 2016 DevOps Survey. It should only take about 20 minutes, and when you complete the survey, you’ll be entered to win some great prizes (see the official rules), including :

    Please take the survey and share it with your friends and peers. Together, we can make IT better for everyone.

    About the Author/Alanna Brown

    unnamedAlanna Brown heads up DevOps research and go-to-marketing strategies at Puppet Labs. She also works closely with Puppet Labs product owners and engineers to develop a roadmap and support for Puppet on Windows.

  • Coaching DevOps Baseball

    Coaching DevOps Baseball

    Coaching DevOps Baseball

    Every technology gets surrounded by hype during its maturation, and DevOps is certainly not immune to that phenomenon. If you’ve spent more than five minutes looking into it, you know that, because the current discussion sounds something like this:

    “All right, there’s other stuff, but it’s just support, so I want you all to go out there and practice the important part! You only win the game if you score runs, and you only score a run if you run from third to home, so get out there and run from third to home! You’ll be the best team ever on the only part that matters, running it in!”

    baseball

    “What? That hitting the ball and making first, second, third base? That’s supporting stuff, doesn’t really matter, master running from third to home, that’s how you score runs, and runs win games! Oh sure, some hotshot can hit a home run, but then the team relies on the guy who can get home runs, so forget about it, just focus on running third to home!”

    Yes, the vast bulk of punditry sound like this right now, and yes, it is as damaging to your DevOps efforts as this coach would be to a baseball team.

    And yes, you need to care about all the other parts of the game – because it isn’t baseball if you only do one part, and it isn’t DevOps if you only do one part. No matter how much the coach thinks that part is the important part. After all, in the game, you’ll never get the chance to run third to home if you’re not able to handle the preceding parts of the game.

    So when you read pundits at the moment, pay more attention to what they minimize than what they consider the end game. The benefits of putting scripts and configurations into version control, building automated testing, taking the time to write automation scripts you’ve been thinking about off and on for years (and putting those into VC also), all of these things are not only necessary prerequisites to the nirvana some foresee if only you do DevOps “right”, but they also hold benefits all their own. Harness your hotshots to automate what’s hard, and make that automation adaptable enough that it can change with the times. The “right” way to do it is methodically. Indeed, I would add the Etsy slogan “measure everything”. You can’t tell how DevOps is impacting the org if you’re not measuring things.

    And doing it methodically is actually pretty easy. Pick a team or (my preference) a project, and tell them to do it. Set standards for keeping each change to configs in version control, demand that they automate as much as possible, but leave points in the process for human checking, require that automated tests are complete and run successfully before the code is considered complete (and set a standard for maintaining tests in the future, since that’s where most orgs have issues). Involve security deeply, because a failed drive, or a server dropped from a bad config can be recovered quickly, a security breech not so much. Then take what you learn, and apply what works well for your org again, perhaps to a larger team or project.

    The whole point of DevOps is to improve IT’s responsiveness to changing business needs, increase operational capacity, and reduce human error. It’s not to achieve some goal set by people outside of your org, it’s to do it within the confines of your org.

    So go hit some home runs, run the heck out of the first three bases, make IT more efficient and effective. Worry about things like “IT Transformation” when they come up and make sense, not when you’re just learning the rules of the game.