when-do-you-need-a-devops-coach

Podcast Ep. 97: When Do You Need a DevOps Coach?

when-do-you-need-a-devops-coach
Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

We have a special repeat guest on this week’s episode. It’s Barry Matheney. He is a senior DevOps consultant and one of Dan’s colleagues at AgileThought.

So often, teams operate on a “get it done” model and try to push their code out the door as quickly as possible, but that is not sustainable and not the markings of a high-class professional team. Barry understands the Scrum teams’ main mission and purpose is often very wrong; it’s to appease the Product Owner, not create purposeful and meaningful end-results.

In this week’s episode, Barry shares his thoughts on when it’s time to hire a DevOps coach for an organization, some of the troubles organizations run into (problems with easy fixes), when it comes to their Scrum teams, and when you know when your team is on the right track in their DevOps journey.


Listen on Google Play Music

Listen on Apple Podcasts

Would you benefit from a DevOps coach?

Key Takeaways

  • What’s the working definition of DevOps?
    • It’s about delivering better value, sooner, safer, and happier
    • The difference between agile and the DevOps motto is the definition of what “done” truly means
    • True north for DevOps means there is a continuous delivery and a continuous deployment
    • If you have some DevOps influence in what you’re doing, you’re on the right track
  • What are the best ways a Scrum team can get started?
    • Typically, when a Scrum team gets started, the sole focus tends to be delivery of stories. AKA, making the Product Owner happy
    • Most Product Owners don’t care about dashboards or reliability. However, they should. The scope of a Product Owner should include the production world as well.
  • When do you need a DevOps coach?
    • It’s a tough answer. It depends on the team composition
    • If you have a junior team, they won’t have the experience to know the consequences of bad code
    • The journey begins as soon as you begin production
    • You build resiliency by delivering something that cannot fail, something that was built to last. That takes planning and continuous development. Junior teams might not be thinking in these terms just yet
  • How do you know when you should be leveraging DevOps?
    • What times do your deployments occur? If you deploy them during off-hours, then something is wrong
    • Deployments should be normal working events and not interruptions to your life
    • Do your organization’s security teams always seem to be diving into your business?
    • If you can provide compliance and proof to your security teams, then you’re on the right track and have thought about all the possible security risks
    • Anything that happens should be logged
    • You don’t need to manually tinker in production
    • Software teams want to get things out the door, but that’s not operating at a professional level
    • The transformation is not about your Scrum team. It is an organizational transformation
  • What’s the distinction between an agile coach vs. a DevOps coach?
    • Agile coaches plant the ideas
    • DevOps coaches can help build the prototypes together and experiment with different theories
    • DevOps coaches give a continuous approach and re-examine practices that were put into place 10 years ago that may not be relevant now
    • DevOps is an organizational challenge, not necessarily a team challenge
    • Waste is bad, so you need to either scrap the project or get it into production
    • Remember, DevOps is a journey

Mentioned in this Episode

Transcription [This transcription is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]

Intro: [00:03] Welcome to Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host coach and agile expert, Dan Neumann.

Dan Neumann: [00:17] Welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host Dan Neumann and joined by guests Barry Matheney. Welcome, Barry. Thanks for joining.

Barry Matheney: [00:25] Thank you for having me.

Dan Neumann: [00:27] And you are a DevOps coach within AgileThought. And for folks that are interested in other DevOps topics, you’ve got to go on the way back machine in the podcast feed. We’ve got two that you were on back in February and March of last year of 2019, which seems like forever ago at this point about embedding DevOps into a large organization and the importance of embedding DevOps skillset into your team. So you paired up with Eric Landes on one of those in one was with me. So we’ve, we’ve got some other DevOps topics when people like more of that DevOps stuff.

Barry Matheney: [00:59] And if you and I talk, hopefully it’s about DevOps.

Dan Neumann: [01:03] And why do you say that?

Barry Matheney: [01:05] Um, because that’s what I like to focus on, and that’s what I like to talk about. And I love the conversations that we get into and the one that we’ll have today about the differences between agile coaches and DevOps coaches.

Dan Neumann: [01:20] Definitely. I think that’ll be interesting because I think from just our prep, we see the world a little differently when it comes to agile and DevOps. So that’s fun. Um, it’s a really kind of anchoring around when do you need a DevOps coach and maybe even then, what, what does a DevOps coach do for you?

Barry Matheney: [01:37] So, first of all, I’ll say that’s not an easy answer. There is no easy answer to this. If it was, it would be here’s your form, fill it out, go hire yourself somebody to come in and give you some DevOps. Right. Um, so I kind of look at it as if you’re in a safe environment, hopefully you’re already getting it right,

Dan Neumann: [01:53] You mean you don’t mean like the, um, modern, agile, emotional safety scaled, agile frameworks, cause I’ve seen unsafe, safe. That might be a different topic. Um, so assuming you’re in a, um, a safe environment, that’s good.

Barry Matheney: [02:17] Yeah. There is more than in its infancy about that. Then you should be starting to see the coaching and the alignment among the delivery of your teams to make sure that in the column DevOps practices, to me, they’re just continual improvement to get, you know, software into production in a more efficient and predictable way, high quality software specifically, right.

Dan Neumann: [02:44] Let’s for brief digression, do you have a working definition of DevOps that you use. Cause I remember from some previous episodes DevOps that there’s the agile manifesto for the agile stuff, but then it seems to be a whole set of opinions about what DevOps is. And so maybe just for the purposes, just a little snippet for us to hold on to, for DevOps.

Barry Matheney: [03:05] I’m going to, I’m going to go way back in time. So right. So John Willis and Daymond Edwards came out with this thing called CAMS, right? Culture, automation, measurement, and sharing. And then, uh, Jez Humble, added lean in there, so became CALMS. And then we’re like, what the heck? Right. And so I, I don’t know if you’ve ever seen it or heard Steven talk about it, but it, you know, influencing executives to invest in your methodology, they really need to understand what the business value of that is. Right. If I say CAMS or CALMS and try to explain it, I’d lose everybody. So recently, as recently as last year, Jonathan Smart from Deloitte came up with a great definition, right? And he’s actually writing a book with this title better value, sooner, safer, happier. And that’s the definition, right?

Dan Neumann: [03:57] That just sounds like agile to me.

Barry Matheney: [03:59] Um, so, okay, great point. I agree. I don’t disagree with you from that.

Dan Neumann: [04:04] You can disagree.

Barry Matheney: [04:06] I think the difference is our definitions of done differ, right? Most agile is to provide a shippable increment DevOps is about operation and production and providing value.

Dan Neumann: [04:21] So, and specifically I think you’re talking, Hey, scrum team, we have an increment at the end of the Sprint, which is potentially releasable, but it may or may not go anywhere. And your saying, Hey, you know, well-functioning DevOps environment. That increment actually goes into production or even slices of that increment as you go through you’re between one and one, one week in one month time box go into production.

Barry Matheney: [04:44] Yeah, exactly. And if you look at it, every DevOps practice, so true North for DevOps is effectively continuous delivery and continuous deployment. So if you’re striving towards that and you’re improving towards that, then you’re probably implementing or, you know, having some DevOps influence in what you’re doing. And if that’s your mantra for process improvement, then um, you’re headed in the right direction and you may get to points where you stall and you’re not making the progress that you’re looking for and you need new ideas and new concepts and new ways. And that’s kind of what we’re talking about.

Dan Neumann: [05:20] Okay. Very cool. There was a, there was a comment you had made, uh, and let’s talk about, so teams getting started, if you remember what you said about the focus of a Scrum team getting started.

Barry Matheney: [05:31] Um, my experience has been that the Scrum team, when they’re first getting started, their sole focus is on delivery of stories, making the product owner happy. Right. And there’s no focus and no is a strong word. Right. But there’s not as much focus necessarily on quality, resilience, reliability, all of the factors that we take into consideration in the DevOps world.

Dan Neumann: [06:00] All the ilities. Yeah. And I, and I, my reaction to that is like, they probably have a bad agile coach, but I think you’re, I think your point is, is correct. That that is the place that lots of teams start at. Right. It just, Hey, can we get a feature or PBI story, whatever, whatever they’re calling, those things that they’re delivering out of their product backlog. Can we get some of those to our teams definition of done, maybe that’s just built and tested in our two week Sprint.

Barry Matheney: [06:31] What are we going to show our product owner? Right. Yeah. And your product owner doesn’t care about dashboards, about reliability they should. Right. And I think that’s one of the key points. If they’re looking for, uh, to me, the scope of the Product Owner should be, it should include the production world as well. Right. And making sure that those features are operating in a way that, um, that, that the team is it in toil is an SRE word right. Where they’re not spending time that doesn’t provide value to the product itself.

Dan Neumann: [07:02] Okay. That’s fair. Yeah. It’s kind of doing the tasks that can be automated and that machines can do. Is that what you mean by toil?

Barry Matheney: [07:10] Toil is, is a task that someone has to do has to get done, but it doesn’t add any real value. In other words, the machine is locked up. Somebody has got to go log in and reboot that machine. What’s the value of that. We got to have the machine, but it also took that person away from doing something that they could be adding value with. Right? There’s a lot of there’s the whole SRE world, right. Is built around a lot of those practices and there’s a real, there’s a certain amount of toil that your operations people should have and that’s to help make sure that they don’t lose their skills. They understand the systems, they understand what they should be doing. But at the same time, if they spend an exorbitant amount of time in doing that, it becomes toil and nobody wants to go do it anymore. Right?

Dan Neumann: [07:57]
Yep. It’s it’s the, uh, the, the poor work, if you will, you’ve got, then you’ve got Scrum teams on that are maybe brand new. Maybe they haven’t done any Sprints yet. Maybe they’re new. Then eventually, maybe you’ve got teams that are, like you said, are focused on delivering product backlog items in a Sprint and a time box and you not just Scrum, but it’s easy to think about Scrum. Cause there’s there’s lot of Scrum teams out there. And, and then at some point, are you saying when in that continuum, from there to, um, the teams, a fairly mature Scrum team, where in that spectrum, do you think you would advocate to say, Hey, you really need a DevOps coach.

Barry Matheney: [08:38] So I don’t think that’s an easy question to answer either. Right. And I think so you’re exactly right. So the team composition is really going to matter if you have, you know, if your team is relatively junior, they’re not gonna, they won’t, they won’t have the experience to know, you know, the code that I write is going to wind up in production and it’s going to, it’s going to impact somebody else’s life, right. It’s going to impact the way their weekends work. Oh, by the way, it’s going to impact the way that we work in terms of when are we deploying and how are we deploying and how much confidence is the rest of the organization have in our capabilities to do the deployments. Right? So it’s the, the journey begins as soon as you go to production. And I can tell you that probably the first indicator from my perspective is how difficult, if you’re a new team and it’s a new product, how difficult was that first deployment and that first release into your production environment, you know, what did it take an army to do it? Or was it relatively simple, right? I’m not saying it was a hundred percent automated, but at the same point, you could see the goal line in terms of keeping things to the point of little or zero error can happen. Right. And I love this quote. A long time ago, I worked at Capital One, right? And they’re one of the few banks in the world that does continuous delivery and continuous deployment financial services doing DevOps all the way to pride. You do your check-in, the test run. And it winds up in prod in just a few minutes. That’s pretty cool. Right?

Dan Neumann: [10:10]
But Barry, we need security and we need to be auditable. We gotta have a, you had to have somebody look at that, Barry. You have to, you can I hear the financial services people.

Barry Matheney: [10:26] You can do that actually. And one of the cool things, so two things I’m going to tell you. So the first thing was when I was at Capital One, we had gotten an, what was called a memorandum of understanding for the federal for investments, right? That memorandum was because we had bad credit ratings. So we were making money, hand over fist, but we were bad credit ratings. And Rich Fairbank’s stood up on stage. And he said, we got in trouble. We are going to become unassailable. And that term wow. That term. So that’s when they started buying bricks and mortar banks and started doing and got everything in line that came out of the MOU. And they’ve never been in trouble since basically, right? Because you change the way you do your business. And that term sticks to me in terms of software delivery, how I deliver something that can’t fail, right? How do I deliver something that I can hand to somebody that’s resiliency, right. That is making sure that the product operates in the environment, whether it was a, uh, uh, what’s the right term, um, an environment that was meant for it, right. Or whether you wind up sticking it in a little machine somewhere that wasn’t configured for it naturally, you know, either report what was wrong or so the, the unassailable piece to me is really the key from a development team perspective. And if your team is made of junior, you know, junior level people, you’re just not going to have that thought process of how do I design and implement features. Cause that’s how we’re still talking about. It’s not about making the feature, do what you want it to do. It’s making the feature, do what you want it to do and sharing, I’m not going to get a call about it in three months because I didn’t do something that I should have done when I did it.

Dan Neumann: [12:32] So you’re, you’re one of the opportunities then to need a DevOps coach, I think is you said when it goes to production and I’ve seen a lot of teams really struggle with getting it into production configured, right. So that they can flip the switch. Oh my gosh. We, uh, a configuration file. Shoot. We forgot. We’re pulling it into a database back in dev still up. Jeez. This thing doesn’t scale. Oh, that would never happen, right? No, it doesn’t happen on every single team that goes to production the first time. Maybe they’re new to the cloud, especially new to cloud, especially I’ve seen them stumble even internally. Oh geez. We forgot the firewall rule on the who’s that and nothing works. Right. But I was just thinking, so is, do they really need that DevOps coach earlier in that, um, much earlier, potentially than when they actually want to go to prod less, they want to go to prod go two months of, or more of Holy cow firefighting.

Barry Matheney: [13:31] Yeah. I saw something the other day and I was reading about executives. The value of DevOps is owning a feature now and it being there today or tomorrow. I mean, that’s really it, right. From a business perspective. This is, we’re not talking about just building software. We’re talking about delivering features that your users are going to wind up using near immediate. Right. And that’s, again, that’s a, that’s the Holy grail for DevOps. So if you’re moving in that direction and you’re focusing on that, some of your, you know, your stories or your PBIs should be, how do we, how do we make improvement to get in that direction and what percentage and all that that’s a different discussion. Right. But it can’t be forgotten. Is the point.

Dan Neumann: [14:15] No, that’s wonderful. What are some of the, what are some of the questions that people might use? And I think we can take some of these in turn them into a little, a little tick sheet. If you will, a little tally sheet and make that an artifact that people would go out to the show notes and download. Kind of what, how do you, how do you know when you’re ready or when you should be leveraging DevOps?

Barry Matheney: [14:37]
Yeah, and when I wrote, all of these, it was again, just a stream of consciousness. Right. But at the same time, it’s how do you, if I, if I read these and I come up with answers that are, you know, more than a few that say, yeah, this is a real problem for me, it’s probably time to say, okay, agile coach go learn DevOps, right. Or call somebody that’s a DevOps specialist and bring them in and say, let’s look at this stuff. Right. So to me, one of the first ones is do your deployments occur during non-business hours or normal business hours? And if the answer is I have to do them during off hours, that’s toil. Right. Cause now what happens is, and I’ve been there. I’ve done that, right? Oh, we’re going to start at 11:00 PM tonight.

Dan Neumann: [15:23] But yeah. Oh God, I’m having flashbacks. Yeah. Oh my God. Kevin forgot to run the database script and Kevin ducked off a phone call and he’s not a video. So nobody knows. And that’s Kevin knows who he is because I didn’t change. I didn’t change his name to protect him. He’s guilty.

Barry Matheney: [15:39] And if you’ve ever heard snoring on those calls, you know? Yeah.

Dan Neumann: [15:42]
Yeah. And why wouldn’t you when they start at 11:00 PM and go to 1:00 AM I mean, we’re humans.

Barry Matheney: [15:48] Oh not AM. 11:00 PM to 1:00 PM. I have seen it start on Friday night and Monday morning. And then you’re expected to still come in and do your day job. Right. So that’s, that’s the first one. Right? So,

Dan Neumann: [16:07] Okay. So support humans and actually being humans and being a working when the daylight’s on.

Barry Matheney: [16:15] So again, deployments and releases are two different things. So we can talk about that separately, but deployments are, should be a non event. They should be normal working events. They shouldn’t be interruptions in the rest of your life.

Dan Neumann: [16:33] And let’s so deployment moving code configuration from point A to point B, is that what you’re referring to by a deployment? We’re moving the stuff. And then I’m assuming that release is flipping the lights on to enable the feature to enable the feature. Okay.

Barry Matheney: [16:48] So they are two different distinct things for some organizations. However, for most organizations, they are synonymous and therein lies part of your problem, right? Because your teams haven’t built in feature flags or whatever technique that you’re going to use to enable features, to do whatever types of testing that one might want, like AB blue, green, all those types of things. Right? So, uh, but once again, so there’s business value in AB testing, obviously, right? But most teams don’t inherently go say, Hey, let’s build that feature in so that we can turn it on and turn it off and get real statistics about what the conversion rates or whatever it is that you’re driving.

Dan Neumann: [17:27] And that would mean you even have to have an interest in measuring or notion that one should be measuring conversion rates or behavior differences and things like that.

Barry Matheney: [17:34] How many organizations do we continue to work with that still do business cases. I know.

Dan Neumann: [17:41] I need a moment, a moment of silence.

Barry Matheney: [17:43] How many times are they measurable? Whether they drive the return they’re intended to or not. So that’s kind of one of those, anti-patterns where the business case was developed. The Product Owner said, go build stuff, but they’re not going to build in metrics to go capture them. And it’s not because they can’t it’s because they choose not to.

Dan Neumann: [18:01]
Well, and the system, doesn’t the system of their operating in doesn’t enable that, it doesn’t, doesn’t ask for it. It’s not curious about it. It’s just, it’s good at measuring hours and dollars and that’s about it.

Barry Matheney: [18:16] I would just say that most executives have let the reconciliation between the investment and the actual return go unreconciled. Right. In many cases it’s because maybe in the past we didn’t have the capabilities to do that, but we do have those capabilities now.

Dan Neumann: [18:32] Ooh, we might, uh, that might be a separate, let’s put a pin in that. Okay. We’re talking. So we got through one on the list, our velocity, this will be a four hour podcast. Alright. No, it’s all good. And that’s why we’re going to make the list available. Cause you’ve got a lot of really interesting questions, a lot of thought provoking questions on the list.

Barry Matheney: [18:56] So the next one I would just say is, does your organization security themes seem to always be diving into your, uh, into your business? Right. And that probably means that there are risks identified security gaps, and there are practices again, to, to help manage that, right? And provide evidence to your security team. Here’s our risk. Here’s how we’ve mitigated them and hand them to your compliance team at the same time. And by the way, compliance is typically ecstatic with DevOps processes because they, you can make an agreement up front about what the deliverables are going to be in terms of evidence. You produce that evidence as a function of your daily work, and nobody has to go take time to generate and create manual reports and those types of things at audit time.

Dan Neumann: [19:44] Is there an example of some evidence that you could share? Because conceptually, I think I understand that, you know, being a, being a lowly agile coach and not a DevOps coach, but I think some concrete examples would help people go, Oh, I see, I see what he’s talking about.

Barry Matheney: [20:01] So, so for example, having tools and processes in place to monitor and record changes to machines, to monitor and record configuration changes, anything that happens should be logged. Right? And then I don’t care about every detail of the log, but I do care about the ones that look exceptional, right? So you can build reports around those. That’s the easiest one. I can think of a, your build pipeline in terms of security reports who has access to change, make changes to your build pipeline, who has access to modify source code. Once it’s in your build pipeline, those types of things, monitor and modify and capture those events as they occur.

Dan Neumann: [20:44] No, that’s, that’s super helpful. And it we’ll time box this and make sure I don’t take us down a rabbit hole. A lot of times when I think of DevOps, I think of how I first heard it, did the team building the software, building the product building features is also then responsible for the operation of that thing, dev and ops being close together. And that team has a full responsibility. And then I hear other organizations, like you said, Oh, we can’t have developers touching production week. Or, you know, we can’t have developers doing this. We can’t have them doing that. And so they put that wall in and then they’d make a DevOps team, which I’m like, well, that, I mean, yeah, they’re doing DevOps technologies, but it’s an ops team really. Who’s maybe doing some automation. Um, and I see your head, nodding. Can you help me with the compliance of that, because I think a lot of organizations go, we can’t have the developers doing this stuff. And you’re saying, you can, you just need to have the evidence, the logging, the traceability, the controls, et cetera.

Barry Matheney: [21:46]
I’m gonna start on my rant first. So DevOps is not a job title. It’s not a role and it’s not a department. Okay. If you look at, and I know that, and we don’t have the visual, but Steven’s roadmap, right? It shows the journey from transformation through agile, up through DevOps. High performing DevOps. DevOps is a slice all along that route. Right? And the case being, you have to design and think about how are, how are we going to support an application when it gets to production and what are the controls that we put in place to make sure that if a developer needs to get in, he can get in, right? Ideally developers don’t need to get in. That’s the first thing, make it. So your developers never need access to production. They have sufficient monitoring, logging. They have sufficient, uh, auditing. They have sufficient everything that prod access has never a necessity, right? Even in an outage their warnings and errors are so good that they’re self healing. Right? You can do those types of things. And that way having separation of duties is no longer a concern, right? Because it is simply more than, um, it simply, I don’t want anybody in my production systems. Right. Computers should do the toil work. Individuals should do the thought work. It’s that simple. So how do you, how do you, we talk about automation. It’s not about automation. It’s about letting computers do what computers do best.

Dan Neumann: [23:21] It makes me wonder why so many organizations think it’s okay to need to go and manually tinker in production. Right? You wouldn’t do that with your car. Your car is going down the road, you don’t, most people don’t expect to have to get out and fiddle with the car. Right. I mean, there were the MGs and some of those like classic old cars that were always need, You got a charger, right. Yeah. Right. But now, I mean, as cars have matured, you shouldn’t be fiddling. And I think that’s the same with software and really being professional and operating at a tier of excellence, or what did you say resiliency. Right? These shouldn’t have to go tinker.

Barry Matheney: [24:05]
Unassailable.

Dan Neumann: [24:05] I love that word.

Barry Matheney: [24:08] You too. And it’s just, it just resonates so much with, so, and again, I love quotes and sayings, right? And this one was, uh, it’s attributable to a bunch of different practices, but it’s simply amateurs do it. So they get it right. Professionals do it until they can’t get it wrong. Right. And our software teams are, they want to get it done and get it out the door. And that’s what we did. Right. But that’s not a professional level to me. The professional level is now that I know that whatever you do with it, I know what’s going to happen in every scenario. Right. And that’s, that’s a reach that is a very strong reach and that’s not easy to get to, but it takes maturity in your teams to even begin the journey. Right. The transformation is not about your Scrum team. The transformation is an organizational transformation. How do we enable your teams to deliver in this manner, opposed to why are your teams always fighting to deliver in this manner?

Dan Neumann: [25:10] Right. And I see, and it’s a journey. And one of the things, especially when I was newer to agile coaching and software development is fairly impatient. And I still struggle with patience. But some of these, it’s a journey. In some cases, going from zero to high functioning, agile is not a, an overnight thing. For sure. It’s not a one month thing. It’s most organizations, not a 6 or 12. It’s a continuous journey of excellency. Someplace along the line, you look and you go, wow, we’re pretty awesome. There’s still more awesome to get, but that’s not a short journey.

Barry Matheney: [25:51] Well, and so I think journey is the key word, because DevOps is centered around continuous improvement and continuous being the operative word. It never ends, right. There is always something you can do better. There’s always some area that we can do to improve. So there’s, there’s never an opportunity to just rest on your laurels and go, okay, there you go. We’re, we’re as good as we’re ever going to get. Right. And so that’s the journey of continuous improvement and how that overlays with your agile approach.

Dan Neumann: [26:22] Right. And I should, I should give some credit because the organization that we were talking to them about agile transformations, because honestly, that’s what a lot of companies want to buy. They want to buy an agile transformation. They want to have some people come in and install the agile and have it be good. And then, you know, put the agile into prod. Well, yeah, it’s our new way. It’s it is. And, and it’s, you know, it’s hard sometimes to get a conversation if you’re like, well, agile is a journey, not a transformation. And, um, but this organization said, no, it’s, it’s a journey for us and help us with that journey. And so I’ve, I’ve really become very fond of that much. Like you were fond of the unassailable term, I’m fond of that journey. Okay. Here’s where you are now. Let’s, let’s operate there and let’s get you farther on your journey. And eventually the path curves. And we can’t see around that corner yet, but let’s see when we get to that corner, we’ll see farther down. So love that term. Yup. Cool. Off my soap box, there were a couple other items that you mentioned. I wanted to kind of pull out a couple of these. Like when do you need an agile coach? I’ve seen agile DevOps coach. And I, I really do think there should be a lot of overlap. So let’s touch on the agile coach DevOps coach, part of the distinction I think I’m hearing. And what I see in our organization is the DevOps coach has, can actually help this reality come into existence by sitting down side by side with an organization’s, developers, operations folks, and show them the path and walk with them to get down the path of DevOps. I can talk about some of these, um, you know, the AB tests and the measuring, but at this point, my skills to do any of that are nonexistent. But what you’re describing is the ability to say, Hey, let us show you we’ll do it with you.

Barry Matheney: [28:11]
I think that’s the key, right? Because there are technical practices associated with much of what we’re talking about. There are technical thought processes that a lot of people haven’t been exposed to. So that’s the, I think that’s the differentiation where an agile coach may have the idea. I think the DevOps coach is the one that can come in and say, let’s try this. And let’s, you know, let’s put a prototype together, a POC or something. We’ll do a spike, whatever, and we’ll show you how this would work so that we can do AB testing, or we can do a blue, green deployments, or, you know, we can dynamically provision test environment so that you can have everybody gets their own clean environment. Every time they do a new build. Right. That type of thing.

Dan Neumann: [28:52]
I think of was it Jeff Foxworthy who the, who had the whole year might be a redneck skill. So you might need a DevOps engineer. And one of them was like, if another team’s work breaks your deploy, you might need a DevOps coach.

Barry Matheney: [29:08] That’s exactly right. And again, we’ll put the whole list out there. I think again, we talked about alerting and alarming and prod. And is it self healing or does somebody have to go do something to remediate those problems? Um, I think the manual processes that we introduce that are organizational legacy, I’ll just call it that. I think that’s the nicest term that I can put up with. Nobody remembers why most of them are there. All, all anybody knows is how we’ve solved the problem 10 years ago. And we haven’t readjusted or re-evaluated if that problem still exists. And whether this process of human intervention still exists. Right? So again, the continuous approach to improving that is to question, what’s the value I’m getting out of this change control board, or what’s the value that I’m getting of these, you know, uh, whatever the practice is, right. I have to go through this formal process before it can happen. And if the teams are self, you know, and, and you mentioned earlier, the original thought was that teams would support their own stuff and prod. Well, we are talking about that. We’re just talking about it in a different way. That doesn’t mean I need access to prod. That just means that I know what’s going on in prod because I’ve built in what I need to know about what’s going on in prod, right? So we still have separation of duties if you want, but I’ve also designed it designed my processes. So if some emergency occurs, right, the first thing we’ll do, let’s go fix the problem in prod via whatever means that we’ve built in. And then the next thing that occurs is that item gets put in our immediate backlog to go remediate. So it never happens again.

Dan Neumann: [30:51] That’s a really important distinction between having access to prod and having the transparency and the information and understanding of what’s what’s happening, uh, within. So wonderful. So keeping an eye on our loose time box for this, for this episode, anything you want to leave with, we’ll put this list out for some really good scenarios that would really say, Hey, you really do need a DevOps coach. Let’s see, what’s your parting words.

Barry Matheney: [31:23] Interesting. The, I think that, so when you look at these questions, right, there’s probably one or two categories and ones that are, and again, I keep bringing this back. DevOps is a organizational challenge, not a team challenge, necessarily the teams can be high performing and delivering working software at every product increment. But again, my, my belief is just like in Lean is something sitting on the shelf. It’s not providing any value, it’s excess inventory, right? So the longer it sits there, the more money I’m losing in the more I’m wasting and waste is bad. So how do I get that into production with the high level of reliability, uh, resiliency quality, and not send people off their rails because we’re going, you know, we’re deploying a hundred times a day into a production environment. So, um, that’s when you’re ready to start having that conversation, and you’re not going to get there by the way, you’re probably not going to get there for a long time. It’s still part of that journey, but you can get improvements and you can move in that direction. And every investment you make in that direction is going to pay dividends long term. I can absolutely guarantee it.

Dan Neumann: [32:36] Yep. And it’s, and it’s a journey. It might be, Hey, let’s deploy this quarter. And then eventually this month, this Sprint this week, day, multiple times a day. So wonderful. Well, if people want to ask questions and follow up on DevOps, I think it’s, it’s a massive topic. I mean, there’s lots more to explore potentially, so they can email us at podcast@agilethought.com or tweet it with #AgileThoughtPodcast. And we’ll see what we can do to queue up the questions and get some answers outstanding. Hey, thanks for joining today, Barry. Really appreciate it.

Barry Matheney: [33:07] Enjoyed it. Great conversation. Thanks.

Outro: [33:11] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes@agilethought.com slash podcast.

Stay Up-To-Date