Building High-Performing DevOps Teams – DevOps Unbound Roundtable

com webinar brought to you by Textron and tricentice. My name is Cody J Brown. I'm the host of Textron learning even exciting panel ahead.

But first, I've just a couple of housekeeping notes. First off. Today's session is being recorded So if you miss any of our discussion or you'd like to just rewatch or share with a friend the recording will be made available shortly after we conclude our live webinar.

You should also receive an email with a link to access that recording. If you have any questions, we want you to direct those to the Q&A tab on the right side of your screen. And that's also where you're going to find the chat tab where we want you to engage with your fellow audience members and help influence our discussion today.

Finally at conclusion of our webinar. We will be giving away for $25 Amazon gift cards. So be sure to stick around.

So on to our round table today, we'll be discussing building a high-performing devops team and I'm joined today by an expert panel who will give you their each their own introductions, but to kick off our discussion. I will let Alan Schimmel founder and CEO of tech strong group take it away. Thank you all for being here.

And thank you Alan. Thank you Cody. Thanks for warming up.

Good good day everyone whether it's morning afternoon evening. Thanks for joining us. This is a special edition.

Of our devops Unbound series for those of you who may be familiar devops. Come down is a bi-weekly video series where my co-host Mitchell Ashley and I assembled You know fantastic All-Star panels of of experts to discuss various topics around devops. Related to devops.

We've been doing it now. Oh well over a year. We are joined in this endeavor by our friends at tricentes who have gratefully sponsored devops on and have so since the beginning and many many thanks to Trade Centers responsoring.

Once a month or thereabouts, we do a special edition of devops on down where we expand our panel to include you our audience at home. This is and we call it a live Round Table versus a regular devops on bound session these live round tables when they work right are fantastic. And the reason they are again is because of you.

These rap what we have found are these round tables are only as good as our audience. Makes them because we count on you to help drive the conversation we count on you to steer our discussion. Don't be afraid to ask our panel the hard questions that you're thinking about.

Don't be afraid to comment. right on what your thoughts on a given on topics that were discussing are you could do it in a couple of different places here in Our big Mark a webinar system for most of you. There's a right hand on the right side of your browser is a Communications panel and in that Communications panel, you'll find there's three or four different headings the ones I want to focus you on today are Mark chat and QA.

Under the chat heading there is the public chat. And that is just what it reports to be a public chat you put something on there every single person logged onto this webinar whether they are on the panel or just in the audience sees what you wrote and that could be a good thing or maybe not but be aware that if you put it in there everyone is going to see it. I always like to get things kicked off by saying hey, I'm coming at you today from Booker.

It's own, Florida. We love to see where you are in the world and where you're logging in from so feel free to jump in and say hi from wherever you are. Then there's the Q&A section of our Communications panel Q&A sections.

If you have a specific comment or question for the panel at large or a particular member on the panel. Put it in there. We will try to get to it.

Mitchell is going to be Manning the Q&A. Channel today, so I'll get it out to the team. Also, you do have the ability to use the private.

Chat in the main chat section and that is if you someone asks a question, you want to engage with them one-on-one not in a public forum you you can do so. The only thing is not caution. You is look this isn't Leisure Larry or anything like that and it's not a place for you, you know to be trolling.

It's it there's a real conversation and don't feel obligated to answer someone if they do reach out to you privately that's consenting adults and all that stuff. I prefer the public chat and the Q&A. That being said, let's move on now to our panel and our topic today.

As Cody mentioned we are going to be discussing. High performing devops teams, how do you how do you develop one? How do you maintain one?

How do you join one even? Maybe I'm lucky enough to have several people here who have actually been. Or have how built high performing devops team is in that careers, and I think it's gonna be a great great conversation.

Let me introduce you. Excuse me. Let me show you our panel now on this.

Um first joining us is Miss Sharon Alvarez and Sharon. Welcome. Welcome back to devops Unbound.

Why don't you introduce yourself to the audience? Hey, thank you very much Helen. Hi everybody.

I'm really excited to be here and to answer your questions. So Sharon, I'm visiting Seattle. I've been in India trial and devops space for probably 10 plus 10 30 years.

I started off in France in lean manufacturing and I've Been instrumental in leading really large scale adoption and Transformations and working with devops team. That's setting up devops. Don't use very excited to be here with you and I'm looking forward to all your questions.

Fantastic. Thanks Sharon. Thanks for joining us.

Next I want to introduce you to I was gonna say an old friend, but he's really not old. He's just been a friend for a long time with me. His name's Brian Dawson.

Brian has a stellar resume in the devops space agile and Brian. It's great to see you. Well, and on on my screen today, welcome back.

Thank you, Alan. Thank you. Yes, I got to experience a bit of the the covid-19 and you're so kind but I am old.

Um, so I've spent about about and it's and it's a joy to be on here with this panel. I currently work for a company called Ripple a company in the blockchain and crypto currency space and I oversee our Partnerships there. I join with about 30 years in software development and delivery and I take pride insane.

I I have a panoramic view. I've worked as an individual contributor or leader and practically every phase of software development and delivery. So while I'm not as deeply credential there's many here.

I think I I have a a perspective. I like to describe myself as a technologist that focuses on working with humans to use to deliver and to develop and deliver better software for humans. Glad to be here with you all today.

Thanks, Brian. Glad you can join us next up. Let me introduce you to one of my favorite people.

Her name is Raven Manuel. So fellow New Yorker like me. She's a bronx account.

I was Queens but both of us are out in New York now. Hey Raven, it's a pleasure to see you again. Why don't you introduce yourself to the audience?

Miss you very much virtual hugs Ella. Thank you. And I I won't tell me about you from Queens will forgive you.

Yeah, I don't tell them usually but yeah, I am Raven manuelas. Um, Alan said I am the senior application developer kind of architect and the devops engineer for the national museum of African American history and culture which is a unit under the Smithsonian institution. My favorite part of my job is actually building the very small interactives that you kind of play with when you're in the gallery space, but I also make policy and and develop processes and strategy for the debt for devops for our unit.

And I'm the AWS and ministrator for our Cloud resources. But as I was telling the panel before we got started I have the best job ever. I do work a little bit but I kind of do a lot of R&D and R&D is like a very cognitive type of jobs.

So I just think a lot. Nothing around with that. No, you know what good thinkers are hard to come by.

Thanks Raven. All right, our fourth panel member is Adam and I Adam. I don't have my like as I mentioned my computers really not in front of me here, but it's Adam field.

Correct? You got it. Cool, I don't why don't you introduce yourself?

Yes, sir. Hey really excited to be here. I know I was recognize a couple of faces and it's actually a pleasure to speak alongside you yeah, so I've been in the industry about two decades or so right now.

My specialty is really helping, you know, Legacy teams. Learn how to adopt devops best practices inside of the cloud and help them migrate over and figure out how to configure pipelines and you know, really kind of understand what it means to have a true cicd cycle. Excellent.

Thanks for joining us Adam and welcome to the panel our last panel member. I've already referenced them a few times as my co-host of devops. I'm down.

It's also a one-time business partner and colleague of mine. Into the little older than me, I'll mention. By three months my friend Mitchell Ashley Mitchell.

Go ahead. I'm just gonna have you call me your favorite CTO. But yeah, that's all I don't know.

That's assuming but God well put it out there now, so it's right. So Mitch Ashley and I am CTO with tech strong group and Mel's Allen mentioned in business partner off and on over several years. I'm also principal of our analyst business helping start that a few years back and we covered devops in cybersecurity and Cloud native AI ml data things that we need to do modern applications today.

So let's get right to it. I want to hear from these these folks. I love this panel.

They're all great folks. So thank you to our team for putting this panel together. Fantastic Mitchell your Manning the chat.

So feel free to interject with questions from the audience. But let's Mitch says let's jump in. So the topic today is high performing devops things look for myself like for many of you out there.

The first time you may have heard that. Term high-performing devops teams was in the Dora reports right kind of the seminal work that Dr. Nicole forsgren and jez humble along with Gene Kim did in as part of Dora in their devops survey, which I should mention was, you know, originally started off by our friends at puppet and their annual devops survey and then The Dora folks, you know started helping out puppet and eventually kind of took that on their own but it still does their devops survey, but that whole concept that high-performing teams.

result intangible positives and tangible pluses was really born out in their research, right? I think up to that point a lot of people in their gut felt that you know, devops could lead to better results more profitability. You know, how whatever metric you want to use to measure better?

Right, but it wasn't until we started seeing it in the door stuff that I think people began to really. Kind of focus in on that look all four. Are you folks on here have been around decades?

Right, we're all familiar with. With the door where kids but is is that sort of The Benchmark for high performing devops team? So what is high performing teams mean to you?

I'll ask anyone who wants to jump in to jump in on that. Um, you know first I I agree. I think the door report did a great job of quantifying what the benefit and kind of Target outcome of of devops is when we talk about some of the sort of key metrics kpis, right?

Those are now just kind of woven into the Lexicon of devops discussion in terms of meantime to recovery cycle time Etc. Um, I would say that that those metrics give us a good foundation to kind of align around but in my opinion a high-performing devops team is less about velocity less about measuring time and really more about ensuring that you have a team that can consistently deliver. They can deliver with quality capabilities and they deliver positive customer experience whether you're front end back-end respect of over your customer is so I'd say continuous consistent quality capabilities and customer experience.

A lot of things there. Yeah, definitely agree with with Brian there and one of the things that we always try to shoot for with high performing teams is we like to say autonomy was security right Is Our Big Goal with you know, the devops teams is trying to remove that that click Ops where a developer tries to promote code to a certain environment by you know, running through some some manual steps. And when we have those High performing teams, what you can do is you can reduce the errors reduce the problems that might occur with that and you know with it autonomy teams naturally will develop things faster.

They naturally will, you know be more High performing because they understand you know, if I run this script, I know that it's been tested. I know that it works and it's something that my devops team has helped me with whether you're going through, you know, Jenkins whether using something like a terraform or ansible, right? It kind of gives you that control to our devops team can go and they can develop and a lot more secure manner without having to go ask the infrastructure team to do something or having to go, you know through a lengthy change management process.

I think that oh, sorry, Alan good. No. No, I was gonna say I my first introduction to high performance teams was in I was going for my emba.

And that was one of the things that was one of the terms that we had to understand and so for me, the devops part of high performance team is just the extra the high performance is actually the thing because it I think Brian he said it before it's about people and so you have in order to be performant and high performance that means you have to be collaborative. You have to engage together interactive respect the space and respect the differences and then be able to as a team go from A to B and get there in time under budget. So for the devops part, I agree with you Adam, all of that is part of a high performance devops team, but it's the high performance.

Focus because it's a person focused and it doesn't really matter what you're doing. You have to work with each other. good point let me let me.

Jump in on something, you know Mitchell and I when we started still secure I had a friend Raj. Co-founded company who founded the company where that's Raja always had to saying that. Everything could be measured and we measure everything.

I think we have Raven and essentially Brian and Adam. You've hit the right thing a lot of seas. As I mentioned right you you've hit the right things.

We need to point to to ascertain or to show. You know what? What are those like what high performing teams are doing?

Well. Of course the question is how do we measure? That they're doing well, right there's God.

What are the metrics that matter? com a lot of people thought all that cultural stuff was Kumbaya stuff and there were no subjective. measurements that would show high performing teams result in better better outcomes for companies, right?

Yeah, the team gets together. Yeah, it's gonna come by. Yeah.

Yeah, but how do we how do we measure it? And so I'm interested sharing, you know your background and you have a lot of agile and you know in that job was a little different because we could Point to well, how much code did you release? How long did you did it take you to release that code?

What would the bugs that were found? How much had to be, you know, redone or what have you there are very specific metrics. We talk about software release per se.

Right that that we can measure high performance and some of those lend themselves to devops but devops has this whole other aspect to it as well. Interested in your thoughts there. Yeah.

Thank you. Allies engagement how high performance team is one that's going to be engaged with the business. Right and what you mentioned around around measuring high performance team.

So I think when we talk about devops in particular we can focus on the Dora Matrix and the technology and especially automation we can focus on all of that and I do believe it's a huge part of helping team become High performing and they want to develop a high velocity and I use the term velocity not in reference to story point, but more in reference to what Mackenzie and Microsoft have introduced the developer velocity index. So I do believe that Automation and the technology super important, but there's also everything that you talked about and what our participants have been talking about, right so psychological safety the research at McKinsey and Microsoft deed and the research at Google did have proven that psychological safety is the criteria number one of innovation and High performance team so and it's very difficult to understand very different still very difficult to introduce. I mean reducing a lot of that right now in my company at Salesforce within my Executives and teams, but I can tell you it's really difficult and difficult to introduce difficult to even talk about and measure and then there's all of the other things you talk to your talk about, you know, the culture the collaboration inclusive inclusive collaboration building that environment where they're going to try and their relationship with the business in the comment.

It's a so I'm going back to Randy shower. Actually, he did a talk where he he made some really good point. He mentioned the fact that those Technologies those technical Matrix are really important but it's important to give our developers devops, you know Engineers Matrix that's gonna help them relate to the business.

So more business driven Matrix and that will drive that generate drive there engagement developers drive when they see that they work is consumed by the business the tribe when they have that relationship with the business and that contributes to developing high performance teams. So those are yeah, let me bring in someone from the audience. Right?

So one of the participants in our audience is we're trying not to use names, you know, it makes a comment the door is great for management in my opinion. Now the flip side of that is okay, but it's great for management. Does that mean it's not great for the individual workers or their teams?

Is it management only? Why is it great for only management? Right or are we trying to say that high-performance is something that management cares about only I I don't buy that I think Sharon that aren't really really sometimes management metrics or vanity metrics, right?

Yeah, sometimes right to make themselves look good. I mean, you know Brian I I know in your life you've been on both sides of that management and contributor. Yeah.

His daughter kind of is the whole High performing thing. Just something that management worries about well Yeah, I mean so this is interesting one. So first of all, I'd say as I may be indicated earlier, I truly strongly believe that Dora gives us a key Baseline of Technical and adjacent metrics, right and oftentimes when management doesn't know doesn't understand the software organization.

They don't know how to kind of say are they doing well or not? It gives some tangible metrics that say in terms of a baseline. Here's how we're delivering.

However, I'd say you cannot stand when connecting Dev and the business devops in the business. You cannot stand on these technical metrics alone because what you don't get through MTT R what you don't get through through cycle time is is how are we influencing key business objectives and maybe our business objective is the market scene a shift. We need to be able to rapidly innovate.

Can you measure that just by saying we're delivering, you know, X number of features to production a week, you can't and so what well, I think it's a good starting point to start to provide some transparency to leadership to start to engage in a discussion all heard back to something Sharon said, look, I'm developers need more than just to be said fix problems this fact remediate this fast. Um where technical creatives we need to understand context. We need to understand how we're bringing our experience and our team to Bear to Saul's I'm higher order problems and to do that.

It's important. You have a deeper dialogue between leadership in the team than just a set of of quantitative a cycle metrics. Yeah Brian if I can build on your point as well.

One of the things that we oftentimes forget when we go for metrics is the why right? Why are we using as metrics? Are we trying to solve a problem?

Are we trying to just highlight the work that the team is doing and I see when metrics like these fail with the leader is because we just decide to measure and we don't explain the story behind it. We don't explain what we're trying to get or even what the expectation is for the leader so we should expect something in return when we're measuring these you know, and and presenting these two leadership of what what do we want from you right? We're we just want to highlight what the team is doing look at the great work.

They're doing okay. We don't need anything else. From you right or we have a problem and here's we've measured it and we need this some sort of solution to fix that problem.

So definitely for teams if you're looking to implement metrics, don't forget your story and don't forget your why. He interject a little different take on this and because I think we're all sort of aligning around metrics and and they are a good thing. There's also a downside to metrics metrics can be very inwardly focused if they can be focused on the wrong things.

That is one of the reasons why we ask you about Dora. No those good things to to focus my my thinking on this is evolved. from neck metrics of the secondary thing the primary thing or what are the outcomes we want to have what is it is a velocity for the business.

Is it flexibility to be able to do experimentation and Market as they're getting out products out faster. Is it having an influence beyond the team? It's not just a team of high performers, but it's a high performance team that's having an effect on the rest of the organization.

And what are those things? We want it to be so some of them might fall into a little bit of a software Camp maybe that totally measurable, but I think that's what defines our metrics so I wouldn't rush just to go. Let's align with Dora and we're good because then management it's not metrics for metrics.

Yeah, exactly ready. Oh, yeah, because I have About all right. One of the reasons why I really like being on this on panels in general is because small agencies get forgotten in the whole conversation and the whole point of agile the methodology and devops this philosophy or back and forth is the flexibility that it offers.

It's not prescriptive. You don't have to do all of the agile stuff and you don't have to do all of the devops stuff. Right?

So if you have all these public in private sectors that are doing devops and agile that works for them. They don't meet the metrics, right your metrics don't even apply. So the metrics are not evenly applied.

They cannot be you cannot say I'm better than this particular organization because you're you're it's apples to like pineapples, right? It's not even the same you get to choose and anyone that's thinking out there about measuring the performance and and the continuous whatever like the continuous Improvement of your teams. That's what you need to be measuring if you want because the whole point of devops is to get better is to to experience incremental change and Alan I think you said it you have to know what your or maybe it's Brian.

I'm rich. I don't know. I was just excited.

Okay. Yes. You just know what it is that you're looking for.

And and if you're asking Yourself fat and you're already in the middle of devops and you probably shouldn't even be doing devops because that was a question. You should have been asking when you were implementing and planning for devops. I'm getting off my soapbox because I could do this all day.

Okay. Hey, we've got a question in the Q&A and I think one of our candies for putting it in there, you know, it says team should aspire to do well and Dora, but how did they do that? Right and it's a human nature thing.

Everyone wants to win. Everyone wants to be successful. It's not like that commercial remember that commercial.

Is that a few years ago? I want to have to retire early because I'm made obsolete. No one really wants that we all we all want to right succeed and be successful.

So, you know, but how getting there is is the issue right? How do we all right? So we we did a Dora survey and you know what, we're not we're not killing it.

We got to get better, right? How do I plot my How do I plot my roadmap if you will? To making to getting better to becoming a high performing team.

Right, unfortunately for a lot of folks out here, they're not part of high performing teams today. Sharon I'm going to ask you if you don't mind kicking off. Maybe Adam has some thoughts.

How do you how do you get on track here? Yeah, you know, it's great that you know, I love it that we are did we taking a step back? And so first we have to be dailyburate about it?

It's just doesn't happen and I like what you say the Riven it's you know and Adam as well. This is going back to the why and then we have to look at our objectives. And also looking at is also looking at being mindful of the barriers the organizational barriers you talked about roadmap Island.

So we need to look at all of the organizational values that we have when we're trying to develop High performing not development when we're trying to make sure a teams and we're trying to help them get better, you know, sometimes I'm not very another huge fan of high performing because he's putting a lot of pressure on the teams to be high performing and it's a Consulting type of you know, where that we use in order to sell to organization. And so I think we have Start with the teams where they are. That's why like what you said Rave in the context, you know, and I'm not talking about doing an assessment but looking at our organization, what are the barriers?

What education do we need to do with our Executives? So the Mackenzie and Microsoft study and I'm referencing it a lot and share it with you. It's very interesting because they they showed that exactly not understand the relationship between Best in Class tools and developer velocity.

So they don't understand that. So we there's a lot of Education that needs to happen at the executive level. Then we also need to look at all of the cultural aspect of the organization.

So the silos We talking about the business and devops and if we talk a lot about that it's because obviously we still see silos right? We still see not only thinking silos but also organizational silos. So we have to look to look at it.

So for me high performing team is not just the technology and Dora. It's a sort of index composed of different, you know, attributes cultural organizational up Skilling. We haven't talked about upskilling our ingenious, right?

This is a huge part of their engagement and their ability to deliver quickly and then some of you talk about Matrix, so we should look at and measuring so there's the health of the team instead of looking at Matrix is more looking at health indicators and also not just the looking at the flow some Metric that are more aligned with business. So expectations such as the flow such as true food this kind of things. Yeah.

Hey, I got a few more questions from the area. I love this. This is the kind of given take we need.

So another participant want to know how do we measure delivery of business value and building the right thing at the right time? This isn't something Dora measures right door. Is it the blue oil and end all there's other there's other I think aspects they're high performing game and this is something that I think is important.

All right Sharon. I know you plus one that one. How do we how do we do that?

Adam any ideas anybody any ideas? Sharon yeah, don't go ahead. I took you.

Yeah, so I you know, I mentioned in my response that it's really hard to understand the value that is being delivered without you know, the voice of the customer and I truly think that you know in the overall, you know cooperation, you know devops really being about people oftentimes especially in large Enterprises that is a big piece missing you have developers working testers working and ultimately something is delivered and kind of goes into a black box and they really never understand are the customers actually happy with what we've delivered and what we've built right and I really think that that's something as a business leader as an executive leader to have that regular communication to have that regular conversation, you know, because if we're building something super fast and it's super neat and it's using the latest tools, but everyone hates it it's not really effective and it's not really what we should be building. Yeah, and and I I did look, you know translating business value into a metric that the software, you know that Devon delivery or devops can use is very business specific. So, I don't think there's a one size fits all answer but a couple of things as we referenced earlier, it's it's important to have a bi-directional dialogue and a common understanding with the business.

I do think that process of of sort of saying, okay, where are we? Where do we want to be? IE connect with the business and understand what our goals as a company are and how our software Services those goals and then saying how do we get there is a discussion that may not immediately Bear all the answers, but it'll set the foundation for a fruitful collaboration between software.

I'm Devin the business now Adam. I think I'd add look absent any other metric in the distance necessarily apply for all other software at the end of the day most businesses are using software in technology to service customers to provide a better experience in one way or an or you know, you may be a few orders removed and may be the back end ordering system that agents use to deliver better person to person experience, right? So absence any other metric, I do believe um, a component of business value should be measured in customer satisfaction customer retention.

Quality of customer engagement and if we start there, we're in a good place. I have a question for Adam. For something can I ask a question?

Sure. So Adam you I was curious because and interested because when you were talking about devops and then you mentioned not having quality but whatever and not knowing what the customer means for me devops is a an outcome of the agile methodology and Angel is actually made that's what it's for to be engaging to have those feedback loops so that by the end you do have what the customer wants. So what were you what was your thought when you actually said that?

Yeah, and it's a great point and and I totally agree and I think some of this comes from you know, maybe the the unfortunate influences a large Enterprises have had on my psyche. And so yeah, I used to work for a very large Healthcare, you know company go unnamed we're for a financial technology company that goes on name. But if you look at my LinkedIn profile, you're probably find it and you know, there's not a lot of teams that that They follow true agile, you know, we may have a lot of teams that you know may you know, do Agile potentially on their planning but it's very, you know waterfall in their delivery and you know, there's a multitude of reasons for that.

This obviously is a full agile chat. But you know, I think one of the things that we've had to realize is, you know from a devops standpoint is how do we help those teams? Right?

How do we you know kind of work with those teams and make sure that you know, whether you're agile waterfall, you know, agile fall or whatever, you know that we can help provide, you know, for those teams. We've kind of come up with a shared services model where we have devops that kind of Pop around from Team to team. So, you know, our team doesn't necessarily see the end results, right?

We kind of physically hear from some of the developers but and that may not even be like a true devops model right based on what some teams are doing but I think you know, one of the things that I truly like in the overall devops philosophy is, you know flexibility of mind, right? You know, how can you kind of like change your the way that you're doing something to serve? Know your customer which my customer is the development team.

Thank you. Good stuff. Okay, we've got another question.

I'm sorry. Go ahead Brian. I just want to start some trouble because something came up here.

I mean we're talking about what we said building High performing devops teams. What's a devops team or are we all talking about the same thing? There you go starting trouble.

You can you can push right past that Adam. com is there such a thing as a devops engineer. Do we have a devops team?

So what is the devops team? Anyway, okay to be a devops engineer. Don't say that.

Okay, 2013. We we've evolved since that right? I hope I hope we have What state and that's why I mentioned a product engineering team.

I really prefer counting them and that's why I rather call any devops dojo. call it a product engineering and the reason for that it's You know devops sometimes may feel me makes the beach May makes the business feel that they are excluded. What we what's going on with devops, right?

It's so engineering driven, but I think it's more it's not the case. They was never meant to be exclusive of the business and you know obsess somebody was never the case actually when it started when the movement started on the contrary and John Williams said in 20 between 2010 actually. It's a really long time ago.

He said it's published. All that attempt of automation are going all your attempt of automation are going to be fruitless. If you don't have the culture to support your devops or culture, right your devops are initiative and that was in 2010.

I think that we still missing the Mark today and I think it's because we have so much I think devops is a really cool industry with a lot of great things happening at a really fast. Case lots of the technology Investments and so it's going a lot faster. Like you said at them.

It's going a lot faster than agile. And I remember I mentioned other conference that I made a lot of enemies we need to automate we need to automate agile not agility. But agile, we focusing on a lot of things about agile that are not relevant and several studies.

I mentioned that I saw some question around planning the you know, the scrum ceremonies, they're not as important as a Focusing on empiricism inspect adapt and the flexibility that we need to help the teams. So I'm really big about we can some people call it bees devops or product engineering and it's not because devops excluded the business. Not at all.

It's just the perception that we have today. Yeah, and one of the things sorry, I don't know. Go ahead.

Yeah. So one of the things that I've you know, come to realize you know with with some of the larger Enterprises is that there's a lot of people especially leaders and hopefully none of my leaders are watching this but don't know anything about devops. You know, so oftentimes we have to be Educators, right?

So a lot of us, you know, we're obviously in this webinar we go to talks we speak at conferences. We read books. We're kind of the anomaly and you know the technology world, right because we are fully ingrained to this and I think sometimes we can get a little Focus thinking that other people kind of know a lot about devops as well.

And I found that that has gotten me into trouble a couple of times when I have a conversation and a leader stops me goes. No. No, what what is a pipeline?

Right and just kind of realizing that a lot of times that the things that we're talking about may not be understood by leaders. So I think you know from our standpoint. I look at devops is having to be an educator on what it means to actually, you know deliver software.

Absolutely. You know what? We've got a bunch of questions in the Q&A and if we hit each one individually would never gonna have time.

I'm gonna take a lot of them together and in my mind they all deal with a similar issue, which is what exactly What what's the makeup of the devops team? Right it's diversity important in a devops team and we talk about diversity. It's not just diversity of men versus women versus people of colors.

It's called agents. It's diversity of roles. It's a diversity of of training of experiences and everything else in my mind.

You can never have enough diversity. Right, but hey, I got a panel experts here. What do you think about that?

Can I step in on this one? Yeah, this one lead on. Our devops team is ethereal.

It actually is not a team. We have a name that people can work under and so if we need something from security, then that security manager is now part of the team. So the team isn't actually this another Silo it's not another Silo it includes all of the technologists and all the people that have to actually support the development and the delivery of a product which includes the stakeholders who are determining the requirements.

So if we need to have requirements, so we know what the infrastructure is then that particular curator for my for our stakeholders. They actually become part of the devops team because it's development and operations. So we are ethereal it's it's really just me being a placeholder holding that space for all of the people that I have to work with even Ocio, which is not even in our organization right just Um bringing them in when they're necessary and I agree with Sharon the business kind of feels like it's outside that bubble but it shouldn't because without them we wouldn't have directive right there would be no directive.

So the organization that's why they everybody says culture but that is actually how the devops team Works in our organization. fair enough think that's a good thoughts to you know of we're engineers and we think about things and putting definitions and boundaries and measurements. And that's good to do too.

There's also a kind of magic site to this. Yeah, when I've been fortunate to either build or be on high performance teams. There is just a magic that happens.

It's it's more than just a team of rock stars in individual rock stars, and it's more than kind of one foot. The Synergy of one plus one is three. It's Things happen things gel communication flows easily flow happens easily the influence that people have on each other, you know, the communications we talk about psychological safety and some of the questions and things like that.

There are a lot of soft things that happen in high performance teams and sometimes to your point Raven. I love the we don't Define it you want to be on the team you're on the team make yourself part of the team and joining. You don't like it.

Go again. It's not a problem. You know, you're not required to be on it.

But there there is a let it be what it's gonna be part of this. I don't to be too metaphysical about it. But whenever we constrain things I always think you know what we're missing some things here by putting too much structure.

Here there's your medical lottery today. Yeah agreement sometimes as as Engineers or people sort of with logically oriented Minds. We want to we want to Define we want to apply engineering solutions to to qualitative people problems, right?

So grateful never works. Well, you know, just one quick thing on diversity, then we could hop on to the dozens of other topics that people are throwing up here is when we talked about diversity another area of diverse city is in today's world. We have like kind of you want to call full staff developers full second Engineers versus low coders and no coders and and those kinds of things in this, you know, there's the testers right?

I said this shout out to our sponsors, you know, they cater to a professional tester. And in many times. They also came to developers they catered to the occasional Through the open source the automation right?

There's so many different within these devops teams when we look at skill sets and competencies. Right that that's another area of diversity that I think diversity that I think we don't. Give it its due right?

And they that comes in all shapes and sizes as well. Brian doesn't like the term full stock. I'm just a grumpy.

I told you I'm all I don't like. You know like RAV. Ens in here.

I know I'm signing a lot of paychecks every two weeks for my full stack developers. Let's talk about that. I don't have to pay him.

That's good. But we don't turn Brian what's wrong with the time? How would you how would you determine that?

Well, I I think it gives it gives kind of a false perception or kind of discounts too much the value of domain expertise, especially when we're looking to deliver and pursuit of quality. So I often run into younger developers that are again. I'm a full stack developer.

Um, and and when we dig a little further what they what they really mean is they've developed an understanding of the vertical stack that they work with but they don't necessarily own or understand end-to-end delivery. So I think you know full stack sort of initially came about and leaned into this concept of somebody that that owns delivery from concept to the poor. And and and there are years of expertise built around security that I don't expect a full fact to developer to hold or network topology or network performance.

So Raven that sort of it I think oftentimes it's meant to project that. I can own delivery from start to finish and that's not what we should be striving. I could be wrong.

I think I think full stack because an evolution out of the old lamp stack days, right? You just kind of refer to it like yeah, maybe I don't know. Yeah, I I kind of sorry Adam.

No, there's no right. Um, I think Brian that because I called myself full stack. Oh, that's okay.

I love it. I love being insulted. It's awesome.

Just makes me happy Bill crust exactly. I really roasting right it is I just I think I understand your agreement. I just think that just because the label has been misused that the label is actually still valid for instance and nobody hate me for this because I don't really follow football.

My favorite teams are actually based off of color and how well the team looks in their uniforms. That's why one of my favorite teams is the Vikings right? I just like the way they look um and Louisiana with the flirt release because I like the Fleur de lease right?

So but can I call it New Orleans? It's okay. Yeah.

Oh, that's how it's reference. No, but it's the same. It's the same what you said Alex.

I'm that doesn't make me a football fan, right? I can call myself a fan but I don't watch any games or anything people. I don't do any football type of stuff.

I just like, oh, yeah. They've got a cool. Form their uniform bites, right?

So full stack is just a label. Um, and it actually I believe Mitch. You're right.

It's about the tech stack and it's about the your skill set and how far in the application you can develop so we should take back the term full stack and revoke the licenses of those people who say that they're full stack anything well, but Dad always this is always what happens in Tech with hype stuff, right? Everybody wants to kind of piece of the hot thing and so and and you know, it goes back to the Microsoft thing right dancing done to Lotus. Don't run.

We that's how old I am what like no because you know watering it down and customizing it and extending it and all of that until it doesn't look. Anything like it was anymore and and it's a tough thing. I got one more.

We're really in overtime already. So if you're joining us in overtime great, um, one other another participant came up with the not a question but a statement that hey devops departments end up becoming support silos in in their experience shifting left building. The discipline in the engineering mindset is key.

But is is that the ultimate Kind of destination for devops teams and departments becoming support transitioning the SRE. Or the can you maintain that cross functional team, or maybe we just need a different name as Sharon says, right. Product engineering was that what it you called?

It sharing project engineering team or yeah, yes, but engineering, you know and but just not a bad word. I certainly don't mean to say anything like that. You know, I'm a huge fan of the movement.

I just think that is it's off. It's still miss on this dude, and there's a lot of education and a lot of training to do around their jobs. I'm a huge fan of devops and I try to you know to support the best I can in my organization and in the community, but when I do so I try to ensure that we see the balance we see that it's not just the application the platform the tooling even though there's a huge emphasis on it.

It's all the other things that we talked about. So it's certainly not a bad word and so productive engineering teams just more holistic because of everything we talked about they don't Present delivering devops a product, you know, they focus on delivering business projects. And so it's just very sweet.

I think the way I look at I also we talked about it on Monday during another Unbound Episode, by the way, they highly encourage you to watch about devops to Jews another way of calling them. I call them value stream dojo's and I don't want to call them very stream teams, but I have to say that I work across value streams right now to clouds there are two value streams and I encourage the teams to think of themselves as part of the value stream rather than as part of, you know supporting technology, which is devops. It doesn't help that there's a Dev SEC Ops that doesn't help anything right there by including that particular label on anything, right?

Okay argue with some of my security friends about that. I'm on my way down. Did RSA for devsec Upstate here and Raven?

You are welcome my friend. That's the opening, you know at RSA. Yeah.

Well, no, you know what I said this before there is only one devops. You do devops. I feel a lot of times we put second there because security people are so like it's a little bit our leaders security person, right?

It makes us feel important. But in any event guys, we're at I got a wrap this up and wind it down. I you know, first of all, I want to thank most of all our audience because we have barely scratched the surface of some of these comments and questions in here.

I just couldn't anymore. I I grabbed my computer back so I could do it and I I couldn't I mean we did the best we could if we didn't get to you. I apologize.

Also had a little malfunction I think with my big marker. So Cody if you gave me those four winners for our Amazon cards, I haven't seen them. So if you want to come on at the end and you can announce the the Amazon winners.

second to last I want to thank Sharon Raven Brian Adam guys. What a great panel. We could have done this for days and just kept going.

Thank you. Thank you so much for coming on here. Thank you to Mitchell as always co-hosting and and riding shotgun with me.

Here. We It's a lot of fun. And then lastly thank you so much to try centers for sponsoring these devops on down events.

They are great. I have a great time with them for those who are interested. I think we have it in the sticky section.

Try sentence virtual Summit a half day conference is coming up it's free. You could click on there to register Mitchell and I think are doing it section there. Um, and we will have a new version, you know a normal not live Round Table version of devops on down in about a week and a half and we'll be back next month with the another live round table.

But till then let me turn this back over to Cody J Brown our face of webinars that like strong learning and he'll tell us about who won our Amazon cards today Cody take it away. Awesome. Thank you so much Alan, and so our full the four winners of our 25 block Amazon gift card drawing.

Our first winner is Trevor B. Our second winner is a shock pee. Our third winner is Sheila G.

Our fourth and final winner is Sean b, so to the four of you. Please keep an eye on your inbox to claim your gift card, but if you don't see an email, just check your spam folder. I would like to before we officially close out just ask our audience to spend one more moment with us to fill out our post webinar survey.

But other than that, we hope to see you at a future upcoming text strong learning webinar. Okay. Thanks, Cody.

Thanks everyone. We'll see you. Thank you guys awesome.

Bye-bye.