On this week’s episode, we’re joined by Puppet CIO & VP of operations, Nigel Kersten to discuss Puppet’s 2016 State of DevOps Report. Special guests Anders Wallgreen, CTO at Elecric Cloud, and Dan Jones, Skytap Director of Product Management join this discussion by offering some of their favorite findings from this awesome annual report.
We’ve provided a handy transcript below fo those who are unable to listen, and we encourage you to subscribe to The Skytap Podcast on either iTunes or SoundCloud!
Thank you for joining us on this special episode; let’s get on with the show!
Noel: So I just introduced everybody a second ago, separately, but if I could get everyone to just say your name and title and where you’re from, just so our listeners are aware or clear on who’s speaking as they’re listening to the podcast today.
I’ll go ahead and start. My name is Noel Wurst, and I am the corporate communications manager and content marketer here at Skytap. Nigel, would you like to go next?
Nigel: Sure. My name is Nigel Kersten, and I’m CIO, VP of operations here at Puppet, and I’ve been with Puppet about six years now in a variety of different roles, but I’ve been working heavily on the DevOps report that we’ll be discussing today.
Noel: Anders?
Anders: Sure, I’m Anders Wallgren, CTO at Electric Cloud. I’ve been with the company almost twelve years now. We work with all of our customers, largely large enterprise type customers, helping them with their DevOps tooling and processes and a little bit of culture as well.
Dan: I’m Dan Jones, I’m director of product management at Skytap. I’ve been here for a little over a year, and I focus on application modernization, so, helping our customers take their traditional apps and introduce new types of either cloud technologies, or DevOps, and DevOps tooling principals. Prior to that, I did a tour of duty at a large retailer in the Seattle area.
Noel: Awesome. Thank you very much, everybody. So, Nigel, we’ll let you kick it off. We’re talking about Puppet’s 2016 State of DevOps Report. Maybe just for anyone who is unfamiliar with the report, if you want to give a little bit of background as to how it came to be, and how you gather the feedback for that, and just some more information about the report in general.
Nigel: Sure. So this is the fifth year that we’ve run the report. What we do is we survey a whole bunch of technical professionals, around about 25,000 total over those five years. We had nearly 5000 respondents this year. We essentially ask about a whole bunch of different practices and a whole bunch of different performance measures.
We’re asking people, “Are you using continuous delivery? Are you using infrastructure as code automation? Are you doing testing automatically in pipelines?” But we’re also asking questions about mean time between failures, how much time you spend doing planned versus unplanned work, and all sorts of characteristics.
This has been evolving for quite a few years now. I think when we first started, five years ago, it wasn’t even clear DevOps was going to be more than a flash in the pan, which it’s definitely turned out to be a much, much bigger deal than any of us really envisioned, particularly in the enterprise environment.
The general arc we’ve seen over the last five years has been those early adopters who adopted these practices before many of the other enterprises are really starting to pull away from the pack, in terms of performance.
When we do the statistical analysis of the surveys, we end up using a method called “cluster analysis.” We’re looking at the kinds of practices and behaviors companies use, as well as the outcomes. There’s a really tight correlation in the high performing IT cluster between the practices that they embody and this huge orders-of-magnitude better performance in terms of actual outcomes.
One thing that I really wanted to make clear is that we are a vendor in this space, Puppet, but to make sure this isn’t just another vendor report, is so we partner with DevOps research and assessment, DORA. In previous years they’ve been known as IT Revolution, the people who published The Phoenix Project, which many of you may have read. The individuals I’ve been working with pretty closely there are Gene Kim, who is the ex-CTO of Tripwire and has written a bunch of really great books like The Phoenix Project and The Visible Ops Handbook. Jez Humble, who you may know from his continuous delivery, lean enterprise books, and the upcoming, which is a really great read, I’ve got a preview copy, of The DevOps Handbook, as well as Nicole Forsgren who’s an ex-academic and an IT impact risk expert and researcher around IT performance, knowledge management, and DevOps practices.
I think we’ve got some really great topics that we’ve managed to uncover in the course of the survey over the last couple years, and looking forward to the rest of the conversation as we dive into them.
Noel: That’s great. Like you mentioned, some of the results and the impacts of DevOps that you share in the report definitely back up that claim that those who have embraced it are really starting to pull away from the pack. We’ve each got a couple of points from the report that stood out to us, but anyone here on the podcast today, feel free to chime in if there’s anything else you had to say about each point.
One thing that stood out to me, like I was just discussing, that sometimes the scale of the numbers and the findings that you have in there, not that they’re hard to believe, it’s just hard to imagine what that kind of growth actually looks like. One of the numbers in there that stood out to me was “2,555% shorter lead times.” I know lead times, a lot of times, get touted as maybe the most important metric to look at in DevOps, so I was curious, Nigel, if you could describe what “2,555%” even looks like.
Nigel: It’s pretty astounding isn’t it?
Noel: It is.
Nigel: I think what we’re talking about here is when people actually adopt automation and appropriate organizational structure and processes internally to work with that automation. We see, and I’m sure you see this a lot with your enterprise customers as well, people have awfully manual processes in this space. Just things as simple as provisioning a new machine can involve putting in a ticket to the hypervisor team, and then putting in another ticket to the storage team, and then putting another ticket in to the network team to get an IP address allocated, then someone realizes that the firewall needs to be opened up for that particular service. All of these things have a really huge lag time because they involve manual work.
Once you actually adopt continuous delivery practices, infrastructure as code, automated testing, all of these things, people move from lead times to nine months to being able to do things within a couple of hours. It ends up being really transformative for the business. Not only is that just means that you’re getting work done faster, but it means that you’re actually able to respond far more quickly. I think we see this particularly in one of the findings that came out of the report about high-performing IT organizations are spending 50% less time remediating security incidents.
That’s a really huge top-level metric for your CIO or your CISO, or whatever, to deal with. I’d say that I think the actual impact is significantly higher than that. My gut feeling is that those people who are working in an incredibly manual way just aren’t actually addressing those security issues. They’re running old, unpatched bits of software because the process to actually update that software and roll it out and test it is just so unfathomably manual that people aren’t getting around to doing it. Whereas those people who have a highly automated pipeline can go, “Well, let’s roll out this change. We have a testing environment that we know matches production. We can actually investigate that, see how well it works, and then we’re done.”
I think that general being able to respond in a significantly more agile way just has a really huge transformative impact across the business. I think it also uncovers some of the things that companies simply aren’t doing at the moment. Or even worse, that old term that many of us in IT end up loathing in many ways of “shadow IT.” But if your IT services organization isn’t allowing your development teams, your digital teams, your marketing teams to actually work quickly, at the speed they need to, they’re going to go around you and find another way.
I feel like every day I’m seeing another security company pop out there which is essentially offering a promise around, “We can find all of the infrastructure out there on the cloud that your IT department doesn’t know about.” That’s a real problem for many businesses.
Noel: Absolutely. Dan or Anders, do either of you have anything, as far as some of the magnitude of DevOps impact that’s discussed there in the report?
Anders: Yes, I think it’s really kind of interesting, too.
Nigel, you said, “we can respond in an agile way,” and I absolutely agree with that, but I think it goes a little bit deeper psychologically than that. Teams that have a robust automated software pipeline, can operate with confidence. You can try things. You can experiment. You can work fast because you know that if you break something it’s going to get caught in the pipeline.
That’s a fundamentally different mindset that people have. It does take away a good chunk of the fear that people have when faced with a situation of, you know, “We have an open SSL security issue. We need to go patch hundreds or thousands of systems. How are we going to do that without screwing up?” That’s where things grind to a halt in more traditional- type organizations.
I think I agree. Low performers are just not addressing these issues at all. In some sense, the percentages are infinite in some of these measurements.
I think it’s almost understating it to say that we’re able to be more agile. We’re able to be human. We’re able to be more confident and get more things done, which is pretty spectacular. We see that in Fortune 20 banks, in large enterprises, and even in government institutions and aerospace institutions. Places where you would expect to see a lot of slow moving, cautious types of behavior. We’re seeing much more rational, fast behavior with these methodologies, which is really fascinating and very cool.
Dan: You mentioned, Anders, the rework and catching things earlier in the cycle. Pretty much every software shop I’ve worked in, whether it was enterprise IT or at an ISV, the top sustained engineering or break-fix work versus the time you spent on new work is a topic of discussion, and what are the right percentages. The report shows pretty clearly that the high performers are spending far less percentage of their time on rework than the median performers and the low performers.
That’s going to lead to higher employee satisfaction. It’s a creative field that we work in, and people want to be creative and do high-value activities, not running around fighting fires or picking up after others. I think that high employee satisfaction and getting to do new bits of work and be creative creates a great environment for those people, and then it starts to attract new talent to the organization. Greatness attracts greatness. People want to be part of something fun, something meaningful, and good.
Nigel: I really like that point about, it not just being about agility, but about removing fear in many ways. I think that also helps you onboard new staff. It lets you hire people and make them more productive more quickly. It also helps you level up your junior staff significantly more.
I think, particularly in the 90s, a lot of the IT shops I worked in, there’s a relatively long apprenticeship you do as a SysAdmin before people let you touch production because there’s just so much fear around what happens if you type the wrong thing in. That’s actually going to affect the running service.
I think the more we can do in our industry of leveling up our junior people, and I think we’re all struggling with how to improve diversity and stop having such a mono-culture in the tech industry. The more we can enable new people to enter the industry, pick up skills quickly, operate with confidence, and actually produce, for want of a better term, business value for the company, the better we all are. We need more diverse voices in this industry.
Noel: That was the next point I was going to get to. A lot of times people expect metrics to be around things like time to market and defect resolution and the shorter lead times, but there’s a whole set of other more creative metrics around employee loyalty. You know, job satisfaction, retention, talent, all that kind of stuff. That’s definitely there in the report as well.
Anders, I know you mentioned you do some stuff with culture there at Electric Cloud. I would love to get your thoughts on how DevOps enables some of those things.
Anders: It’s interesting because we’re a tools vendor, that’s what we do. We all know you can’t buy DevOps in a box. If you could I would certainly sell it to you, but you’re going to fail spectacularly if you don’t pay attention to the culture and all of those other things.
I think one of the things we’re seeing quite often is there really is a correlation with employee churn. It’s not just about keeping the existing people happy, it’s about preventing them from walking out the door.
We work with a very large trading firm, I can’t use company names, unfortunately, but a very large trading firm that we’ve all heard about. They’ve gone from spending entire weekends doing deployments to where deployments are now a forty-five to sixty-second process.
I’ll never forget the first time we demoed that for the managers in the team that we were working with. They were just sitting there and somebody said, “Well, when does it start?”
And we said, “No, no. It’s done. It’s finished. Do you want to see it again?”
It was so fast that they conceive that it could operate that quickly. All of a sudden, the room erupted in, “Okay, if we can do deployments that fast, that means we can also,” you know….
Now, all of a sudden, all of that energy and time and stuff that was hung up on, “Oh, my god, it’s going to be another weekend from hell. Everybody’s going to be on a conference call until the early wee morning hours, and all of that kind of stuff, turned into, “Now, what can we take that time away and do useful things with?”
Obviously, on the weekend it’s, “Be home with the family.” But even during the week, all of a sudden you’re freed up to do lots of things.
It’s a big deal for these companies, especially if you have to do trading hours and those kinds of things, where you by definition are only going to do deployments during off-hours. That’s a huge load for people to no longer have to bear the burden of.
For us, it’s interesting to see how technology and culture impact each other because you need all three legs of the stool. You need people, process, and technology. But improving one leg of the stool actually helps you improve the others. Getting some good technology in there all of the sudden frees you up to think, to breathe, to do all kinds of other things. That has an improvement on morale and has an improvement on how many people are going to walk out the door because they’re pissed off at how you do things.
It’s really been interesting to see not just the individual ways that the legs of the stool, if you will, work individually, but also how they impact each other, and how you get a positive feedback loop once you start to really strengthen the core aspects of one piece of the puzzle and how it impacts everything else. It’s really fascinating.
Nigel: I think you’ve hit something really interesting there, which I’ve seen a lot in the financial services industry as well, which is those technology improvements do lead to process improvements and people improvements. The really concrete examples I can think of are the people that are moving to the next level in automation, where they’re not just automating the infrastructure layer, but they’re automating the deployment of applications on that infrastructure layer, and using a combined infrastructure-as-code approach to manage both of those things.
There’s often a lot of push back where people say, “Well, you know, we develop apps in fifty-five different ways.” I think many people who don’t work inside those organizations and verticals don’t really realize just how many software developers the large banks have, and how many software apps they actually run.
Anders: Absolutely.
Nigel: There’s tens of thousands of them.
Anders: Yes. The Fortune 20 bank that we’re working with has over 6,000 applications in just this area of the bank that we’re working with … and something like 145,000 end points out in the data center or in the cloud. The scale at which these guys operate, and obviously other than financial companies operate at that scale as well, but the key point being, I think, the number of different applications that you have to deal with. And the different toolchains, and technology stacks; it’s bewildering for these people to just, “Where do we start? How do we onboard all of these things?”
Nigel: Totally.
Anders: It’s a lot of scale to deal with.
Nigel: Yes, but I think once you put in those technology layers that let people get those incredibly dramatic effects, like the deployment you were just talking about, people can’t go on board. They’re like, “Yeah, we will rewrite those twenty simple applications that are all running differently. Previously I wouldn’t have bothered. I would have said, ‘No, that’s just busy work. Why rewrite things that are already working?'” But once they see these incredible gains in deployment speed and reliability, people just start doing it.
I think the technology improvements lead to process improvements, lead to consistency, which ultimately leads to higher engagement because they’re to do more interesting work during those limited time periods.
Anders: People are incredibly rational for the most part. If you give them painful things to do, they’ll do them but they won’t be happy about it. If you give them less painful things to do then, yes, they’ll exert more energy in favor of the cause, so to speak.
Dan: I think getting to that solid foundation of “process and tools that support the process” is essential for any team.
When I started my career, I was a COBOL programmer on a mainframe working on a payroll system. We would release new code twice a month, and we would run payroll twice a month. After my first couple months there, I started asking, “So when do we run payroll?” Because the demeanor of the department never changed. Everybody was calm, everybody was relaxed. We’re running payroll for 80,000 employees in the US and this was a company full of engineers that would call up if their paycheck was a penny off. The margin of error is pretty low there. But there were solid processes and solid tooling in place to support the team in doing their job. As a result, we could all relax.
Fast-forward twenty-two years, and my next tour of duty in enterprise IT, people were so fearful of deploying anything into production. Throughout the calendar year, there were multiple dates of freeze times, where there are no changes to even test environments for fear that a change to a test environment could somehow break a production environment. The complexity is tremendous from then to now, but there weren’t the process and the tooling in place to support that complexity.
Nigel: I think that fear has all sorts of other effects. Not to pick on Red Hat at all, they’re serving their market very well, or even Microsoft, but the big enterprise OS vendors end up having to have these huge extended support cycles where they’re saying, “You can pay a bit more and you can still keep running ‘Enterprise 4’ for another four or five years.” That just means Red Hat’s not spending that effort on innovation, and all of the vendors who have to support software are having to make sure they support older OSs. The more that cycle-time manages to speed up it really is a rising tide that lifts everyone.
Anders: It’s amazing how much more productive you can be if you’re not tasked with something a computer can do for you, much better and much faster. It seems like an obvious thing to say but so much of the industry really spends its time doing stuff that doesn’t need a human.
That doesn’t mean to say “go fire all the humans,” you just find more valuable things for them to do. It’s exciting to see when that happens. It’s satisfying.
Working in software, even working in DevOps-type software, we’re not really saving the world here. We’re not Doctors Without Borders or anything like that. But to see an organization’s “organizational light bulb” go on above their head is pretty cool to see.
Noel: This gets into the next note I had here, where the report talks about unplanned work and what DevOps’ impact is on that. We discussed this in our briefing with each other before this recording, but how widespread unplanned work can become, and that when an organization that’s developing software is all of the sudden stuck doing unplanned work, and it’s delaying a future release, or a support request, or any kind of new features being delivered, it really all of the sudden starts to create unplanned work for your customers as well. It’s impacting not just within your walls but it’s creating work for your customers who are now unable to do their job because they’re waiting on you—because you’re doing unplanned work.
Nigel: That was one of the key metrics we really wanted to measure because we’re going to try to work out how deliberate were people being. Was there actually a huge difference between people in DevOps environments versus pre-DevOps, to be somewhat optimistic about it, and what were their ratios of unplanned work like. I think this is a reality. The more time you can spend doing planned work, they’re the features that you’re shipping, they’re the things that are creating business value, it’s the unplanned work—and there’s always a certain amount of unplanned work in our space. We’re not going to head towards some nirvana where we no longer have Heartbleed, or all these giant industry-wide vulnerabilities hitting all of us.
You just want to minimize that stuff, because the planned work is where you get to actually address technical dirt, and unplanned work is often where you create it.
Anders: It’s interesting, too, because traditionally when we talk DevOps and continuous delivery, a large majority of the time we’re addressing web companies, web properties. A lot of our customers are embedded, they’re even on-premises type applications, and things like that, as well as, obviously, large web customers as well. This is starting to take root even in the non-web type companies: aerospace, defense, those kinds of things.
It’s interesting to see how they look at the way that they do software. The amount of planned unplanned work that they actually have to deal with. They have months-worth of time in their development processes that are reserved for, “Okay, this is when the s*** hits the fan. This is when we’re going to have to fix all the unknown problems.”
They’re starting to get to the point now where obviously they realize how screwed up that is, and that has to get fixed, and are willing to make a lot of changes for that. In those kinds of traditionally slow-moving, conservative type environments, in some ways, to me, that’s a real hallmark of the success of the movement, as it were.
Noel: Dan, I wanted to ask you about something. One of the things in the report that stood out to you was that it really drove home the importance of smaller batch sizes and deployments. Whether it’s related to less unplanned work, or fewer defects, or whatever the benefits are. I’m curious as to what stood out about that about you?
Dan: I always used to get hit up from business users, when we would talk about projects and when we could deliver certain functionality, they would use their phone as an example. They’d say, “The apps on my phone update almost every day. These companies seem to get functionality into my hands so quickly. You guys are right here with me, and I’m asking for this little thing. Why does it take so long?”
I think it was the fixed cost to move an idea through the pipeline into implementation was just so high. As I mentioned before, there was a lot of fear in making those changes. Once you can break through that fear, you can start putting the tooling, the processes, in place, and build that confidence.
We see from the survey that the high performers are deploying more frequently. The lead time to get changes deployed is much shorter. That means there are going to be fewer people involved. That means it’s going to cost less. When something goes wrong—it’s never an if; things are going to go wrong—the time to recover is so much shorter. And, actually, the overall change failure state. We see that much, much lower on the high performers than the median and low performers in IT.
The high performers can satisfy their internal customers who are expecting that instant gratification from, “I have this idea. Let me see it expressed in the application that I’m using on a daily basis.” That leads to greater satisfaction from the external consumers of IT, and within IT, and it’s all based on smaller batch sizes.
Nigel: I don’t think you can over-emphasize the huge impact that the phone OSs that we all deal with now, and consumer SaaS just add on the pressure for development and operations people. Suddenly everyone’s expectation was, “This is ridiculous. I can go to a website, I can put in my credit card, I can click a few buttons, and I get a thing. Why is enterprise IT so bad compared to this? Why does my phone work like this?” I think that was a huge pressure for a lot of these changes.
Anders: It’s the ultimate consumerization of IT. Aside from bring-your-own-device and that kind of stuff, yes, we’ve got expectations now. Why do we suck so much more that these guys?
Benchmarking is always good, and it’s always good when the bar starts to get raised. It’s a really great thing to see.
Nigel: One thing I wanted to touch on with the small batches really quickly was a really great finding from last year’s DevOps report, which showed that you can’t just have top-down support from your executives, and you can’t just have a grass-roots movement implementing DevOps practices. The middle managers turn out to be key to this process because they’re essentially turning strategy into tactics, and letting tactical results feed back into strategy. If they’re not on board, you can’t get this done.
The most visceral example of that is that middle managers need to embrace failure in a different way. When you’re working in small batches, you’re also going to fail more frequently, but the cost of failure is so much lower that overall velocity and progress is much higher.
If you’re implementing a highly-automated system, moving in small batches, and yet your middle managers are still haranguing individuals who are going, “This is no good. One out of ten changes is failing.” You need to push that culture all the way through the management layer.
Anders: You almost have to change the math a little bit. You have to think, not in terms of raw failure rate, but in terms of attempts not made, right? “I didn’t want to try to do this because I didn’t want to fail. I didn’t want to screw up.” That should count as a failure, not as a not-counted thing.
I think if you were to do that sort of accounting magic, most organization’s failure rates would go way up. You would stand out even more if you were an organization that encouraged experimentation and failing rapidly.
Nigel: I think this makes all of the metrics quite astounding. We’ve already talked about several instances where we’re talking about a dark matter of unobserved attempts made and incidents not resolved.
Dan: Here’s another dimension of small batch sizes, and the report doesn’t measure this, but having led large and small teams, I’ve got to believe that this comes into play, and that’s performance review time.
I would work on projects that would be a year or two years in nature, and of course, it never lined up with when my performance review was happening, so my review was always happening mid-flight. It’s really hard for a manager to say, “Look at all the great stuff you’ve done.” When it’s still on the drawing board.
You move to smaller batch sizes, and stuff is moving through that pipeline, and the conversation changes. “Here’s the tangible business value that I delivered in this period. It was these eighty-three different changes. Sure eight of them didn’t go well, but we learned a lot and made those corrections for the last nine of them.” That’s a very productive performance review discussion, and there should be incentives and bonuses tied to that sort of thing.
Nigel: That’s a fantastic point.
Noel: That’s great. It really is. We’ve got time for one more, and originally I had just planned this for Nigel but I’m curious to get your takes on it as well, Anders and Dan. What do you do with the report now, or the information that you found in there?
Obviously, everyone has admitted that we’re all vendors, so using it to further our own cause is one thing, but what kinds of things does it make you think about? Is it sharing the information? Is it trying new things? Is it being less afraid to try new things? Not being afraid to fail? What plans do each of you have when you learn something new, or a new way to measure the ROI of DevOps? What kind of things does it bring to mind?
Nigel, I’ll let you start.
Nigel: Sure. As you said, a lot of this, to be honest, is about making sure that Puppet stays as a prominent voice in this whole movement, but I think there’s a bunch of really pragmatic useful things for the whole industry.
One that I think is really easy to discount is that “enterprise DevOps” was almost a term that was mocked in the early days. Particularly we’d see people make jokes about, “You can’t do DevOps on mainframes. You can’t do DevOps on ERP systems.” It turns out none of those things are true, and The DevOps Handbook I mentioned earlier has a whole bunch of really great case studies around that.
One of the things I’m most proud of with the report, though, and I’ve heard this a bunch of times from practitioners, is because we end up being focused on the value to the whole business, and we connect that with the actual practices people are using at the grass-roots, it gives sysadmins, who aren’t always the most people-oriented people in the world, a way to engage with their management chain, and go, “This is why we should do these sorts of things.” IT gives them some of the language, and some of the outcomes and goals to be able to actually engage with their management and convince them to change things, convince them to try how things should work.
Also, it gives them an idea of what should they be measuring in order to build those cases internally. I think this is one of the big cultural changes the DevOps movement has pushed. Operations people can’t just be the IT cost center sitting in the basement constantly spending money and never actually being recognized for delivering any value. It’s a point of interaction, I think, between individual practitioners and managers for practitioners who haven’t generally known how to speak to their C-suite.
Anders: It’s amazing ammunition in those kinds of scenarios. One of the things I do all the time is point people to the report and hit them over the head with the numbers, right? The sheer quantity of data and the quality of that data as well grows and grows and grows. It becomes difficult to argue ad hoc against that kind of data.
I think the other thing that I do often is; look, people are doing this successfully. It gives people a little bit of hope that we can change, that we can do things differently. There are companies and organizations out there that are doing these things differently, doing it better, having better outcomes, having happier customers, having happier employees.
It’s really a question of applying a little bit of the scientific method to how we’re doing business. It’s not Sloan School of Management/HBR, top-down management kind of stuff. There really is a place for experimentation and figuring out key metrics, and how they matter, and how to really measure them, and how to really act on them. I think it’s a good hopeful message to throw in people’s face.
If they don’t respond to that, then you flip it on its side and say, “Look, your competitors are doing it. You’re going to be out of business if you don’t.” The numbers say that, too. The orders of magnitude of difference are fairly substantial, so you want to be on one side of that equation, not the other side of the equation. If you’re rational.
Dan: It always seemed to be the case. I’ve lived through the Rational Unified Process, and CMM and agile, and scrum, and all those other things. To be able to benchmark your team against others was always really hard. The data was never readily available, or it wasn’t done scientifically. I think the consulting firms made a killing off of this.
You’d hire whoever to come in and, “Well, we’ve surveyed 100 different shops using the Rational Unified Process, and we’ll measure you and tell you how you’re doing versus those other shops.” Who has the time and money to do that? What the report gives us are those benchmarks.
It also provides that justification for those seedlings in the organization that are fed up and they want to try something new. They can take the data to their leaders and start driving change, to the point of, “Here’s what you should be measuring, and here’s how you line up against others.”
Anders: I think that is a really impressive component of the report. It does speak both to grass-roots and to higher up in the management chain. That’s a little bit unusual. Lots of reports, lots of people’s opinions, even if they’re full of data, often times speak only to one audience. The fact that you can use this report to speak to all up and down the reporting chain in most if not all organizations speaks really well to the quality.
Nigel: You’re all so kind. That makes me feel awesome.
Dan: It’s easy for some to maybe look at it and say, “Well, that’s just a marketing tool by Puppet.” I think you’ve done a really good job of trying to show the data and the methodology is independent. This is not Puppet’s spin on the world, this is what we’re actually seeing out there.
Nigel: I do feel really obliged to mention, again, the DORA folks that we work with. Nicole, Jez, and Gene, because this is what they do now. They’ve become a research and analytics firm. They’re filling in the gaps in many ways, where some of the big analyst firms have not necessarily picked up where this movement is going very quickly. I think benchmarking industries is going to be more and more important.
Anders: Also, the DevOps Enterprise Summit, that IT Revolution co-founded with us at Electric Cloud.
Nigel: Fantastic Conference.
Anders: It is a great conference. I love that conference because it’s like a DevOps support group. “Hi, my name is Anders, and I do DevOps.”
Nigel: Someone made the comment, “This is the first DevOps event I’ve been to where no one’s in a t-shirt.” I think that is a really visceral example of the impact this is having.
Anders: Very true.
Noel: Thank you, everybody, for joining us today. That was great, that we were all able to share our appreciation for the report and for putting it out there. It almost becomes a case study that a lot of people are able to use, rather than just about a single customer and coming from a single company.
Thank you so much, Nigel, and Dan, and Anders!
Nigel: No worries.
Anders: My pleasure.
Dan: Thank you.
