DevOps Building Blocks Part 5: Flow, Bottlenecks and Continuous Improvement – DevOps Unbound EP 42

Hello everyone. I'm Alan Shimel of Techstrong Group, and you're watching another episode of DevOps Unbound. DevOps Unbound is a, well, it's actually three year plus running a video series where we explore various aspects and topics relevant to DevOps.

And as DevOps has grown, so has the scope of our topics and, uh, aspects of DevOps. com, and our good friends at t Tricentis, the worldwide leader in continuous testing. They've been with us since day one on this journey and, and continue to help us bring the best guests, the best panels, the best topics to you, our audience.

Um, speaking of which, let's talk about today's topics and panels. You know, the last couple months we have been doing, uh, what we call our DevOps building blocks, Terry. And this is actually part five of the DevOps building blocks, and it's around flow, bottlenecks and continuous improvement.

Right? And this is a, I mean, this goes really to the heart of DevOps, but it's also a subject as we were talking off camera that I wanna make sure our audience really understands what we mean when we talk about flow, value stream and stuff like this. Couldn't think of a better, uh, panel to, to have it.

Let me introduce you to our panel. First of all, speaking of flow and value stream, he's Mr. Value Stream to me.

He's helped start the Value Stream consortium. He's worked at several value stream companies. It's our friend joining us from near Seattle.

Jeff es Jeff, welcome to DevOps Unbound. Thank you. Glad to be here.

Jeff, I, I hope I didn't embarrass you, but why don't you fill people in a little bit on your background? Uh, sure. In, in a nutshell, like I started off my career as a developer and, and, uh, you know, was a, a dev manager.

It's kind of funny. I learned all sorts of things about how to do things wrong and made all sorts of mistakes. It made me very passionate.

By the time I became a product guy, um, I got really frustrated with why aren't things moving faster and what are the issues that we face? Um, moving into marketing, I got to watch even bigger companies, um, struggle with the same kinds of things when it came around to look at the flow of value and how companies were dealing with that. Um, again, I became really frustrated how, you know, slowly things were going and why did we just put up with all these bottlenecks?

And so thus, uh, was born this idea of why don't we use metrics to manage our improvement? And, uh, jumped on board with a, uh, very pivotal piece of value stream management, which was a forestry report, um, authored by Chris Condo. Uh, and thus the industry was born.

So we got into it, people were like, oh, yeah, we do that. Like, really? Are you sure you do that?

And, and so with that, um, worked, uh, with a, a few vendors and, and companies to help start the value stream management consortium, um, to help standardize the practice of, of what does this actually mean? You know, moving beyond just metrics, but there's a methodology behind it. Um, and, and, uh, anyways, in my journey now with planview, that's what we have as we have a series of flow advisors and, and, um, we help companies find those bottlenecks and make the improvements they need to make, um, using metrics to, to actually answer the most important question that, you know, agile has always been asking of, of, you know, if, if Agile's intent is to improve, you know, value delivery to customers, the most important question is, well, are we improving?

Well, how do you know? And, and thus, you know, looking at flow from a standardized set of metrics does just that. So anyway, that's my passion around this space.

I love it. Thank you. Thanks, Jeff.

Next up is joining us actually from all the way in Switzerland today, Elle Ruiz. Elle, welcome, welcome back. If you wouldn't mind giving a little, a bit of your story to our sharing with our audience.

Thank you. Thank you for having me here. And it's a pleasure to be back.

And, well, I have also very interesting story, like Jeff. Um, I come from the developer background, but as him, I joined into different roles. And my perspective was since the beginning as a developer, we got the features and we have to deliver something, but the process was not always that nice.

And so sometimes we did a lot of rework. We spent a lot of time, we didn't meet our, uh, our deadlines, we didn't meet our features. So there was something wrong in how the entire software development process was happening.

And, and don't get me started with how we were in almost silos that we were building something that we never saw it wrong. So there was this need of actually solving a problem, not only in our small sandbox, but seeing it as a part of the long story. I mean, because at the end of the day, software development, it's written by human at until this point.

It's still written by humans, and it's going to affect human life. So it's entire human factor. And we sometimes have this inability to see the big picture.

So in different kind of roles that I have had in the past as a DevOps practitioner, as a manager, as a developer, uh, or even as a developer advocate, I had different perspectives on all this idea of software. How do we build software and what is the flow or the stream or what, how should we drive this creation? Love it.

Thank you. Our third panel member is been on with the before, um, is Brian Cole. Brian, welcome.

Hi, Mitch. Hi Alan. So my name is Brian Cole.

I am the director of customer engineering for Neo Load here at tricentis. So I worked for the vendor. I have been a performance engineer at Heart my entire career.

I was a terrible developer for six months, nearly 30 years ago, and, uh, discovered performance engineering and have never looked back. It's been a fantastic journey and more tellingly, the performance conversation really touches on every single part of the enterprise and a very, uh, almost deep level that you don't get with the traditional quality effort. Uh, perf good performance engineers know a little bit about development, DevOps, tool chains, CI pipelines, operations tools, a PM management, programming structures, quality requirements, backlog management.

You have to be very cross disciplined to be able to be really effective at performance engineering. And that's been my background and my journey for the last 25 years. Excellent, thank you and welcome to the show.

Last but not least is my co-host of DevOps Unbound, as well as partner in in in Techstrong here with me. Uh, he's our CTO and, uh, principal research analyst, GM for our tech strong research division. Mitch Ashley.

Mitch, I'd leave anything else for you to say. I am a developer and occasionally when I don't talk to my sponsor, I slip back and write a few lines of code. Um, and I hate to think what code I've written is still running somewhere.

Thank God I don't bank there, but that's a whole nother problem. Great to be here, great to love this panel. Talk about a passionate panel.

This is probably, I would say up there in the top five, a passion around a topic. So I think we'll have a really good discussion. Fantastic.

All right. All right. Let's jump into things.

You know, as I was saying offline, I think one of the challenges is that a lot of people watching this, a lot of people in the general DevOps audience, they think they know what flow is. They have an idea, they have an inkling. Some absolutely do know.

But like so many things about DevOps, it, you know, sometimes you'll put your thumb on something you squish too hard and it escapes. Um, how would you define flow? You want to call it stream value stream, whatever.

Um, Jeff, I saw that smile. I'm coming to you first though, man. How, how do you define this?

Well, you know, whatever you define it as, you're right, because it's sort of like the blind men trying to describe the elephant. You know, it depends on what part, where's where's your focus and what's your view at, you know, if you, if you talk to, um, you know, developers, engineers, you're gonna talk about, you know, code flowing to, you know, your Git repository and, um, the artifacts that flow across to the different locations. If you talk to product people, they're gonna talk about the flow of work and, and how the work's actually continuing.

Uh, and yet if you talk to the business side, you'll look at, uh, well, how is value created and, and thought about? And how does it actually get to the customer? Well, who's right?

Yes, everybody's right. They're, they're all things to be concerned with. And they're all things to, to look at when you evaluate flow.

Um, the danger is to think, well, I've got a way of seeing it. And so it's only that way, therefore, the elephant is only the trunk of the ear or the tail, or, um, uh, you know, you, there's gotta be a, a, a healthy competition of, uh, evaluating all work, um, and all kinds of flow, um, when you're one gonna improve it, two, gonna evaluate how are we doing and so forth. So that's my view.

One of the things that I've seen over the years is people tend to look at the whole process and be daunted by it. Mm. They're like, well, if I, how do I simultaneously improve the efficiency of code moving through SCM and my CI pipelines and my quality effort and my automated deployment effort and the security checks that I need to put in place, and it's just too much.

Uh, and what they're not thinking through is you don't have to do it all at once. To which they immediately replied, well, won't that cause the bottleneck to move somewhere else? And I'm like, yes, absolutely it will.

And that will put pressure on the team where that bottleneck sits. Now, to act on that, either you are starved for information, you're not getting the throughput from upstream, or you get really efficient and you jam up the downstream elements. Either way, that creates an impetus for organizational change, a demonstration of value and efficiency that you can then begin to help propagate throughout the whole enterprise.

It's, you can't boil the ocean. You can't do everything perfectly. You never wanna let perfect be, get in the way of better.

There is a lot that can be done with existing tool chains. I often tell customers, when you are trying to implement a DevOps tool chain, if you don't own a hundred percent of the technology, you need to do it today, it's because you own 95% of it, you're missing maybe one or two pieces. It's not about brand new tools.

It's about using what you have in a different way. And getting flow out of those just requires a shift in mindset. Hmm, fair.

Any other thoughts? Go ahead. Well, I, I want just to add something.

I mean, there, there definition is very complete, but I wanted just to remember that the term was born from another industry where things were more physical. So the entire process was something that you touch, like, uh, and, and, and that is interesting because for me, what we are missing is this dual process of having the big picture, but being able to zoom into the different parts. And as Jeff mentioned, this is a matter of perspective.

So each stakeholder in the entire process have a different perspective, have a different language that they are using to analyze the entire, the entire process. But it is a single process. So what we are aiming here for is to have some unified language so all the stakeholders can communicate in an effective way, and then still are the, their knowledge.

People in their small domains, like when they soon in or out, they are still know this whole big process and they can't communicate with the different stakeholders. But then when they go in, they have their own metrics, they have their own goals, they have their own ways of measuring things. But at the end of the day, everything, every single effort that we are doing should sum up to delivering some value.

This is extremely common in the quality space generally, but in performance engineering in particular. Mm-Hmm. Uh, and I really want to jump on what you said here, Excel, because it's the idea that you need to translate the information so that it's meaningful.

If I look at a bunch of performance engineering reports designed for performance engineers and try to just hand those to the developers, expecting them to understand what they're looking at, that's not gonna work. That is not the language or the context that they need to understand this information. You have to translate the data into the correct context for the different audiences and stakeholders to consume it.

But it has to be the same data. Your transformation can't alter reality. Um, this is one of the biggest hurdles that I see with a lot of technology tools that are out there, that they do not cater to an audience beyond the scope of just the narrow focus that that solution was built for.

Um, and we see this a lot when you start looking at industry tools. So true. It exactly my point.

Uh, well, Jeff, I already talked. No, no, I, I, so true. I kind of, uh, another bent on that too is like, well, why don't people do more with this?

And it, and it feels like the big sticking point is, well, I'm, I'm, I don't want to go boil the ocean. I don't know how this stuff works. I just gotta get my stuff done here.

And once I'm more mature, I'll get to that little bit of evaluating flow and seeing how it's going. I often laugh. People, people always ask me, well, how, what is the most effective thing we can do to embed performance engineering as a practice, as part of our DevOps tool chain?

And I say, add a task to the backlog, because literally you're not asking anybody to do it. So it's not getting done. Try maybe making that something that you're, you have in your list of, to-do items and see what happens.

It's amazing to me how sometimes the simplest steps can lead to transformative results inside. Yeah. To that point, that point, Brian, it, it, it also helpful, and there are methodologies to this, you can just kind of do your own thing, just putting some diagram or visual together about what the process is, what the, what the flow is.

Yep. Because, you know, applying, like you mentioned, quality, uh, techniques that we use in DevOps and other disciplines. And then you can see, start to measure where the performance issues are, where the bottlenecks are in the workflow or whatever it is.

But at least you kind have a picture of, it doesn't have to be perfect. That's 80%, that's 80 more percent than you had before you built the diagram, right. Or some visual understanding.

'cause what happens when you dive into that sort of, the little things pop out and say, oh, I didn't know we did those things. What about that? What you, so you learn a ton about what's happening.

Elle, go ahead, please. No, and I totally, I just want to add onto your idea, because yes, we do need how to have this panoramic idea. So we have an inkling.

We, we have developed this gut feeling of this, we are going in the right direction. But also, as we have said, there is a problem sometimes in the communication in what matters to me in the language that I am using and what matters to you in the language that you're used to. Uh, talked about this.

Like, for example, when marketing comes to a developer and says like, we are not making our KPIs. And developers are like, and like, I, I don't even know how to translate your KPIs to my, like, how, how, how, how I, my, my medium time to the, to whatever it, it, it's a, a equivalent to your license bot or something like that. So there is this miscommunication.

So the first thing, as you have said, we all need this big picture to know how do, are we contributing to the entire flow? And it's not only about our specific part, but it's how we are in the big picture and the small picture. And the other thing that when I, I suggest this, uh, uh, as you have said, like add the task, add the big picture, and also explain why it's so important that you provide the information that is required for this flow to actually continuously move forward.

Where are you generating the exact information that adds value, that it has meaning and is defined? Because that, at the end of the day, it's going to be the main characteristics of whatever we're extracting, exposing, or trying to, uh, communicate back to our workflow. Yeah.

People, people like feeling their work matters. They wanna feel like what they're doing has value, is an intrinsically important part of the process. And providing that understanding that shouldn't be difficult.

I hope. I, I hope that there's a lot of, uh, managers out there who are able to clearly articulate this is why you're doing the work that you're doing and the value that it provides back to the organization. This is why you matter.

And that can be tremendously impactful for getting people motivated to participate in this full transformational effort around lining up all this automation and getting the flow to accelerate. 'cause that's the goal, right? We wanna move stuff from dev to ops.

That's it. That's what we want. How do we do that faster, more efficiently and, uh, with greater buy-in from our teams?

Yep. You, you know, though, listening to this though, in many ways, I, I think this is why the whole flow value stream discussion is such a perfect fit for the DevOps framework, right? Because DevOps is about breaking down silos.

Part of it certainly is, right? That's an important piece of it. And it's not just dev and ops, though.

That's, you know, the purist will tell you that it still is just about that, but it's breaking down silos between security and testing and, you know, all of these different areas that we all play in or we all work in and toilet. And, you know, and that really, I think is the double-edged sword behind flow, right? Flow is seeking also to cross the silos, to break down the silos and cross through and show the flow of value from left to right as, as things get done.

But what happens is, it's like at every border there seems to need, you need a visa or a translation, right? To make sure what was valuable here is recognized as value here to what these folks do, and so on and so on, down, down the stream. And I think sometimes it, it's easy to, for that train to get off its tracks, right?

And, and what you may as a developer put a tremendous amount of value, you know, in terms of the flow of, of, of, of, of value from what you're doing the next stop along the river. There may not necessarily or maybe doesn't understand it. So, and it's fascinating, and I speak to this from the quality perspective that I've lived in.

A lot of QA team members that I've worked with over the years feel like the quality engineering effort is important in and of itself. It is not. The only thing that's really important is getting good software running in production.

That's the goal. Everything else is a means to an end to accomplish that. So getting to that point and understanding the role of quality there, there's so many different things people will talk about, especially in the performance space.

Well, what are our performance requirements? Well, uh, they're gonna be three seconds for whatever this business process is under these load. 01 seconds and say with the door, right?

Nobody's gonna stop it for that hundredth of a second delay. The, these nebulous requirements, this understanding of context needs to be applied to every part of this delivery tool chain. How do you do that though?

That's, you know, some level talk's cheap. How do you make that happen? So there, there's been a fascinating trend over the last probably 10 years, but it's really picked up over the last six or seven, where the idea of a DevOps tool chain has spread beyond the dev organization in a really compelling way.

Um, they created it. They, they had their understanding why they do it. There's the cynical jokey part of me that says, you know, all the business people figured out what agile is and started going to the agile conferences.

So they created DevOps so they could have a place to go without, uh, all the pmms and everybody showing up. Um, but what it did to the quality organization in particular is really put pressure on them, uh, to change. There is this whole conversation about shift left, and I keep bumping into people who seem to think that means make the developers do it, which is not what shift left means.

That's not at all correct. They have a job already. It is about you, that quality engineer or you, the release, uh, tool chain engineer, whoever your job role is, learning more about CI systems, learning about workflow code, learning how to incorporate the value that you currently do in the context of this tool chain.

And being able to take the output of your information into standardized formats that could be consumed by others J unit result files, for example. These are the types of things that a lot of developers are gonna be able to consume very easily in their existing tooling. And that's really the message that we want to drive for a lot of this.

You've got your technology stack. There shouldn't need to be a rip and replace of anything you're currently using. Most everything you've got is gonna be able to output a CSV file or something.

You can then transform that into meaningful reporting. You can transform that into meaningful analytics. There's a ton of things you can do with your existing stack.

You don't need to go and buy a whole new platform to accomplish this. Jump in, I think, did you have a comment about that? Are you, look like she was, I, I, I do have some comments, but, okay.

So my comments, I agree with Brian. There are a lot of things that you can actually do, uh, not to adopt a new shiny tool. And my, my only suggestion there is that we are as, as good as our tools, like how we manage our tools.

And I agree with Ryan, we should be moving into a standardization. So we have this common language that many of the tools can plug in and to generate this information, this data, at this point, it's only data. So we, I can actually mine them into information and hopefully, and improvements in our work process.

But I also see, uh, and I also agree with Brian, it's shift left is not like giving more responsibilities to the developers because we have been acquiring. And, and that was, um, one of the burden of, as a developer, suddenly when I go to conferences, it's like, before I, you only need to to know my programming language, my compiler, my IDE, and now I have to learn so many tools like Excel, honestly. Do you think I have so much time in my hands not only to deliver quality software, but also learning all these tools that are not under my competence anymore.

And I cannot be an expert in everything, and I totally agree with them. So what we are advocating, or I'm advocating is, you know, we have to have a small amount or big amount depending on how you see it, of knowledge in so many d different disciplines. Not to be an expert, but as I like to say, is to know enough to have either an intelligent conversation with your peers in other disciplines, or at least to be very, very dangerous.

Uh, so true. I was gonna say yes, and to all of that, I, I, I think a good measuring stick, you know, to find out if you're on the right path is when this conversation gets to either a business level or at a minimum into the hands of your product management team. Because when product management has visibility into this work, and they start to say, oh, no, let's not focus on this feature because I need my team test and dev to be focusing on building risk or improving infrastructure.

Uh, and, and particularly I can now justify fixing my technical debt and, and improving the, the flow. And I'm investing into that because I know this is an area that's gonna be a platform that I'm gonna continue in the future. That's really starting the foundation for this closed loop planning where I can see what's going in in terms of the artifacts, investments, I can look at the improvement that's happening in terms of the flow of value, uh, again, using, uh, in, in my language flow, time flow, load flow, throughput, look at how much is going through that whole system, system and then decide like, was it worth the investment?

I traded off this feature so I can improve the foundation that I'm working on. What's the business value of that? Well, now I know, because now when I put another feature on, I'm not putting one feature on, maybe I'm putting four because I can do so much more.

That's, that's your measuring stick when the whole team is looking at this from the same light. And you can normalize that thinking. Now, uh, there's a a, a key secret to this is that you have to have your whole tool chain connected.

You have to have a common language that you're using. You know, if, if the foundations of manufacturing produce lean principles, well then use those metrics, you know, uh, throughput, cycle time, lead time, you can apply that to anything. Um, and then follow those metrics through so that the whole team is aligned on what's intended.

This isn't a, once you're mature and once you're done, start with where you are today and make this just be part of your practice. That's the point. Common sense advice there.

So, you know what, Jeff, you mentioned something that's something I wanted to make sure we hit today, and that's this whole concept of bottlenecks, right? Because what's, what's the purpose here? The purpose is to go more, faster, better, right?

And bottlenecks are sort of the scourge of that philosophy. But, you know, one thing we've learned from the lean manufacturing and of course from the goal and the books like that is that, you know, removing bo a bottleneck just sets us up to work on the next bottleneck. Mm-Hmm.

Um, you know, we, we never achieve a state of nirvana where there's no bottleneck. It was, it's the classic case of, well, great, when is the system gonna be perfect? Right.

Entropy, Uh, entropy. Yeah. Well, chupy in every discipline, right?

Uh, when you do audio tuning and you see a big noise spike, if you remediate that, it then covers the two smaller spikes that were being masked by the bigger one. And then you start dealing with those and so on and so on. And you'll never get to true perfection because there's this practical, real world that needs to exist alongside of it.

You can't just spend all of your cycles optimizing your delivery tool chain without actually delivering anything. The, the business kind of requires the software to function in a lot of ways. There's that saying, right?

There's no such thing as a non-software company anymore. Every company is pretty much a software company, uh, that maybe makes things or does healthcare or flies airplanes, whatever they are that their software companies, first and foremost, that is the trend line that we've certainly seen. And it's getting comprehensively better and more engaged as all these digital systems continuously improve.

Um, the interconnectedness of everything is just going up, and it, I'm really excited for what the future's gonna bring. And, and even our, like our code bases are bigger. Uh, our markets are bigger, are more fragmented.

So our necessities, even if we had the perfect machine working like the perfect first conservation machine, the environment is not, is not static. So we will have more demands, and that means that our system has to continue to improve all the time. Even like, it's not only non feasible that we achieve perfection, but also our environment.

It's moving towards forcing us to continuously tune it down and find new ways of actually improving it, maybe totally outside the box or maybe just making sure that everything is oiled. E Exactly. And, and tying back into what Jeff said earlier about successfully measuring this there, it's great to go through and do an exercise to improve things.

It's much better when you have the data to justify that the effort was actually worth it. And I've seen this countless times. Go ahead, Excel.

No, and, and I, that's, that's for me the key, like the, the moment of obstru, because sometimes we are convinced about so many things by only words, and there's a limit of how many things you can do by fate until you lose the fate. I mean, I'm In the performance engineering space, right? Uh, human perception is the bane of my existence of, well, it feels slow.

Okay, well, that's vague, but unhelpful. Can you be a more specific, um, yeah, I, I'm with you. Uh, data and evidence are keys to being successful in this enterprise.

Yeah. If we only have opinions, so let's go with mine. If not, show me the data.

Mm-Hmm. And, And especially right now in current economic times, I mean, I, I don't think any of us have ever seen the technology industry be like it is right now. Um, it's a, a multi-pronged problem where the executive view of, of the engineering teams is like, well, I think they could produce so much more across the board.

I feel like even one of the surveys I read says, I, we think they could produce twice as much as they're doing. Um, developer productivity is a really hot topic. And I think right now, if, if you're anywhere associated to a development team to not focus on proving and demonstrating that you're focused on improving the value delivery, you're, you're missing the point.

And if you don't do it, somebody else will. So just start, we're Now that that is the mantra, right? It it's 25% more with 25% less correct.

Productivity. Right. And look, you start talking about that.

The next thing is ai, right? Because that's going to be the game changer here. Yeah.

Right? That's gonna allow us to do more with less. H how does, uh, you know, it's, it's, look, we made it almost 30, 35 minutes into this thing without discussing it.

Um, how does, how does ai, how does AI play in here? Does that help us do 25% more with 25% less? I mean, yes.

Yes. Absolutely. I would say it's a good analogy would be all of the assembler programmers back in the day looking at the rise of, uh, programming environments like c going, and this thing is just simplifying so much.

It's gonna take away our jobs. What are we gonna do? Uh, all right.

Everybody needs to calm down. There's gonna be a whole new set of jobs. Just like when I was growing up, if I, somebody had said they wanted to grow up and be a YouTuber, nobody would've known what the heck they were talking about.

The same thing is gonna happen in the future. There will be entirely new jobs like AI Wrangler or something like that, that's going to exist to shepherd these smart systems and help collaborate with them to build the kind of solutions that we're looking for. It's gonna be entirely new careers that nobody knows about today.

Um, and I'm fascinated by it. It's going to be incredibly exciting. It, I already see a ton of transformations across the entire DevOps tool chain.

Everything that's happening with all of the smart systems, it's when those systems start talking to each other, that we're really gonna see an explosion in value and an explosion in velocity that's not present today, even though things are moving so much faster than they were even three years ago. Okay. I think there's a another big shift too, that, um, companies are gonna use AI in this hoard of data that has been put into the treasure chest to evaluate the flow of value.

You know what, Hey, look at Planview. I'm also a vendor, right? We, we produce a dashboard that looks at your flow of value.

We interconnect your tool chain. One of the features we're adding is, um, a generative ai and in fact, just, uh, released it recently, a, a generative AI component to it where you can ask a very complicated dashboard that shows you, you know, lean metrics and flow metrics that take a, a fair amount of know-how, like what does this mean? And you can ask it really simple questions that have deep meanings.

Things like, you know, what should I be worried about? What a fundamental question to ask. Yeah.

What should I be worried about? You know? And apply that to wherever you're at.

What we can now do with this prompt is to tell you, well, look, looking at your flow load, this team's overloaded. We know by benchmarks and your previous history because we have the data, what's working and what's not. Hey, look, there's another team that's gonna be behind because there's a dependency.

They're not gonna get done in time. You should focus on that. The second thing I think, um, AI plays is it democratizes the expertise.

Anybody can ask that question. They don't have to understand all these metrics. They don't have to understand the flow of value.

They don't have to understand performance engineering. They don't have to understand, um, how quality fits in. You know, it democratizes this expertise.

So now you can ask these questions and it'll tell you, it'll teach you to everybody across the whole company. Everybody knows how this works. And does you democratize it or dumb it down?

Well, Sure. In the eye of the beholder Yeah. Yeah.

Is in the eye of the beholder. But I'm with, I'm with Jeff on this point. If you ask the question without really understanding what the underpinnings are and get a response, your follow up question would be, can you explain that to me?

And I'm willing to bet that the software's gonna do a really good job doing an explanation of exactly what this means. And it's like falling down that Wikipedia hole. I don't know if anybody else has done that.

You click on one thing and read it, and there's a link. So you click that and then five hours later you're like, how did I end up in Poland or wherever I'm at? So those types of things are gonna be built into the software that we use every day, where it's going to, based on how we react to the explanation, understand how much we understood of what it was telling us, and provided the context that we're missing.

It's gonna be incredibly helpful in a creepy and alarming way that we're not prepared for. I don't think, I don't think a lot of people are ready for just how smart these systems are gonna get. And I think that that's actually my, my take right now.

And it's slightly different from yours. I mean, for me it's a tool and the tool of today has some issues, some wrinkles that we have to still verify and the tool of the future. I think I, I, I'm very optimistic about the capabilities once we are on those wrinkles, that the tool of the present has, the tool of the present is still worrying me in some way.

Because again, what Jeff mentioned, it's opening more, uh, it's, it's actually opening the doors for people that have expertise and maybe not so much expertise and have context and not so much context. And they are able to interact with this tool. Now, the answers that this tool provide, most of the times we see, we, we, we think, like even the people with a lot of context and a lot of expertise, they are like, yes, this actually does make sense.

And once in a while we are fooled by it. So we actually need to be cautious. That's my only point.

Like the tool of the present, you still have like, yes, play, yes, push, see where it can take you, but don't take it as face value. That will be my advice. And I still believe that we need a little bit more experience and context even to evaluate the answers before going with the Yes, the tool told me.

That's a good reason. Yeah. That was one of the use cases and factors we were going through all this is like, you know, hey, what should I worry about?

Well, this project's delayed. You should move it out. Oh, great, do it.

But wait a minute, what about all the approval processes and everything else that's gotta, so, you know, broad implications about what this means and who can see what, and then you end up with people that are worried, well, who all's gonna see that my team moving slow? And I, I think we're opening the door of gaining visibility into a lot of things that I don't, I don't think we all know the implications of, but Don't get me wrong. That's What we need this, need This tool for, sorry, sorry.

No, this tool for this specific use case, it's magnificent because it detect patterns. It is aware of patterns that we never have even crossed in our minds. So the amount of insight that we, we can get at different levels, it's surprising.

So in this particular use case, I'm super excited, And this is, this is, But I'm still caution Yeah. This, this is the great strength that I think AI is gonna provide initially, is that pattern recognition, uh, right upfront. That's really what humans are.

We are great pattern recognition, uh, engines. I'm in the performance space. Whether I am correlating a test script, trying to figure out how to get it to work, or whether I'm doing results analysis, looking at server data combined with the response time data, I am looking for patterns in that data.

Mm-Hmm. And having this wealth of information that we've been saving up over the years and being able to apply a machine-based pattern, recognition engine that's capable of doing some very insightful things. Mm-Hmm.

The next, the next steps are gonna be great. And one that will sit there and tell you, so you've been doing the same thing and expecting different results. I'm here to tell you, Uh, humans are notoriously good at getting feedback that what we've been doing is wrong and we should change our ways.

So yeah, that, I don't see any friction with that in the future, but Right. There's, there's going to be a bit of it. It's gonna be a bumpy road, but it leads to a good destination and it's worth the journey For me.

For me, what we now, we will have to go back again, is to identify what are the events? Where is the information that is actually going to provide us with value and meaning and information? Mm-Hmm.

Because again, this amazing questions, this pattern. Find the, uh, finding abilities, this ability to actually, uh, analyze an end dimension matrix of different data points in, in so with such an ease, it's only going to be worth it if the data that we have and we are producing it is interesting. It is important.

It provides meaning and value because otherwise Yeah. Sorry, EE exactly. And it's the tying it to metrics that matter.

I vividly remember going to a customer, 'cause they wanted to evaluate all their quality metrics. And I looked at all of 'em. I said, well, I can propose one simple change that will make all of your quality metrics solidly green all the time.

Stop running tests. 'cause every single thing you have in here is defect related. If you find no defects, these are all green lights and your dashboard's perfect, and you can ship it into production with confidence.

'cause that's what you just finished telling me matters to you. And that opened their eyes to the fact that maybe they're measuring the wrong things, they're looking at the wrong type of information, that there's something else that's actually important, which is that taking a step back and saying, what I'm doing here isn't important. It's the outcome that matters.

It's not about how many tests I run. It's one, the software is high quality. So these are the types of conversational changes that I'm anticipating these smart systems starting to come to us with, with insights saying this, there's a better way.

Look what you could be getting if you made these types of changes. Love it guys. I'd love to sit and chat with you a little bit more on this, but we're over time already, so we're gonna have to end it here.

Um, you know what, this was a great discussion, a great discussion. We started off here and we, it just kind of flowed, no pun intended, flowed all the way down and through, right, right into ai. I was intentionally, well, I try.

Um, anyway, Elle, Ryan, Jeff, thank you so much for joining us on DevOps Unbound. Mitch, I I'm gonna hand it over to you for the last word, but before I do many thanks again to t Tricentis for co-producing and sponsoring DevOps Unbound with us. Check it.

You know, there is a DevOps Unbound podcast that you can get on Apple or Spotify or wherever you listen to your podcast. So you can, it, you can listen and or watch it there, as well as Techron TV and everywhere else along our network. Mitch, I'm gonna give it to you to end, finish up.

You bet. com. There, you'll find it right there available to you.

You know, I, I think one of the many things that, that I learned, and it's part of this discussion, one of 'em is, so don't go, don't get wrapped up in the thing that you're doing, the technique or the process or whatever. Those are all good and there's a part of the tools, but think about the outcome of what you're trying to achieve, right? Why are you measuring flow?

What's important about it? Is it performance issues? Is it getting software out faster to market?

Is it something else? Maybe it's nothing related to s backlog or security, or whatever it might be. And kind keep that in the mind for the thing of setting the goals of what you're measuring and improving.

And you may move on to the next thing. Um, but it's a kind of a very heads up exercise or heads up effort, and it's a good chance to really get a, uh, kind, holistic, or at least a better understanding of what's happening and what, where you can make improvements to deliver whatever you're doing faster, better, cheaper, better profitable, whatever. Absolutely.

Fantastic. All right, four, on behalf of Tricent Distech Strong, this is Alan Scheel. You've just watched another episode to DevOps Unbound.

Bye-Bye.