 From around the globe, it's theCUBE with digital coverage of DevOps Virtual Forum, brought to you by Broadcom. Hi guys, welcome back. So we have discussed the current state and the near future state of DevOps and how it's going to evolve from three unique perspectives. In this last segment, we're going to open up the floor and see if we can come to a shared understanding of where DevOps needs to go in order to be successful next year. So our guests today are, you've seen them all before, Jeffrey Hammond is here, the VP and principal analyst serving CIOs at Forrester. We've also got Serge Lucio, the GM of Broadcom's Enterprise Software Division and Glenn Martin, the head of QA Transformation at BT. Guys, welcome back. Great to have you all three together. Hi Lisa. Good to be here. All right. So we're all very socially distanced as we've talked about before. Great to have this conversation. So let's start with one of the topics that we kicked off the forum with. Jeff, we're going to start with you, spiritual co-location. That's a really interesting topic that we've uncovered. But how much of the challenge is truly cultural and what can we solve through technology? Jeff, we'll start with you, then Serge, then Glenn. Jeff, take it away. Yeah, I think fundamentally you can have all the technology in the world and if you don't make the right investments in the cultural practices in your development organization, you still won't be effective. Almost 10 years ago, I wrote a piece where I did a bunch of research around what made high performance teams, software delivery teams, high performance. And one of the things that came out as part of that was that these teams have a high level of autonomy. And that's one of the things that you see coming out of the Agile Manifesto. Let's take that to today where developers are on their own in their own offices. If you've got teams where the team itself had a high level of autonomy and they know how to work, they can make decisions, they can move forward. They're not waiting for management to tell them what to do. And so what we have seen is that organizations that embraced autonomy and got their teams in the right place and their teams had the information that they needed to make the right decisions have actually been able to operate pretty well even as they've been remote. And it's turned out to be things like, well, how do we actually push the software that we've created into production that have become the challenges, not are we writing the right software? And that's why I think the term spiritual colocation is so important because even though we may be physically distant, we're on the same plane, we're connected from a shared purpose. Serge and I worked together a long, long time ago. Serge has been what, almost 15, 16 years since we were at the same place. And yet I would say there's probably still a certain level of spiritual colocation between us because of the shared purposes that we've had in the past and what we've seen in the industry. And that's a really powerful tool to build on. So what do tools play as part of that? To the extent that tools make information available to build shared purpose on, to the extent that they enable communication so that we can build that spiritual colocation, to the extent that they reinforce the culture that we want to put in place, they can be incredibly valuable, especially when we don't have the luxury of physical colocation. Hope that makes sense. It does. I should have introduced this last segment as we're all spiritually colocated. All right, so Serge, clearly you're still spiritually colocated with Jeff. Talk to me about what your thoughts are about spiritual colocation, the cultural impact and how technology can move it forward. Yeah, so I think, well, I'm going to sound very similar to Jeff in that respect. I think, you know, it starts with kind of shared purpose and understanding how individuals, teams contribute to kind of business outcome. What is our shared goal, our shared vision? What is it we're trying to achieve collectively and keeping kind of a line to that? And so it really starts with that. Now the big challenge obviously is over the last, you know, 20 years, especially in large organizations, there's been specialization of roles and functions. And so we all have started to basically measure what we do on a daily basis using metrics which oftentimes are completely disconnected from kind of a business outcome or its shared purpose. We kind of revert back to, okay, what is my database of time? What is my cycle time, right? And I think, you know, what we can do or where we really should be focused as an industry is to start to basically provide a lens for these different stakeholders to look at what they're doing in the context of kind of these business outcomes. So, you know, probably one of my favorite experience was to actually witness at one of a large financial institution, you know, two stakeholders of development and operations staring at the same data, right? Which was related to, you know, incoming changes, test execution results, you know, covert coverage, application liabilities and on the other hand, production level incidents. And when you start to put these things in context and represent that in a way that these different stakeholders can look at from their different lens and can start to essentially communicate and understand how they jointly are contributing to that kind of common vision or objective. And Glenn, we talked a lot about transformation with you last time. What are your thoughts on spiritual co-location and the cultural part, the technology impact? Yeah, I mean, I agree with Jeffrey that, you know, the people and culture are the most important thing. Actually, that's why it's really important when you're transforming to have partners who have the same vision as you, who you can work with, have the same end goal in mind. And I've certainly found that with our continuing relationship with Broadcom. What it also does though is although, you know, tools can accelerate what you're doing and can drive consistency. You know, we've seen within Simplify, which is BT's flagship transformation program where we're trying to, as it kind of says, simplify the number of system stacks that we have, the number of products that we have. Actually, at the moment, we've got different value streams within that program who have got organizational silos who are trying to rewrite the wheel, who are still doing things manually. So in order to try and bring that consistency, we need the right tools that actually are at an enterprise grade, which can be flexible to work with in BT, which is such a complex and very different environment where it's spending more area of BT you're in, whether it's a consumer, whether it's a mobile area, whether it's large global or government organizations. You know, we've found that we need tools that can drive that consistency, but also flex to Greenfield, Brownfield, kind of technologies as well. So it's really important that, as I say, from a number of different aspects that you have the right partner to drive the right culture and you've got the same vision, but also who have the tool sets to help you accelerate. They can't do that on their own, but they can help accelerate what it is you're trying to do. And a really good example of that is we're trying to shift left, which is probably quite a bit of a buzz phrase in their kind of testing world at the moment. But, you know, I could talk about things like continuous delivery direct to one of Borecom's tools and it has many different features to it, but very simply on its own, it allows us to give the visibility of what the teams are doing. And once we have that visibility, then we can talk to the teams around, you know, could they be doing better component testing? Could they be using some virtualized services here or there? And that's not even the main purpose of continuous delivery director, but it's just a reason that tools themselves can just give greater visibility, have much more an intuitive and insightful conversations with other teams and reduce those organizations or some of those. Thanks, Ben. So we kind of sum it up, autonomy, collaboration, tools that facilitate that. So let's talk now about metrics. From your perspectives, what are the metrics that matter, Jeff? Well, I'm going to go right back to what Glenn said about data that provides visibility that enables us to make decisions with shared purpose. And so business value has to be one of the first things that we look at. How do we assess whether we have built something that is valuable? You know, that could be sales revenue, it could be net promoter score. If you're not selling what you've built, it could even be what the level of reuse is within your organization or other teams picking up the services that you've created. One of the things that I've begun to see organizations do is to align value streams with customer journeys and then to align teams with those value streams. So that's one of the ways that you get to a shared purpose, because we're all trying to deliver around that customer journey, the value associated with it, and we're all measured on that. There are flow metrics, which are really important. How long does it take us to get a new feature out from the time that we conceive it to the time that we can run our first experiments with it? There are quality metrics, you know, some of the classics or maybe things like defect density or meantime to response. One of my favorites came from a company called Ultimate Software where they looked at the ratio of defects found in production to defects found in pre-production. And their developers were in fact measured on that ratio. It told them that, guess what? Quality is your job too, not just the test department's group. The fourth level that I think is really important in the current situation that we're in is the level of engagement in your development organization. We used to joke that we measured this with the parking lot metric. How full was the parking lot at nine and how full was it at five o'clock? I can't do that anymore since we're not physically co-located. But what you can do is you can look at how folks are delivering. You can look at your metrics in your SCM environment. You can look at the relative rates of churn. You can look at things like, well, are our developers delivering during longer periods? Earlier in the morning, later in the evening, are they delivering on the weekends as well? Are those signs that we might be heading toward burnout because folks are still running at sprint levels instead of marathon levels? So all of those in combination, business value, flow, engagement, and quality, I think form the backbone of any sort of metrics program. The second thing that I think you need to look at is what are we gonna do with the data? And the philosophy behind the data is critical. Unfortunately, I see organizations where they weaponize the data and that's completely the wrong way to look at it. What you need to do is you need to say, how is this data helping us to identify the blockers, the things that aren't allowing us to provide the right context for people to do the right thing? And then what do we do to remove those blockers to make sure that we're giving these autonomous teams the context that they need to do their job in a way that creates the most value for the customers? Great advice, Jeff. Glenn, over to you, metrics that matter to you that really make a big impact. And also, how do you measure quality kind of following on to the advice that Jeff provided? Jeff provided some great advice. Actually, he talks about value and he talks about flow. Both of those things are very much on my mind at the moment. But there was this, I listened to a speaker called Mick Hurston a couple of months ago. He talked very much around how important flow management is and using that to remove waste, to understand in terms of making software changes, what is it that's causing us to do it longer than we need to? So where are those areas where it takes too long? So I think that's a very important thing. For us, it's even more basic than that at the moment. We're on a journey from moving from kind of waterfall to agile. And the problem with moving from waterfall to agile is with waterfall, the business had a kind of comfort that everything was tested together and therefore it's safer. And with agile, there's that kind of, how do we make sure that if we're doing things quick and we're getting stuff out of the door that we give that confidence that that's ready to go? Or if there's a risk that we're able to truly articulate what that risk is. So there's a bit about release confidence and some of the metrics around that and how healthy those releases are. And actually saying, we spend a lot of money and investment setting up our teams, training our teams. Are we actually seeing them deliver more quickly? And are we actually seeing them deliver more value quickly? So those are the two main things for me at the moment. But I think it's also about, generally bringing it all together, the DevOps, we've got kind of value ops, AI ops, how do we actually bring that together so we can make quick decisions and making sure that we are delivering the biggest bang for our buck. Absolutely, biggest bang for the buck. Serge, your thoughts. Yeah, so I think we all agree, right? It starts with business metrics, flow metrics. These are kind of the most important metrics. And ultimately, I mean, one of the things that's very common across AI-fabric function teams is engagements, right? When you see a team that's highly functioning, that's agile, that practices DevOps every day, they are highly engaged. That's definitely true. Now, back to I think, Jefferson's point on weaponization of metrics. One of the key challenges we see is that organizations traditionally have been kind of, you know, setting up benchmarks, right? So what is a good cycle time? What is a good lead time? What is a good mean time to repair? The problem is that this is very contextual, right? It varies, it's going to vary quite a bit depending on the nature of the application and system. And so one of the things that we really need to evolve as an industry is to understand that it's not so much about those flow metrics, it's about all these flow metrics ultimately contribute to the business metric, to the business outcome. So that's one thing. The second aspect I think that's oftentimes misunderstood is that, you know, when you have a bad cycle time or what you perceive as being a bad cycle time or bad quality, the problem is oftentimes like, how do you go and explore why, right? What is the root cause of this? And I think one of the key challenges is that we tend to focus a lot of time on metrics and not on the type patterns which are pretty common across the industry. If you look at, for instance, things like lead time, for instance, it's very common that organizational boundaries are going to be a key contributor to bad lead time. And so I think beyond the metrics, there is I think a lot of work that we need to do in terms of classifying these anti-patterns. Back to you, Jeff, I think you're one of the cool offers of water scrum fall as a key pattern in the industry or anti-pattern. But water scrum fall, right, is a key one, right? And you will detect that through kind of a defect arrival rate that looks like an S curve. And so I think it's beyond kind of the metrics is what do you do with those metrics? Right, I'll tell you, Serge, one of the things that is really interesting to me in that space is I think those of us that have been in the industry for a long time, we know the anti-patterns because we've seen them in our career maybe in multiple times. And one of the things that I think you could see tooling do is perhaps provide some notification of anti-patterns based on the telemetry that comes in. I think it would be a really interesting place to apply machine learning and reinforcement learning techniques. So hopefully something that we'd see in the future with DevOps tools, because as a manager that may be only a 10 year veteran or 15 year veteran, you may be seeing these anti-patterns for the first time. And it would sure be nice to know what to do when they start to pop up. That would, right? Insight always helpful. All right guys, I would like to get your final thoughts on the one thing that you believe our audience really needs to be on the lookout for and to put on their agendas for the next 12 months. Jeff, we'll go back to you. I would say look for the opportunities that this disruption presents. And there are a couple that I see. First of all, as we shift to remote-centric working, we're unlocking new pools of talent where it's possible to implement more geographic diversity. So look to that as part of your strategy. Number two, look for new types of tools. We've seen a lot of interest in usage of low-code tools to very quickly develop applications. That's potentially part of a mainstream strategy as we go into 2021. Finally, make sure that you embrace this idea that you are supporting creative workers, that agile and DevOps are the peanut butter and chocolate to support creative workers with algorithmic capabilities. Peanut butter and chocolate. Glen, where do we go from there? What's the one silver bullet that you think folks should be on the lookout for? I'm wondering now. I certainly agree that low-code is next year, we'll see much more low-code. We'd already started going moving towards a more of a South-based world, but low-code also. I think as well for me, we've still got one foot in the kind of cow camp. We'll be fully trying to explore what that means going into the next year and exploiting the capabilities of cloud. But I think the last thing for me is how do you really instill quality throughout the life cycle? When I heard the word scornful, it kind of made me shudder because I know that's a problem, that's where we're at with some of our things at the moment. So we need to get beyond that. We need to be releasing changes more frequently into production and actually being a bit more brave and having the confidence to actually do more testing in production and going straight to production itself. So I expect to see much more of that next year. Yeah, thank you. I haven't got any food analogies, unfortunately. We all need some peanut butter and chocolate now. All right, Serge, take us home. That's what, what's that nugget you think everyone needs to have on their agendas? So it's interesting, right? So a couple of days ago, we had kind of the latest state of DevOps report, right? And if you read through the report, it's all about velocity, right? It's all about, we still are perceiving DevOps as being all about speed. And so to me, the key advice is in order to create kind of that spiritual co-location, in order to foster engagement, we have to go back to what is it we're trying to do collectively? We have to go back to take everything to the business outcome. And so for me, it's absolutely imperative for organizations to start to plot their value streams, to understand how they're delivering value and to align everything they do from a metrics to delivery to flow to those metrics. And only with that, I think, are we going to be able to actually start to, to really start to align kind of all these roles across the other organizations and drive not just speed, but business outcomes. All about business outcomes. I think you guys, the three of you could write a book together. So I'll give you that as food for thought. Thank you all so much for joining me today and our guests. I think this was an incredibly valuable fruitful conversation and we appreciate all of you taking the time to spiritually co-locate with us today. Guys, thank you. Thank you, Lisa. Thank you. Thank you. For Jeff Hammond, Serge Lucio, and Glenn Martin, I'm Lisa Martin. Thank you for watching the Broadcom DevOps Virtual Forum.