Driving DevOps Team Value | DevOps Experience 2023

Good afternoon. I'm happy to be joining you all here today at the DevOps experience, joining virtually recording previously in advance, but hopefully there to answer your questions as items continue. Uh, and what I'll be presented today is accessing and accelerating discoveries of DevOps valuation practices as a qualitative study.

I'm Dr. Mark Peters and a little bit about me. I'm the Director of Engineering operations for Brain Goo.

I work on integrating DevOps in the US Department of Defense Programs and for how we're doing that valuation practice across kind of that whole stream, making sure that we manage everything appropriately and we bring it in. I spent a previous career working in Air Force Intelligence, working in operationalizing, uh, security issues, finding ways to bring teams together and delivering accelerated values. I did write a, a book called Caching in on Cyber Power for my first doctor, head of a, a PhD in information technology for cybersecurity as well.

Uh, for my spare time, I enjoy drawing, reading, speaking and ju as well as my two great Danes and my incredible family. Uh, so with that, we'll jump right into the presentation. So first off, why you listening to this today?

Well, we know in DevOps, so what we see is we see a lot of generic use cases and we see a lot of information about how things are going, but we don't dig into the formal research. Although the third way is improvement in experimentation. We don't always get the time to do that formal experimentation or categorize it.

So in this, I've categorized some of those things I found from the team. I wanted to find out what motivated the DevOps teams to make decisions in security with deliveries, how they were determining value with their deliveries, uh, in terms of security versus functionality as they drove forward. We talk about it all the time at the planning level that we have that value exchange between what we do for security and what we do for other means, especially as we try to shift left, but we don't always have the data behind it to say, how do we accelerate that software development and how do we drive to what we actually want to accomplish?

So the topic for this research was that governance was that qualitative study based on a social exchange. How do we trade things out between different elements of the team? When somebody comes to the team and says, Hey, I have this security thing that we have to do, we have to ingest and incorporate a new cryptographic implementation because we've gone to a new standard and the functional team says, well, wait a minute, that'll break everything.

So how do we relate those things? How do those DevOps practitioners as a culture, as people who really experience DevOps, experience associating and exchanging that value in their software development for those security and functional outcomes? And it turns out that it's not really as easy or or as clear as straightforward as we may have thought it was.

Some of the answers confirm what went on and some don't. So as we go through, we'll talk about how we got to those answers and what the foundation was for the basis. As I've said, when we look at this particular area, we wanna really break it out.

We want to have clear understanding. When we go to a meeting, when we go to a table, we wanna say, look, I know this is the way it works. When we run our Python code, we can show it's clear.

We can do our SaaS and our das and we can show how it works in the implementation, but we don't always get that in our personnel environments. So we have to understand what those value exchange experiences are. Even though there's a lot of writing on DevOps, there's not a lot of what we considered published academic literature.

There's not a lot that has those formal considerations. And when we do those formal considerations, they either tend to be at the low level of implementation from a quantitative set where we take a lot of numbers and statistics and we compare them. Or at the very, very high level of qualitative where we said, Hey, it works.

We made a transformation. Let's go onto the next step. That specific research is out there on those tools that transformation are comparing methodologies saying how DevOps and agile works compared to a waterfall and what we saw in the transformation from one to the other.

But we've yet to really dive into what it means for those teams other than those use cases and studies. So at that extreme level, perhaps you could look at this as another example, the use case or another example of a modern, uh, facilitation. When I researched it, when I went into the areas, I looked a lot at governance.

I looked at how teams create value and I looked at functional software development and looking at it 'cause I was looking qualitatively. So I was looking for those interviews with those different individuals to bring the information. I began with an experience a phenomenology, which is a philosophical approach that begins with ser uh, self interpretation.

It's to the things themselves that everything matters. Uh, from the thing perspective, from the individual perspective, you might al almost consider it a form of object-oriented programming that we deal with each of those objects individually as we drive them forward. We have the external objects, which is how the world forces us to interact.

We have the experience of others, how do we interact with a team? And then the experience of ourself. How do I approach that team and how do I make decisions on my own from those ideas of those things, those objects we can drive into social exchange.

S another philosopher, a business, uh, philosopher in 1951 demonstrated that both material and non-material items can exchange value. That we can trade between security and functionality the same as we can trade a handful of dollars for a meal at the local fast food restaurant. Since we say as a basis or an assumption that functionality and security both have value in software development, how do we exchange those values and how do we consider those values moving forward?

Well, with this, we'd go back to that heiddeger. We go back to that phenomenology experience and we'll talk about holmans and heiddeger a little bit more in the continuing slides. But we talk about in framing that each concept is embedded in something else and that technology orders our humans and is in turn ordered by them.

So we order the structure and what we do something, we say that security has value, then we build that value into our code base. The feminology here shows the essence of the experiment and the developers have interactions based on the world, based on their team, based on their self that drives it forward. This helps us take those qualitative expressions from those summaries and transform that lived expression, that lived experience that we can relate to each other, uh, when we tell stories around a beer and, and drive into a textual expression that we can then evaluate and come to terms with how we deal with security and functionality as we drive forward.

When we look at Holmans, we see him as a founder of behavioral sociology, a founder of the way that people interact, and more importantly, a founder of the way that people interact within those organizations. He had two basic premises when he was considering sociology and ones that expand throughout this research. The basic principle of social science must be true of the individual as members.

So anything that is true of our individual working on a team must be also true of that team and must be true of the larger set of organizations with which they interact. Any generalizations we can make have to be derivable from those principles that we can link those principles to other things and other items, which is where we get to the principle of social exchange that any good we have can be exchanged for any other material or non-material good based on the perceived value. If the item has value to me, then I might exchange it for someone to which that item has less value.

How often do we see this in that? I'll go grab a coffee for you. Uh, I see that you're working hard and the next time when I'm working hard, you'll take the chance to go grab me a coffee.

We've exchanged value even though we don't recognize as such. This drives our cost and our benefits model and our conclusions about functionality and security, how we drive to each step, how we drive to each item forward. We apply this to our value exchange when we say, do I need to put a function in first or do I need to put security in first or security in function?

Really the same in the application we're considering. A lot of times since we drove through the reef research, we found that the developers consider it to be the same, whether it's a function or security, doesn't prioritize it differently, it's just the order in which they can get it done and then how they interact to relate that they're getting it done in that manner so they can make the speed that comes in close concert with DevOps. Iger is the other root of the experience, and I really like Heiddeger.

Uh, he gets very dense at times, uh, but he's a crusty old German philosopher, so you can't get much further than being a crusty old German philosopher. Uh, in, in terms of being dense and complicated in the reading, uh, he wrote Zain, which is being in time, uh, in the early 1950s, and he talks about it being, is predicted in manifold meetings. What is the fundamental meaning when he says being here?

He's talking about the experience, the experience of the individual, and he says with that, it's important to our DevOps temporality that humans are oriented to potential and possibility. We have the potential of delivering code that succeeds and we have the possibility of delivering code that succeeds. When we talk about function security, we talk about both the potential of doing something new and the secureness the potential of being secure.

How do we match those possibilities to each other when we move forward? This goes back to the things themselves. How do they consider the things it moves from a transcendental, from kind of a, a touchy feely type work to a hermenitic view, which is what we're using here, a very object oriented.

When we have a hammer, we know what a hammer does, but what makes it a hammer? That's a hammer because it can drive in a nail. But then is anything that we use to drive in the nail of the hammer, well, we know that not to be true.

So we look at those parts and holes that are associated with it. We take a first glance into those items, we drive to a deeper understanding of what the hammer is, and then our global inspection of how we include that hammer or a toolkit. Now this isn't the same for security security, we might be talking about open policy agent or verno or an or twistlock or one of those other things, but we still break that out in terms of the parts and holes that it proceeds in our security reference and the functionality that we get from the customer.

So we see that we order the technology to use for us, and then we are ordered by it as we drive it into our implementation. Where do we have in the pipeline that we do inco and twistlock and where do we have the incorporation? When we frame that, we have the process of revealing what happens through technology.

We have an in framed, uh, representation of our pipeline. We have an in framed representation of our code, and each of those is in framed in the assumptions and decisions that have been made because of the experience that those DevOps teams have. Now, we say that DevOps is a cultural transformation because we accept certain cultural premises as we drive forward.

This includes the organizational standards that we have, the past experiences and the experiences that drive our interaction or value determination as we talk back and forth in our various planning events on our team about how we get to the precise value of such a thing. So how, with all this in consideration, how did I find a sample? How did I get the right, uh, individuals to talk to to find this?

Well, I looked for 13 individuals. Well, I looked for 10 individuals and I wound up getting 13, which was better for me. Uh, I only used one company, so I minimized the bias from the organizational standing because each of those has the same experiences within the company, although their background was different, uh, I had 13 individuals in the first round, 12 in a second, and 12 in the third.

Each of those interactions, each of those interviews lasted approximately by, uh, about an hour. I selected these individuals through their interest in the project in the corporate slack. I made sure that all of those individuals that I had had worked in the DevOps area and had a minimum of three years of experience being a direct DevOps developer.

2 years, and their average time with a single organization was five years. So they had a wealth of knowledge about how different DevOps processes could work, which helped a lot in the qualitative. As we started telling stories about how things drove forward with those 13 individuals, we did a three interview cycle.

We recorded and transcribed the interviews. We uploaded them to a tool called NVivo, which is a qualitative analysis tool. This allowed me to go back through each of the interviews and transcripts, edit those transcripts, make them anonymous, and go through and code the various elements that I had in it for what I was looking for in terms of functional and security value.

This made sure that I could use the journaling process to remove my own bias towards the individual questions for each question I had answered on my own and made sure that I didn't have a bias towards what they were reporting or what they were seeing to make the information as useful as possible. When we started off with interview cycle one, I had that developed going into the experiment inter interview cycle one largely focused on the in external experiences of the team. It focused on how the world influenced those team, what the world, those project managers in the outside business and those outside use cases were telling the individual to do in terms of evaluating functionality and security.

As we drove forward, once I got answers from the first cycle of question, I built questions for cycle two, and then questions from cycle two resulted in questions for cycle three. Each cycle drove further into their analysis of what was happening further into their experience of that thing with cycle two, examining presence, what the teams were telling them to do and how they dealt with that experience and that pressure from the team. And cycle three, looking at readiness, what was their individual approach, and then how did that individual approach relate to the team and to the external.

Each of the questions focused on functionality, value, security, and their DevOps cultural integration. Uh, to bracket it out, each was designed as an open-ended question to allow the subject opportunity, uh, to include items I may have missed along the way. So after we went through the pre-formatted question, the end question said, is there anything else you'd like to tell me?

Is there anything I may have missed along this, this schedule of this set of experiences that would be helpful in understanding how you value functionality and securius security? In analyzing the data, I did extensive data analysis. We took the interview notes where I talked to the individual.

I took notes as I was taking the interview and then read back through my notes as well as the transcript anonymized the anything so that the individuals couldn't be reported as out for who they were and red ENC coded them as world presence and readiness for each of those security functionality and values sets on the side, you see one of the diagrams I use, and I'll show it to you later on, a a colleague tells me that it's the, uh, the time warp view as we start adding multiple colors, multiple analysis, but you see essentially in an hour solid circle combined comprises the external world. That inner circle, that's the presence or the team interaction in the very center circle, uh, with the dotted line, which shows their individual interaction. This allowed to display the various themes and interactions across the inner interest areas.

As we came through, we identified three central DevOps issues that presented throughout, uh, passivity in really expressing themselves as a DevOps professional, a culture that grounded them in what they drove forward and the solutions that was the end goal of DevOps, that everything had resolved to a solution. If there wasn't a solution, it wasn't worth considering. We didn't move past the idea that we had a solution or something that would fix the immediate problem.

We saw management conflicts arise through the themes as well, the external conflicts with the management. When management expressed something that they didn't quite want or didn't know what they wanted and the constraints that were put upon the teams of that you have to do something within a specific area. We know that the best application may be to use a go language, but instead they wanted us to use Python for everything or may want just use one code interpreter versus another.

This led to a a further theme of confusion that oftentimes there was confusion between what the program manager meant in talking about functionality and security and what the team meant when they were talking about functionality and security. And finally, uh, technological preference. All the DevOps teams throughout, throughout every level showed a preference for using a technological solution as opposed to using a interaction based solution, one that depended on process rather than just implementing a new technological tool.

So what does it look like? We'll have three slides of these, uh, and I'll show you each one and I'll explain them. Uh, each of these circles, the size of the circle shows how many respondents answered in that area and the color of the circle shows which question it was in response to.

So here in that round one, we can see a large concentration on their DevOps culture that they had a large influence of the DevOps world culture. They knew what they were saying and why to say it. The other interesting thing is that we see security with that large orange circle.

It's largely external that they're being told what to do in security and it's not a matter of what they can deal with individually, but that they're being told that security has to apply and how it has to apply in this sense. When we moved in round two, remember we were checking for the team interactions. So oddly enough, these were spaced out a great deal more over the different circles than most of the teams had their own answers.

They had their own answers in their own sections and they couldn't quite break it out. However, also interesting is that they felt that the DevOps process applied at every aspect of the team level. That these questions they were answering about value and about uh, functionality and security were driven by a large preponderance of answers that reflected to DevOps culture.

And we see that even more as we move to question three of those individual assessments. Their individual answers were again, all over the map from what the world expressed them to do to what their team told them to do, to what they thought they had it to do, except when we drove forward. Again, we see most of the answers that drive this individual at the large number of multi-colored circles appear in that individual sense of functionality.

They knew what they wanted to drive for the function, they knew how they wanted a DevOps tool to be functional, but not so much. When you look at that same individual on security, much less answers, much less, uh, common answers about the drive forward to get those uh, decisions and those results. So how do we answer it after all that, after all that basis and bake breakout and build up?

How do we answer the research question of how do those DevOps practitioners as a culture, as a cultural process experience associated and exchanging value during the software development with security and functional outcomes? Well, we find that the social exchange for value trading function for security doesn't regularly occur as part of the DevOps culture. They don't consider that the value of something is in its security or functional, but only the value of the thing is in the thing itself.

In that object oriented piece that does something. The DevOps culture held a different standard of value than the customer did in most cases. One of the best quotes we had here was the slow trickle of expected capability that leads to half-baked functionality that the customer doesn't realize is half-baked.

If I can deliver them something and trickle that capability out to them that they don't really care that it's not quite getting to the full functionality they want because they don't realize it, they're focused on that slow trickle that goes out from the individual to the team to the world as opposed to whether or not it's actually doing something. So those outside customers aren't necessarily valuing, uh, the end result of the function, but they're valuing what's there. We also see the DevOps see that security as a subset of functionality, not as a separate thing in of itself.

Security and functionality are not competing interests, but they're the same. We can't have security without functionality. So that's good from a DevOps cultural perspective because it says we're doing the right things that we're considering the inclusion of security in all things as long as we actually take time to evaluate that security.

And finally, we found that communications in the software development is hampered by unclear and restricted channels that the channels for the individual to talk to the world are sometimes not clear, nor is from the team to talk to the world. We see. The quote for that is the leader is so far removed from setting priorities that they just doubled down on what they thought was the appropriate process.

So rather than actually seeking further guidance or further feedback, they used the feedback they had, even if they knew it was uh, insufficient to move to the next step, and then they thought they were processing a DevOps because they had some feedback, even if it wasn't necessarily the right feedback, it doesn't proceed all the way to that level of improvement experimentation because we're cycling kind of in those first two ways rather than extending out to that third way where we can make things improve over time. So as the conclusion, the DevOps culture does not consider the exchange of security and functionality for project value. So this is important because it says when we trade something, when we say something comes in and we have security objectives and functional objectives, even if we've expressed those clearly at a high level, we're not expressing those clearly enough at the lower level to get the DevOps teams to all the way, incorporate them.

They do one and then the other and then don't consider them any different if all the functional things are easier, they'll do all the functional things first and then the security aspects, even if they've already started delivering that half-baked functionality, because it doesn't include the security as a source or code that can be used for outside learning. We see that correlation that they have of security and function versus individual concerns individually. It's how many tickets can I answer?

How many stories can I complete that drive us to the next level where I can deliver some expression of functional software without moving forward? Even when we see that there are teams that recognize those value differences, they say this is clearly a security item and this is clearly a functional item. They don't challenge either the order or the value that's presented from the external from the world.

The drive is to do what the customer wants and do what the customer wants first. Uh, if we give the customer what they want in terms of what we can deliver and what we can deliver in terms of that functionality, then it doesn't matter how those are interchanged or interlocked into our own team. Thus, the timeliness of an any delivery becomes the DevOps value where we say we have a value on the outside, we may use a a Fibonacci sequence to assign a value.

We may assign it a value in a value stream. The only thing that DevOps team caress about at the end of the day based on this research is how fast we can get that next function delivered, how fast we can get that next function out to the person who needs it, as opposed to stopping to consider whether it actually has the value that we've proposed or the value that's implemented. This leads to some recommendations for your team, of course, that we want to align those clear values between management and development teams.

So we say the how for this is we want precise goals without precise methods. Too often in these discussions with teams, they're experience related that a manager would come to them and say, I have to have this and it has to be in Java, uh, without experiencing a reason. Instead of just saying, I need a function that does something and how do we make it work in this framework, they're deriving or, um, incorporating those clear roles.

So those clear steps that have to be taken, which takes out of our a lot of our DevOps feedback and a lot of our DevOps experimentation. We also have to be able to continue a security emphasis. We can get around the fact that functionality and value or security are not different values by saying that security is a key part of that functionality, making that one of our key attributes, one of our acceptance criteria, one of our deliveries forward as we go to the next step.

And then of course, as always in DevOps, we wanna stress continual communication. We want to have clear and upfront communication about what's going on, and we need to have the teams that are empowered and the individuals that are empowered to come forward and say, this is a problem or this needs to be fixed. Too often the communication from the interviews was I didn't go to them and tell them it was a problem because I knew I could deliver it in a timely manner.

So there we see the disconnect between the timely delivery and the functional delivery that I delivered something functional in a timely manner, but it wasn't quite the functional that I wanted. Or if I had gone, had a chance to go back and talk to the customer, I might've changed it in a better way, a way that better suit their purpose and then maybe I could deliver it even quicker because I wasn't walking around and going extra steps to get to that key result. Uh, overall, this was just one element of research.

Obviously for future research and looking at different angles, you might wanna consider using a different group within a distinct company, uh, using a DevOps cultural group across multiple companies where we have something like a, uh, DevOps Institute ambassador group, where we have a group of highly experienced individuals who might answer differently. Now, I did, when I went through it, used two of the cultural group members, uh, for my first answers and found that those were still largely in line with the answers I derived from doing the research. And overall for future res research, maybe want to men measure the functionality to deliver expectations, more of a value stream type approach of how well did what was delivered, match the expectations of the customer and getting that rather than simply getting a functional delivery.

Uh, so each of these steps, each of these additional types of research would probably provide further data. Uh, but for the time being, uh, this is what we have, I was very happy to do it, uh, en enjoyed it very much. Hopefully you got something out of it and can help make your own DevOps process, uh, better and more efficient in driving forward.

Uh, if you do have other questions or concerns, please feel re free to reach out to me either in the chat after the speech or on LinkedIn. Thank you very much for your time and I hope you enjoyed, uh, the presentation and got something you can use from it. Thank you very much and have a great day.