State of DevOps - A Continuous Improvement Story

Hello, everyone. We are so excited to be here at DevOps JS. Thank you for joining us for a story of continuous improvement.

Our story today will be portrayed by Amanda Lewis, a software engineer on a team that is responsible for the Kanban application that her team uses for tracking work. And we have Nathan Harvey, who will play himself, a DORA advocate and a continuous improvement cheerleader.

So Nathan, you're a DORA advocate. What is DORA? Oh, right. I'm glad you asked, Amanda. DORA is a research program that's been running for about a decade. This research program looks into how do teams get better at delivering and operating software? Awesome. I am so excited to be able to talk with you today because my team and I have this goal and I think that you're going to be able to help us achieve it.

Wow, that's awesome. Amanda, if I'm going to help you achieve your goal, the first question I have is, what is your goal? What are you trying to do? We want to get the DORA trophy. We want to win the DORA trophy. Oh, great. That feels important, but that is maybe not the best goal. Why? Why do you want a DORA trophy? What are you trying to demonstrate with that?

You know what, Amanda, maybe we could take the quick check together with your team, the DORA quick check, and understand maybe how you're doing today. And that might even help us clarify what your goals should be. I will say, Nathan, we do want the trophy, but we acknowledge to get the trophy, you have to show that you're continuously getting better over time. And so that is absolutely what we want to do. And the team has actually gotten together and taken the quick check. So we've answered these five questions here that you're showing. And then we actually additionally went through that help me prioritize exercise, which was really interesting, you know, talking about our continuous integration, which we're doing really well on. When it came to architecture, you know, do we have control there? We actually really don't. We really like rely on other teams when we're making changes. But then we also answered the questions about culture. And I wanted to ask you, so here's our findings from the prioritize me exercise. And you know, it was great. We're doing well on continuous integration. There's some room there for improvement. Culture is doing pretty good. But that loosely coupled architecture that feels like, oh, we should start there. But the team, like we don't think we can, we don't even know how to get started. We don't really have influence over architectural decisions.

Ah, yeah, I can understand that. And I definitely recommend that you start with something that your team does have the ability to improve. So you can start with a quick check. This helps you set a baseline for how is your team doing today with software delivery performance. And it will allow you to keep track of your score over time as you make improvements. All right. So just to make sure that I understand, because we use the quick check, I want to make sure that I understand what we're measuring.

So with the lead time for changes, we're thinking about when we commit code, you know, to the repo and then when it gets in the hands of our users.

Yes, that's exactly right. Once it's deployed to production, that's when that timer stops. OK. And then for deployment frequency, it's how often we're getting it out there into production.

That's right. We want to think about how frequently are you able to update your production systems. OK. And that change fail rate is when something doesn't go right and we have to quickly fix it or maybe roll it back.

Yeah. I like to call this the O-Expletive rate. It's what happens when someone pushes a change to production and you hear an expletive being shouted out. We can't wait for the next release to fix it. We either have to roll back this change or push forward a hot fix. Luckily today, we don't hear that often, so that's good. And then the time to restore is how fast after we hear that expletive, how long does it take us to actually recover from that and get things back to good for our users? So. All right. All right. I'm glad we understand that. Yes. You know, as we as we looked through this or as your team looked through this, we saw a loosely coupled architecture being one of those things that you could dig in on. You don't maybe have a whole lot of control over that. But what about code reviews?

How are code reviews going on your team? So, I mean, I think they're going OK, but as a team, we definitely saw in this year's report how much an impact of having faster code reviews could have on our software delivery. So it's a place that we want to investigate further and kind of see, is there friction and can we improve it? You know, this year wasn't the first time we dug into this. Actually, back in the 2014 research, we saw that teams were approaching this differently. Teams were being allowed to hold themselves accountable for their quality of code through peer reviews and it worked. Code reviews have been around for quite a long time. In fact, in 2017, we also saw that the highest performers were doing a lot less manual work including automating some of their code reviews and change approval processes. It is possible. In fact, we see that heavyweight change approval processes tend to slow us down.

Not only do they slow us down, they make our changes less likely to succeed. So it's a double negative here. You want to be careful about how long that change approval process takes and it starts with code reviews. This is definitely a place that we could, I think, make some improvement.

As you were saying, as I was thinking about, we kind of have a heavyweight process, especially when it revolves around needing approvals outside of our team. So this might be a great place for us to improve.

Perhaps you could explore how AI might help improve your code reviews. You know, Nathan, that's a good idea. I'm wondering if we're playing bingo because you said that word AI. You know, we love to talk about AI and our team, you know, we've started playing around with it. Most of us are using it in the IDE and kind of seeing how that helps us, you know, code faster.

Yeah, absolutely. You know, in our most recent survey, we saw that AI is really starting to contribute to a bunch of different technical tasks. Of course, it's still pretty early days, but very, very exciting.

While you're waiting for AI, maybe Amanda, I could ask you about your documentation. Oh, it's so important, Nathan. I know. I read it in the report. It's so important. But it can be so hard, right? It takes time. And I know it's something that we should focus on. And we'll definitely explore this. But it is hard.

I know it's hard, but you've sold me. I want, you know, we want to be happy. We want to be productive. We want to get better. And it sounds like if we focus on documentation, we're going to reap the rewards of that.

Absolutely. And I also am interested in your use of the cloud. So as a company, we're definitely starting to use the cloud. They've established a platform team that's working on making it easier for us. For us, we're using it a little bit, but not fully yet. But hoping as we go into 2024, we'll be able to do that a little bit better.

I'm encouraged to hear about your platform team making it easier. We see that flexible infrastructure leads to much better organizational performance. And what really matters is not that you're using the cloud, but rather how you're using the cloud. Are you, as a developer, able to take advantage of things like on-demand self-service and rapid elasticity? These are the things that cloud has to offer. And while lots of teams and organizations have been using the cloud for quite some time, we see that it's more important to make sure that you're using it properly. Not just that you're using it, but rather how you're using the cloud. And our research really looks across a number of capabilities like what we've discussed here today, technical process and cultural capabilities, and really helps teams understand where's my constraint? Where can I make some improvement so that I can get on this journey of continuous improvement where I get better at getting better?

Well, Nathan, thank you for this discussion. You've given me so many great ideas to go back to the team and places that we can explore that are really in the control of our team.

They've established a platform team that's working on making it easier for us. For us, we're using it a little bit, but not fully yet. But hoping as we go into 2024, we'll be able to do that a little bit better.

I'm encouraged to hear about your platform team making it easier. We see that flexible infrastructure leads to much better organizational performance. And what really matters is not that you're using the cloud, but rather how you're using the cloud. Are you, as a developer, able to take advantage of things like on-demand self-service and rapid elasticity? These are the things that cloud has to offer. And while lots of teams and organizations have been using the cloud for quite some time, we see that it's more important to make sure that you're using it properly. Not just that you're using it, but rather how you're using the cloud. And our research really looks across a number of capabilities like what we've discussed here today, technical process and cultural capabilities, and really helps teams understand where's my constraint? Where can I make some improvement so that I can get on this journey of continuous improvement where I get better at getting better?

Well, Nathan, thank you for this discussion. You've given me so many great ideas to go back to the team and places that we can explore that are really in the control of our team.

And I really enjoyed reading the report. Some of the takeaways that I saw was our culture is really important. Having a good culture within our team and organization, if we're going to be successful. Focusing on the user when we're making these change initiatives. Really making sure that we're thinking about the user when we're doing that.

Documentation, I hear you. I see the value. We're definitely going to tackle that. The importance of, with flexible infrastructure, it's how we're using it. And I would say our platform team has been really fantastic. They're really talking to us, listening to us, and it's been really collaborative. So I feel good things are coming there.

And then the section around how work is distributed was really impactful for us. And so we're working on improving and having a process for how we distribute work. Because we don't want anybody to be having more toil or working on something that isn't going to be rewarded down the road. Because that's not fair, and that's not going to make us a happy, productive team.

Yeah, I love that, Amanda. And thank you for reading the report. And I'm really excited to follow along on your journey as you take insights from the report and put them into action. And for those of you that haven't had a chance to download the report yet, head over to dora.dev slash dorareport, and you can download the report and read it today. Find your own inspiration.

And then encourage you to join the DORA Community of Practice. So today, we just started with showing how you can get started on this continuous improvement journey. But over at the DORA Community, there's so many different practitioners sharing how they're doing it, the outcomes they're having. And it's just a great place to connect, get excited, and work together on improving our software delivery. And so I hope you'll join us at DORA.Community. And really, Nathan, thank you for joining me today. Everyone here, thank you for joining us. Really excited to be here, and I hope you enjoy the rest of the talks.