(upbeat music) >> Welcome to the BizOps Manifesto Power panel talking about, "Embracing Agility Across the Business." I'm Lisa Martin, there are three guests here with me today, to break down this topic. Pierre Viljoen, CTO at Global Head of Enterprise Technology and Governance at HTL Enterprise Studio. Hey Pierre, welcome. >> Thank you >> Lisa: Dave West is also here, the CEO of Scrum.org. Hey Dave, good to have you with us. >> Hi Lisa, hi everybody. >> Lisa: And Serge Lucio is here as well, the general manager of Broadcom's Enterprise Software Division. Hey Serge, good to have you on the program. >> Thank you, good to be here. >> So we're going to be talking about the people and the process and technology requirements that businesses need to adopt to be able to embrace agility across the business. We're going to also be talking a lot about this inaugural BizOps industry research survey, on the state of digital business. A lot of very interesting findings that we're going to go through in the next 20 minutes or so. So the first question guys is, the BizOps survey found that over 519 individuals over five countries business and technology executives. This survey found, most organizations still expect this year to be as challenging as last year. I want you to kind of walk us through why that is, and how is that going to impact digital transformation initiatives? Pierre, we'll start with you, then Dave, then Serge. >> Sure, thank you Lisa. So, I think these days, disruption is no longer an exception. It's kind of become the norm or the rule, in terms of how we operate. And as executives in companies have learned over the last year, with everything that's happened is that, you can only modernize to a point, and then you need to do a little bit more. And what really is needed is for us to understand, going forward, how we're actually going to remodel our business by harnessing the resources that we have in a much more agile way, in a more fluent way, from an organizational perspective. And I think our current midterm goal, probably, is that we're capable of remodeling how we can remove roadblocks. These kinds of roadblocks in the future, and get us in a better position where we are. I don't expect things to change dramatically over the next year. More in line with us making sure that we're more future proof in the way in which we're working. >> We still have remote workers, global uncertainty, the vaccine. Dave, what are your thoughts on the impact of this year on digital transformation initiatives? >> Yeah, it's funny. When I think of, sort of uncertainty and chaos, I think that COVID really started it rolling down a hill, but unfortunately it's literally like rolling down a hill, these chaos and complexity. It's getting faster and faster and harder and harder. We're talking about the new norm, right? What is the new normal? We just don't know. And I think the reality is that most organizations were surprised by the impact of COVID-19 and because of that, they responded very quickly. Many of them, people were working at home, they're looking at their supply chain, looking at localization, all sorts of really important things happen, but very quickly, not very strategically. I think the next few years we're going to see, hopefully, some of that realizing into strategy and actually starting to fundamentally change how the business is looking at the world. We've sort of entered the digital age, Lisa, this next age of innovation, we have moved out of mass production and the age of oil, into something very, very different. And I think those organizations, every organization out there is going to have to get a handle on that and COVID was the wake up, right? And I think the next five years are going to be very interesting. >> I agree with you that that accelerant was, I didn't think of it before as a big ball rolling downhill. And now I don't think I'm going to be able to get that out of my head. But Serge, talk to us about your thoughts, the impacts to digital transformation initiatives. >> Yeah, I think back to what Dave was describing. The big challenge is the uncertainty. Many organizations are faced with, currently, a lot of unknowns about, if and when things will go back to, quote unquote, some kind of normality. And with that kind of uncertainty, there's a lot of challenges to the planning from an investment point of view. So, Dave was talking about a short-term versus long-term Like, a lot of these organizations are basically focused on just getting by over the next 12 months and trying to figure out what needs to happen over the next 12 months. At the same time, there's a lot of challenges with respect to readiness and uncertainty. And so, in that context, you got kind of this tension between, "How much do I invest short term "on basically tactical initiatives, "How do I care about teams? "How do I enable these teams "to deliver in weeks as opposed to months? "And then at the same time, "how do I continue to invest "to fundamentally change my operating model?" And that tension is very real. Within many of the organizations we serve. >> One of the things that the survey found was that most of the respondents were very willing to embrace being more agile in order to be able to better respond to rapidly changing market conditions. But I want to get your opinion on what that actually really means, that willingness to embrace being agile. What does it really mean? And what do organize organizations have to do differently? Pierre, I'll start with you. >> Sure, I think we had a discussion a while back and Dave actually got into something interesting where he said, without quoting a famous sneaker brand, just go out and do it. I think that's probably the most important part of this. Most organizations are struggling to figure out, "How should we embrace Agile? "Should we jump in at full scale now? "Should we be looking Scrum? "Should we be doing Scrum-Falls? "Should we be falling over our own feet?" Nobody knows exactly, what might be the right sector? I think the most important part is to pick up a pair of solid principles that you're going to embrace, start executing on them, start learning as you go, and basically improve as you move forward. Over the last year, we've embraced digital product management quite a lot on our side. And it's had tremendous benefits without us, per se, aiming for those benefits at the end of the day. And these are things that you learn as you go. And if you're going to wait around, analysis paralysis is going to be the killer of Agile at the end of day >> "Just do it," I like that. Good advice. Dave, what are your thoughts? >> Yeah, so, I think that what's really interesting is, Agile has been around for 20 years. The manifesto was signed 20 years ago. Scrum came into the world 25 years ago. All of these sort of Agile approaches, but they were predominantly focused on technology. And I think that one thing that I've noticed, over and over again, is that the realization by C-level executives, level sevens, or whatever they're called, they've realized that it's not about technology. (chuckles) It's great, the technologies. I guess the technology's always worked in this complex world because customers never knew what they wanted. We didn't know how are we going to do it. We'd never worked together before. We didn't know how much it was going to cost. So, because of that (chuckles) we had to work in an agile way in technology. But ultimately, I think, one of the big differences going forward, is going to be that, there I say that intersection of business and technology, that BizOps kind of model that we talked about in the manifesto, and what the survey was really trying to tease out. I think that's really, really going to be interesting. And I don't know what that actually means, in terms of the execution. I hope it means that we're going to see teams better aligned to business outcomes. I hope it means that we're going to actually allow those teams that are actually know what they're approaching to make decisions. I hope it means that planning is going to be more directional rather than task level. I hope it means that we're going to start measuring the success in terms of business outcomes, not in terms of the work that we do. I hope it means all of these things. But we will wait and see, because experience would indicate that after a big disaster, lots of people tend to go back to exactly how they worked before, with that sort of emus kind of mentality or ostrich or whatever things sticks its head in the ground. I don't know. >> Sometimes we just want to go back to when things were safe and normal. But in terms of kind of following on, Dave, what you said, 94%, in this survey, 94% of respondents said we should adopt BizOps to increase competitiveness. So, that willingness is there in a vast majority of the respondents. So, I'd like to get your thoughts on what that willingness actually means and what they need to do differently. >> Yes. The problem is that, I think everybody understand that you have to be agile, right? You need to be able to respond quickly to your customer needs. You need to put the customer at the center of everything you do, right? So, conceptually, everybody understands that. The problem is really the operating model that many of these large organizations are dealing with to this day, right? So, you have these sort of Berkeley, kind of organized organization, with functional roles, specialized roles. And when you think about kind of generally, well, one of the big challenges is that you need to start to think horizontally, right? You need to start to start to think about what kind of value streams and what part of the cross functional teams that need to be organized and integrated to deliver on specific business outcomes. You need to start shifting from the traditional contract-based model that(indistinct) to a model which is much more based on trust, right? And we need to move away from vanity measurements and KPIs that many of the organizations typically lead by, to really focus on one thing and one thing only, which is that business value has been delivered. So, fundamentally, I think it requires a bit of a redesign of the operating model in these organizations. And one where, especially when you have a risk adversed kind of organizations, you need to start to be more accepting of risk, fundamentally. >> More accepting of risk. You brought something up there starts that I want to tackle in the next question with respect to culture. But one of the things that the survey uncovered was an interesting kind of seeming contradiction. The majority of respondents said, "We agreed, digital transformation "is about business outcomes "more than it is about technology." But 62% said, "We're still adopting technology for technology's sake." What does that actually mean? And what's the kind of cultural impact there for organizations to really get that more aligned on the digital transformation and the technology and the business outcomes? Pierre, we'll start with you. >> Sure. So, I think there were a number of reports this year talking about what's happened, what's not happened, and the majority of them focused on the fact that, as tech leaders, for years we've been praying to the gods to get budget approved to do all kinds of modernization activities to our infrastructure, our IT, tools, et cetera. And, lo and behold, the ball comes rolling down the hill, smashes a few things and we basically get some blank checks. So, we run around and we buy a whole bunch of stuff to modernize and to embrace this ability to do things differently. And in that whole process, what we basically did was buy more tools and buy more technology. And in that whole process, we didn't really embrace what it is that we're trying to achieve. So, basically aligning the technology to the actual business requirements getting closer to the customer, being able to understand where our market's moving, how we're capable of reducing the journey, if I can put it that way, and make sure that we're more aligned to where we need to be. So, although a lot of CIOs and CTOs got away with doing a lot of great stuff over the last year and users like me are like, "Ooh! I don't have to worry "about stupid VPNs and things anymore." That all went away. But in the same instance, I didn't really get anything that changed the organizational dynamic, which is a challenge. We still have the fundamental problems we have because the business leaders are not yet embracing the deep monitor of the processes that are supported by the technology. And then driving that in such a way that we can gain more business value which is important. To Serge's previous point, we're doing all these great things but we're not focusing on the incremental value that we're supposed to be getting. >> Dave, did it surprise you that there was this seemingly contradictory response? Yes, it's more about business outcomes and technology, but we're still adopting technology for technology's sake. What are your thoughts on that? And how can organizations actually start to move the needle on that? >> E-comm by cultural change, right? But you do know that your board and your leadership want you to do something, and the easiest thing you can do is buy something. I'm a sort of now an American, so, that's kind of my mantra in life, right? "When in doubt go shopping." Which is fantastic, just for the record. (Lisa laughs) But so, you've got to be seen to be doing something, whether it's replacing a VPN, which is always a fun thing to do, or whether it's getting on Slack. Everyone's going to be on Slack. that's going to help. But actually the core is that, exactly what Serge and Pierre have been saying all along, it's that, "Okay. So what is our business all about? "What are our customers? "what did they actually need? "What do our employees need? "How do we build a better value stream "from customer to the organization? "How do we align our teams to that? "How do we incentivize correctly "both the employees that are working "and our partners that are providing things "in this supply chain. How do we do all of those things?" Ultimately though, that means that we have to take a step back which is a very frustrating thing at the moment. And actually look at what is our business all about? What is the mission of it? Who are the customers? Take a moment to find what those are. And then, soon as we have that, and we don't have to do it. As Pierre said, we don't have to do it completely. We can do it incrementally. Organizations are very inward looking. That is the industrial mindset. That is that paradigm. It's looking, as Serge talked about, silos, "optimizing my department," "optimizing my budget, optimizing my kingdom." And what we're talking about is something that cross cuts all of that. So, the decision making is going to change around where the investments go and that's going to be really, really challenging. So, I'm not surprised, I'm not at all surprised that everybody says we should be doing this. And it's like classic. Everybody says we need to be fitter, but we're still all not fit. (Serge laughs) It's sort of, that's just the reality of the world that we live in, right? But we have to start making a stand. And the place we begin is customers. That's the place. And as soon as we start doing that, then everything else just becomes quite easy, actually. >> I like that. Focus on customers and it becomes easy. Serve, I'm kidding. What are your thoughts on this? >> Yeah, I think Dave summarized it well. It's very easy to just buy a tool or buy something, right? Fundamentally changing kind of an operating model is very difficult, but you need to fundamentally rethink for instance, all the responding initiatives. So, something as mundane as, You know, as a leader in my organization I have a budget, right? What's my incentive of collaborating with my peers in terms of delivering credible analysis form. And so, that to me kind of a fundamental shift that we need to operate, and that's probably one of the reasons why many of our largest organizations that we're serving are starting to introduce some new roles like a Chief Digital Officer, as kind of a way to kind of bring kind of a slightly different organization design. The challenge, though, is that, well, all of these teams are still kind of integrated with this fabric of these large systems which exist. So when we look at these value streams, in fact they're not independent from one another. You have a bunch of interdependencies. You are looking at kind of networks of these value streams. But the fundamental shift that we need to see is what we want these organizations to think about, ultimately with the part of the products or services that need to be focused on, all of these become kind of the primary things that we measure from point of view, and how do we align teams and projects and funding along these kinds of outcomes? >> So being customer focused, also being more broadly focused you mentioned the Chief Digital Officer role, which has an interesting role. It's supposed to look more, holistically, internally and externally. And we know that these organizations know we need to be better at this. like Dave's joke about we know we need to be more fit. But what's it going to take to actually create that collaboration, so that IT and business leaders are really working in lockstep and doing so in a timely fashion, so, that they're able to stay competitive. I do want to know from each of you, are you seeing examples of this already in progress? Pierre, let's start with you. >> I can only give you another example and say, one of the interesting things that we did was we try to embrace the delivery of services at HR in kind of a different frame this year, and kind of productize the services that we deliver. Now, if you're most people, you're trying to think about, "How do I set up things like communities "of practice and collaboration between people so "that they can work together on developing new services "new features, new products, et cetera." And we set out with creating this agile way of working. What we didn't anticipate, which was a very nice side effect, is that, because of COVID, because of the catalyst that it provided us, the remote working, people sense of ownership is inherently there. Meaning that self-organization of teams started happening. Nobody needed to crack a whip to get a bunch of guys to talk together with one another to figure out how to get stuff done. It's not like you could walk over to the water cooler and have a chat to Bob. Bob is a thousand miles away, or Bobby's sitting in another State. So, all of a sudden, all dynamic changed. And I have to say, people are a lot more resilient than what they're being given credit for. And if, as organizations, we embrace the culture in such a way and harness it in a positive way, we can actually get this movement to happen. And we actually can make the sum of the parts to be more than the whole. And this year we've seen that happen. And by no means, are we done 'cause we still have a lot of work to do, like Serge said, we have budgets, and budgets give you finite amount of movement left or right. Then you have to do what's best and possible within the frame that you're given. But I think embracing the cultural change and helping people to really excel at that and empowering them makes a huge difference in the way that you can get stuff done. >> Absolutely. Dave, what are your thoughts on this? >> I'm going to say something a little bit controversial, I think. I'm not a big fan of Chief Digital Officers. It just seems like we've got a problem. And some would argue that, "Well, if you've got a problem with somebody "you should get a coach" and all this stuff "and you get it sorted." And that's probably a good thing. But most digital officers, they're going to build a long-term career and create yet another stove pipe and that stove pipe's responsible for bringing all the other stove pipes together. It sounds a bit odd. If a digital officer is really there as a short term enabler, 'cause you asked IT and business leaders, trying to get them to work together better. The best business leaders (bell dings) know about IT, right? The best business leaders are IT sanctuary. Elon Musk or Jeff Bezos are great business leaders, but they know about technology, right? That's what brings them together. Technology is an asset and they may not be the most biggest expert in it, but they care deeply about learning about that stuff. So, I think the next few years we're going to see a lot of C-level and leaders in organizations become a lot more tech savvy, and maybe hire coaches to help them navigate. And the Chief Digital Officer will become more of a coach rather than a person that rolls out Slack or something, you know? (Pierre laughs) So, I think that is going to be the next big jump, really, when we realize that you don't get an additional thing. It's just part of what you do. >> Serge, agree, disagree? >> I agree. The reality is that it is happening, right? Don't get me wrong. We see that every day that so many States are highly integrated, organizations and teams are measuring business value, business outcomes. The problem is that it's oftentimes a very small subset of what these organizations are doing. And so, it's almost like the CEO is coming as kind of these new kind of, as Dave described. And it's got this new style organization which is really there to kind of scale what has been working with these organizations, but we're kind of creating this kind of almost shadow organization, as opposed to fundamentally rethinking and redesigning the organization and redesigning kind of the operating model. And so, we're kind of layering new stuff as opposed to fundamentally transforming. So, as long as it is just kind of just a step towards kind of a true transformation, I think that's fine. The challenge is to, again, create kind of a new set of silos, which are now called value streams, as opposed to young functional silos that we have today. >> So a lot of opportunities identified in this survey but there are still a lot of challenges there. So, I'd love to get you guys and our final question here in this panel to help us understand, from the BizOps coalition's perspective, how are you helping organizations to navigate these challenges, so, they can become successful, transform and actually become agile to respond to rapidly changing market conditions? Pierre, kick us off. >> Sure, from a coalition perspective, we're just trying to make sure that there's a set of sensible principles. That people can look at, can adopt that I think Dave mentioned it in another discussion, that give you that clarity of thought and mind in terms of what should you be thinking? How should you be thinking about it? What are the various aspects you need to consider? And then from that perspective, how do you implement these things in a sensible way for your organization? By no means is this this like, "Here are the 10 steps, you do them, and you're done." You'll be rich beyond your wildest dreams. It's not how it work. You're still going to have to work at it. You're still going to have to figure some stuff out. You're going to have to deep in yourself in your organizational policies, procedures, understand how the organization is actually working. You can't strap a V8 to Mini Cooper and expect to break the land speed record, without the wheels falling off, or something going wrong. So, you really need to harness that in a more sensible manner to move forward. And I think the coalition is on the right path to help organizations realize, "what is the sensible way to go?" "What are principles we can adopt "that we can abide by that will help us drive business "in a different way and close this chasm of disparity "between business and IT?" >> And Dave, your perspective on the BizOps coalition, helping organizations to sort through these challenges. >> Yeah. I'm going to share a little bit of a personal story. So, I must admit that I wasn't keen on the whole idea, and Serge sent me some stuff and he's like, "Could you just provide some feedback." And I did, and then there was a press release with my name on it. I saw, I was like, "Oh my God! "I better get involved because I don't want to "have my name associated "with something that doesn't make sense" But I've actually been surprisingly, I've actually found it a lot more positive than I thought because of exactly what Pierre's saying. So, basically, the coalition is a group of vendors, a bucolic of consultants, some pseudo thought leaders that think they are very thoughtful and maybe they're not, people like me. (Pierre laughs) And what we're doing though, is actually trying to get some clarity of terminology, get some clarity of, what are the principles? What are those key principles? How do they relate to each other? Get some, some synergy to allow, 'cause there's so much noise out there. And hopefully, this is going to say, "Okay, this is what BizOps is. "This is why it's important. "These are some simple things." And then hopefully, because of the breadth that Serge and others have managed to get in terms of membership, we're going to get all of those organizations to be consistently talking about these things, which will then create pressure on the market to actually start adopting these things in the way that we're proposing, or challenge those ideas and then make them better. So, I'm kind of excited about it, surprisingly, 'cause the last thing we need is yet another manifesto and group of people that spend their whole time talking about things and never getting anything done. But actually I think there might be some valuable stuff that comes out here and we're going to inspect and adapt to make sure it is valuable. And if it isn't, we will stop. (chuckles) (Lisa laughs) >> And Serge, strap us up with your thoughts and extending that value. >> Look, we started the BizOps manifesto really with kind of a very simple observation. Everybody's talking about the same stuff, right? But you have a value stream management church, the digital product management's church, the DevOps church, with Scrum church, the safe church. Right? But we're all saying the same thing. But we create so much confusion with our large enterprise customers, but it's just not a grain on a set of principles. And just saying like, look, fundamentally, we're all talking about the same thing. And there are process aspects, there are cultural aspects. There is what you measure. But fundamentally we agree on the same core set of principles. And so for me, the BizOps manifesto, first and foremost is to get the stakeholders from these different communities together, and recognize that, at the end of the day, we share the same values and create some clarity to the market as to how these pieces fit to one another. The second aspect, which is more from our point of view, as one of the vendors of tools, right? There's tons of tools out there. We talk a lot about kind of measuring business outcomes as a primary way to actually align to everybody in our organization. Well, today if you look at any of these organizations, on average, they use about 40 different tools on one of these value streams. None of that stuff integrates with one another. It's extremely difficult for an organization to be able to trace from an investment, all the way to stuff that delivers value and production to a customer. And so, one of my hopes for the coalition is that we start to actually provide some platform, data models, ontologies, to start to integrate those different tools to facilitate that kind of integration. So, those are kind of the two things which I think we can really help kind of develop and and improve on. >> Well, we know that there's a tremendous amount of folks out there that are wanting to embrace agility across the business, identifying areas where they need to do work. So, great advice from the three of you. Thank you so much for joining me on this power panel today and sharing what organizations can do to really embrace that agility across the organization. >> Thank you. >> Thank you. >> Thank you. >> Pierre Viljoen, Dave West and Serge Lucio. I'm Lisa Martin. Thanks for watching. (upbeat music)

(upbeat music) >> Welcome to this BizOps Manifesto Power Panel, Data Lake or Data Landfill. We're going to be talking about that today. I've got three guests joining me. We're going to dive through that. Kieran Taylor is here the CMO of Broadcom's Enterprise Software Division. Kieran, great to have you on the program. >> Thank you, Lisa. >> Kevin Surace is here as well. Chairman and CTO of Appvance, hey Kevin. >> Hey Lisa. >> And Isaac Sacolick Author and CEO of StarCIO. Isaac, welcome. >> Hi Lisa, thanks for having me. >> So we're going to spend the next 25 to 30 minutes talking about the challenges and the opportunities that data brings to organizations. You guys are going to share some of your best practices for how organizations can actually sort through all this data to make data-driven decisions. We're also going to be citing some statistics from the Inaugural BizOps Industry Survey of the State of Digital Business in which 519 business and technology folks were surveyed across five nations. Let's go ahead and jump right in and the first one in that server that I just mentioned 97% of organizations say we've got data related challenges, limiting the amount of information that we actually have available to the business. Big conundrum there. How do organizations get out of that conundrum? Kieran, we're going to start with you. >> Thanks Lisa. You know, I think, I don't know if it's so much limiting information as it is limiting answers. There's no real shortage of data I don't think being captured, recently met with a unnamed auto manufacturer Who's collecting petabytes of data from their connected cars and they're doing that because they don't really yet know what questions they have of the data. So I think you get out of this Data Landfill conundrum by first understanding what questions to ask. It's not algorithms, it's not analytics. It's not, you know, math that's going to solve this problem. It's really, really understanding your customer's issues and what questions to ask of the data >> Understanding what questions to ask of the data. Kevin, what are your thoughts? >> Yeah, look, I think it gets down to what questions you want to ask and what you want out of it, right? So there's questions you want to ask but what are the business outcomes you're looking for, which is the core of BizOps anyway, right? What are the business outcomes and what business outcomes can I act upon? So there are so many business outcomes you can get from data and you go, well, I can't legally act upon that. I can't practically act upon that. I can't, whether it's lay off people or hire people or whatever it is, right? So what are the actionable items? There is plenty of data. We would argue too much data. Now we could say, is the data good? Is the data bad? Is it poorly organized? Is it, noisy? There's all other problems, right? There's plenty of data. What do I do with it? What can I do that's actionable? If I was an automaker and I had lots of sensors on the road, I had petabytes, as Kieran says and I'd probably bringing in petabytes potentially every day. Well, I could make myself driving systems better. That's an obvious place to start or that's what I would do but I could also potentially use that to change people's insurance and say, if you drive in a certain way something we've never been able to do. If you drive in a certain way, based on the sensors you get a lower insurance rate, then nobody's done that. But now there's interesting business opportunities for that data that you didn't have one minute ago and I just gave away. So, (laughs) it's all about the actionable items in the data. How do you drive something to the top line and the bottom line? 'Cause in the end, that's how we're all measured. >> And Isaac, I know you say data is the lifeblood. What are your thoughts on this conundrum? >> Well, I think, you know, they gave you the start and the end of the equation, start with a question. What are you really trying to answer? What you don't understand that you want to learn about your business connect it to an outcome that is valuable to you. And really what most organizations struggle with is a process that goes through discovery, learning what's in the data, addressing data, quality issues, loading new data sources if required and really doing that iteratively and we're all agile people here at BizOps, right? So doing it iteratively, getting some answers out and understanding what the issues are with the underlying data and then going back and revisiting and reprioritizing what you want to do next. Do you want to go look at another question? Is the answer heading down a path that you can drive outcomes? Do you got to go cleanse some data? So it's really that, how do you put it together so that you can peel the onion back and start looking at data and getting insights out of it. >> Great advice, another challenge though, that the survey identified was that nearly 70% of the respondents and again, 519 business and technology professionals from five countries said, we are struggling to create business metrics from our data with so much data, so much that we can't access. Can you guys share best practices for how organizations would sort through and identify the best data sources from which they can identify the ideal business metrics? Kieran, take it away. >> Sure thing, I guess I'll build on Isaac's statements. Every company has some gap in data, right? And so when you do that, that data gap analysis I think you really, I don't know. It's like Alice in Wonderland, begin at the beginning, right? You start with that question like Isaac said, And I think the best questions are really born from an understanding of what your customers value. And if you dig into that, you understand what the customers value, you build it off of actual customer feedback, market research then you know what questions to ask and then from that, hey, what inputs do I need to really understand how to solve that particular business issue or problem. >> Kevin, what are your thoughts? >> Yeah, I'm going to add to that, completely agree but, look, let's start with sales data, right? So sales data is something, everybody watching this understands, even if they're not in sales, they go well, okay, I understand sales data. What's interesting there is we know who our customers are. We could probably figure out if we have enough data, why they buy, are they buying because of a certain sales person? Are they buying because it's a certain region? Are they buying because of some demographic that we don't understand, but AI can pull out, right? So I would like to know, who's buying and why they're buying. Because if I know that I might make more of what more of those people want whatever that is, certain fundamental sales changes or product changes or whatever it is. So if you could certainly start there, if you start nowhere else, say I sell X today. I'd like to sell X times 1.2 by next year. Okay, great. Can I learn from the last five years of sales, millions of units or million or whatever it is, how to do that better and the answer is for sure yes and yes there's problems with the data and there's holes in the data as Kieran said and there's missing data. It doesn't matter, there's a lot of data around sales. So you can just start there and probably drive some top line growth, just doing what you're already doing but doing it better and learning how to do it better. >> Learning how to do it better. Isaac, talk to us about what your thoughts are here with respect to this challenge. >> Well, when you look at that percentage 70% struggling with business metrics, you know what I see is some companies struggling when they have too few metrics and you know, their KPIs, it really doesn't translate well to people doing work for a customer for an application, responding to an issue. So when you have too few in there too disconnected from the work, people don't understand how to use them and then on the flip side I see other organizations trying to create metrics around every single part of the operation, you know, dozens of different ways of measuring user experience and so forth. And that doesn't work because now we don't know what to prioritize. So I think the art of this is management coming back and saying, what are the metrics? Do we want to see impact and changes over in a short amount of time, over the next quarter, over the next six months and to pick a couple in each category, certainly starting with the customer, certainly looking at sales but then also looking at operations and looking at quality and looking at risk and say to the organization, these are the two or three we're going to focus on in the next six months and then I think that's what simplifies it for organizations. >> Thanks, Isaac. So something that I found interesting, it's not surprising in that the survey found that too much data is one of the biggest challenges that organizations have followed by the limitations that we just talked about in terms of identifying what are the ideal business metrics, but a whopping 74% of survey respondents said we failed to have key data available in real time, which is a big inhibitor for data-driven decision-making. Can you guys offer some advice to organizations? How can they harness this data and glean insights from it faster, Kieran, take it away. >> Yeah, I think there are probably five steps to establishing business KPIs and Lisa your first two questions and these gentleman's answers laid out the first two that is define the questions that you want answers for and then identify what those data inputs would be. You know, if you've got a formula in mind, what data inputs do do you need? The remaining three steps. One is, you know, to evaluate the data you've got and then identify what's missing, you know what do you need to then fetch? And then that fetching, you need to think about the measurement method, the frequency I think Isaac mentioned, you know this concept of tools for all. We have too many tools to collect data. So, the measurement method and frequency is important standardizing on tools and automating that collection wherever possible. And then the last step, this is really the people component of the formula. You need to identify stakeholders that will own those business KPIs and even communicate them within the organization. That human element is sometimes forgotten and it's really important. >> It is important, it's one of the challenges as well. Kevin, talk to us about your thoughts here. >> Yeah, again I mean, for sure you've got in the end you've got the human element. You can give people all kinds of KPIs as Isaac said, often it's too many. You have now KPI the business to death and nobody can get out and do anything that doesn't work. Obviously you can't improve things until you measure them. So you have to measure, we get that. But this question of live data is interesting. My personal view is only certain kinds of data are interesting, absolutely live in the moment. So I think people get in their mind, oh, well if I could deploy IOT everywhere and get instantaneous access within one second to the amalgam of that data, I'm making up words too. That would be interesting. Are you sure that'd be interesting? I might rather analyze the last week of real, real data, really deep analysis, right? Build you know, a real model around that and say, okay for the next week, you ought to do the following. Now I get that if you're in the high-frequency stock trading business you know, every millisecond counts, okay? But most of our businesses do not run by the millisecond and we're not going to make a business decision especially humans involved in a millisecond anyway. We make business decisions based on a fair bit of data, days and weeks. So this is just my own personal opinion. I think people get hung up on this. I've got to have all this live data. No, you want great data analysis using AI and machine learning to evaluate as much data as you can get over whatever period of time that is a week, a month a year and start making some rational decisions off of that information. I think that is how you run a business that's going to crush your competition. >> Good advice, Isaac what are your thoughts on these comments? >> Yeah, I'm going to pair off of Kevin's comments. You know, how do you chip away at this problem at getting more real time data? And I'll share two insights first, from the top down, you know, when StarCIO works with a group of CEO and their executive group, you know how are they getting their data? Well, they're getting it in a boardroom with PowerPoints with spreadsheets behind those PowerPoints, with analysts doing a lot of number crunching and behind all that are all the systems of record around the CRM and the ERP and all the other systems that are telling them how they're performing. And I suggest to them for a month, leave the world of PowerPoint and Excel and bring your analysts in to show you the data live in the systems, ask questions and see what it's like to work with real time data. That first changes the perspective in terms of all the manual work that goes into homogenizing that data for them. But then they start getting used to looking at the tools where the data is actually living. So that's an exercise from the top down from the bottom up when we talk to the it groups, you know so much of our data technologies were built at a time when batch processing in our data centers was the only way to go. We ran these things overnight to move data from point a to point B and with the Cloud, with data streaming technologies it's really a new game in town. And so it's really time for many organizations to modernize and thinking about how they're streaming data. Doesn't necessarily have to be real time. It's not really IOT but it's really saying, I need to have my data updated on a regular basis with an SLA against it so that my teams and my businesses can make good decisions around things. >> So let's talk now about digital transformation. We've been talking about that for years. We talked a lot about in 2020, the acceleration of digital transformation for obvious reasons. But when organizations are facing this data conundrum that we talked about, this sort of data disconnect too much can't get what we need right away. Do we need it right away? How did they flip the script on that so that it doesn't become an impediment to digital transformation but it becomes an accelerant. Kieran >> You know, a lot of times you'll hear vendors talk about technology as being the answer, right? So MI, ML, my math is better than your math, et cetera. And technology is important but it's only effective to the point that which people can actually interpret understand and use the data. And so I would put forth this notion of having data at all levels throughout an organization too often. What you'll see is that I think Isaac mentioned it, you know the data is delivered to the C-suite via PowerPoint and it's been sanitized and scrubbed, et cetera. But heck, by the time it gets to the C-suite it's three weeks old. Data at all levels is making sure that throughout organization, the right people have real-time access to data and can make actionable decisions based upon that. So I think that's a real vital ingredient to successful digital transformation. >> Kevin. >> Well, I like to think of digital transformation as looking at all of your relatively manual or paper-based or other processes whatever they are throughout the organization and saying is this something that can now be done for lack of a better word by a machine, right? And that machine could be algorithms. It could be computers, it could be humans it could be Cloud, it could be AI it could be IOT doesn't really matter. (clears throat) And so there's a reason to do that and of course, the basis of that is the data. You've got to collect data to say, this is how we've been performing. This is what we've been doing. So an example, a simple example of digitalization is people doing RPA around customer support. Now you collect a lot of data on how customer support has been supporting customers. You break that into tiers and you say, here's the easiest, lowest tier. I had farmed that out to probably some other country 20 years ago or 10 years ago. Can I even with the systems in place, can I automate that with a set of processes, Robotic Process Automation that digitizes that process now, Now there still might be, you know 20 different screens that click on all different kinds of things, whatever it is, but can I do that? Can I do it with some Chatbots? Can I do it with it? No, I'm not going to do all the customer support that way but I could probably do a fair bit. Can I digitize that process? Can I digitize the process? Great example we all know is insurance companies taking claims. Okay, I have a phone. Can, I take a picture of my car that just got smashed send it in, let AI analyze it and frankly, do an ACH transfer within the hour, because if it costs them insurance company on average 300 to $500 depending on who they are to process a claim, it's cheaper to just send me the $500 then even question it. And if I did it two or three times, well then I'm trying to steal their money and I should go to jail, right? So these are just, I'm giving these as examples 'cause they're examples that everyone who is watching this would go, oh I understand you're digitizing a process. So now when we get to much more complex processes that we're digitizing in data or hiring or whatever, those are a little harder to understand but I just tried to give those as like everyone understands yes, you should digitize those. Those are obvious, right? >> Now those are great examples, you're right. They're relatable across the board here. Isaac, talk to me about what your thoughts are about. Okay, let's do the conundrum. How do we flip the script and leverage data, access to it insights to drive and facilitate digital transformation rather than impede it. >> Well remember, you know, digital transformation is really about changing the business model, changing how you're working with customers and what markets you're going after. You're being forced to do that because of the pace digital technologies are enabling competitors to outpace you. And so we really like starting digital transformations with a vision. What does this business need to do better, differently more of what markets are we going to go after? What types of technologies are important? And we're going to create that vision but we know long-term planning, doesn't work. We know multi-year planning, doesn't work. So we're going to send our teams out on an agile journey over the next sprint, over the next quarter and we're going to use data to give us information about whether we're heading in the right direction. Should we do more of something? Is this feature higher priority? Is there a certain customer segment that we need to pay attention to more? Is there a set of defects happening in our technology that we have to address? Is there a new competitor stealing market share all that kind of data is what the organization needs to be looking at on a very regular basis to say, do we need to pivot, what we're doing? Do we need to accelerate something? Are we heading in the right direction? Should we give ourselves high fives and celebrate a quick win? Because we've accomplished something 'cause so much of transformation is what we're doing today. We're going to change what we're doing over the next three years, and then guess what? There's going to be a new set of technologies. There's going to be another disruption that we can't anticipate and we want our teams sitting on their toes waiting to look at data and saying, what should we do next? >> That's a great segue Isaac into our last question, which is around culture that's always one of those elephants in the room, right? Because so much cultural transformation is necessary but it's incredibly difficult. So question for you guys, Kieran we'll start with you is, should you advise leadership, should really create a culture, a company-wide culture around data? What do you think? >> Absolutely. I mean, this reminds me of DevOps in many ways and you know, the data has to be shared at all levels and has to empower people to make decisions at their respective levels so that we're not, you know kind of siloed in our knowledge or our decision-making, it's through that collective intelligence that I think organizations can move forward more quickly but they do have to change the culture and they've got to have everyone in the room. Everyone's got a stake in driving business success from the C-suite down to the individual contributor >> Right, Kevin, your thoughts >> You know what? Kieran's right. Data silos, one of the biggest brick walls in all of our way, all the time, you know SecOps says there is no way I'm going to share that database because it's got PII. Okay, well, how about if we strip the PII? Well, then that won't be good for something else and you're getting these huge arguments and if you're not driving it from the top, certainly the CIO, maybe the CFO, maybe the CEO I would argue the CEO, drives it from the top. 'Cause the CEO drives company culture and you know, we talk BizOps and the first word of that is Biz. It's the business, right? It's Ops being driven by business goals and the CEO has to set the business goals. It's not really up to the CIO to set business goals. They're setting operational goals, it's up to the CEO. So when the CEO comes out and says our business goals are to drive up sales by this drive down cost by this drive up speed of product development, whatever it is and we're going to digitize all of our processes to do that. We're going to set in KPIs. We're going to measure everything that we do and everybody's going to work around this table. By the way just like we did with DevOps a decade ago, right? And said, Dev, you actually have to work with Ops now and they go, those dangerous guys way over in that other building, we don't even know who they are but in time people realize that we're all on the same team and that if developers develop something that operations can't host and support and keep alive, it's junk right? And we used to do that and now we're much better at it. And whether it's Dev, SecOps or Dev two-way Ops, whatever all those teams working together. Now we're going to spread that out and make it a bigger pyre on the company and it starts with the CEO. And when the CEO makes it a directive for the company I think we're all going to be successful. >> Isaac, what are your thoughts? >> I think we're really talking about a culture of transformation and a culture of collaboration. I mean, again, everything that we're doing now we're going to build, we're going to learn. We're going to use data to pivot what we're doing. We're going to release a product to customers. We're going to get feedback. We're going to continue to iterate over those things. Same thing when it comes to sales, same things that you know, the experiments that we do for marketing, what we're doing today, we're constantly learning. We're constantly challenging our assumptions. We're trying to throw out the sacred cows with status quo, 'cause we know there's going to be another Island that we have to go after and that's the transformation part. The collaboration part is really you know, what you're hearing. Multiple teams, not just Dev and Ops and not just data and Dev, but really the spectrum of business of product, of stakeholders, of marketing and sales, working with technologists and saying, look this is the things that we need to go after over these time periods and work collaboratively and iteratively around them. And again, the data is the foundation for this, right? And we talk about a learning culture as part of that, the data is a big part of that learning, learning new skills and what new skills to learn is as part of that. But when I think about culture, you know the things that slow down organizations is when they're not transforming fast enough, or they're going in five or six different directions, they're not collaborative enough and the data is the element in there that is an equalizer. It's what you show everybody to say, look what we're doing today is not going to make us survive over the next three years. >> The data equalizer, that sounds like it could be movie coming out in 2021. (laughing) Gentlemen, thank you for walking us through some of those interesting metrics coming out of the BizOps Inaugural Survey. Yes, there are challenges with data. Many of them aren't surprising but there's also a lot of tremendous opportunity and I liked how you kind of brought it around to from a cultural perspective. It's got to start from that C-suite to Kieran's point all the way down. I know we could keep talking, we're out of time, but we'll have to keep following, this as a very interesting topic. One that is certainly pervasive across industries. Thanks guys for sharing your insights. >> Than you. >> Thank you, Lisa. >> Thank you, Lisa. >> For Kieran Taylor, Kevin Surace and Isaac Sacolick. I'm Lisa Martin. Thanks for watching. (upbeat music)

>> From around the globe it's the CUBE with digital coverage of Devops Virtual Forum, brought to you by Broadcom. >> Continuing our conversations here at Broadcom's DevOps Virtual Forum. Lisa Martin here, please do welcome back to the program. Serge Lucio, the general manager of the Enterprise Software Division at Broadcom. Hey Serge welcome. >> Thank you. Good to be here. >> So I know you were just participating with the BizOps manifesto that just happened recently. I just had the chance to talk with Jeffrey Hammond and he unlocked this really interesting concept but I wanted to get your thoughts on, spiritual co-location as really a necessity for BizOps to succeed in this unusual time in which we're living. What are your thoughts on spiritual co-location in terms of cultural change versus adoption of technologies? >> Yeah, it's quite interesting, right. When we think about the major impediments for DevOps implementation, that means all about culture, right? And swore over the last 20 years we've been talking about silos. We'd be talking about the paradox for these teams too when it goes to align. And in many ways it's not so much about these teams aligning but about being in the same car, in the same books, right? It's really about fusing those teams around kind of the common purpose, a common objective. So to me this is really about kind of changing this culture where people start to look at kind of OKRs instead of the key objective that drives the entire team. Now, what it means in practice is really that's we need to change a lot of behaviors, right? It's not about the ER key, it's not about roles. It's about, you know, who can do what and when, and, you know, driving a bias towards action. It's also means that we need, I mean, especially in this COVID times it becomes very difficult, right? To drive kind of a kind of collaboration and affinity between these teams. And so I think there's a significant role that especially tools can play in terms of providing this conference feedback from teams to be in that preface spiritual qualification. >> Well, and it talked about culture being it's something that, you know, we're so used to talking about DevOps with respect to velocity, all about speed here. But of course this time everything changed so quickly but going from the physical spaces to everybody being remote really does take. It's very different than you can't replicate it digitally but there are collaboration tools that can kind of really be essential to help that cultural shift, right? >> Yeah, so to me we tend to talk about collaboration in a very mundane way, right? Of course we can use zoom. We can all get into the same room. But the point when I think when Jeff says spiritual co-location, it's really about, we all share the same objective. Do we have a means for instance, our pipeline, right? When you talk about DevOps probably we all started thinking about this continuous delivery pipeline that basically drives the automation, the orchestration across the team. But just thinking about a pipeline, right? At the end of the day, it's all about what is the meantime to feed back to these teams. If I'm a developer and I commit code, how long does it take for, you know, that code to be processed through pipeline or quick and I get feedback? If I am a finance person, who's funding a product or a project, what is my meantime to beat back? And so a lot of, kind of a, when we think about the pipeline, I think what's been really inspiring to me in the last year or so is that there is much more of an adoption of that door effect metrics. There is way more of a focus around value stream management. And to me, this is really when we talk about collaboration it's really a balance. How do you provide that feedback to the different stakeholders across the life cycle in a very timely matter? And that's what we would need to get to in terms of kind of this notion of collaboration. It's not so much about people being in the same physical space. It's about, you know, when checking code, you know, to do I guess the system to automatically identify what I'm going to break. If I'm about to release some allocation, how can the system help me reduce my change builder rate? Because it's able to predict that some issue was introduced in the application or the product. So I think there's a great role of technology and AI candidates to actually provide kind of that new level of collaboration. >> So we'll get to AI in a second but I'm curious, what are some of the metrics you think that really matter right now is organizations are still in some form probably of transformation to this new almost 100% remote workforce. >> So I'll just say first I'm not a big fan of metrics. And the reason being that, you know, you can look at a change failure rate, right, or a leak time or cycle time. And those are interesting metrics, right? The trend on metric is absolutely critical. But what's more important these I'll do get to the root cause. What is taught to you lead to that metric to degrade or improve over time. And so I'm much more interested and we, you know, fruit for Broadcom. Are we more interested in understanding what are the patterns that contribute to this? So I'll use a very mundane example. You know, we know that cycle time is heavily influenced by organizational boundaries. So, you know, we talk a lot about silos, but we we've worked with many of our customers doing value stream mapping. And oftentimes what you see is that really the boundaries of your organization creates a lot of idle time, right? So to me, it's less about the metrics. I think the door metrics are pretty, you know, valid set metrics but what's way more important is to understand, what are the anti parents? What are the things that we can detect through the data that actually are affecting those metrics? And I mean, over the last 10, 20 years, we've learned a lot about kind of what are the anti parents within our large enterprise customers? And there are plenty of them. >> What are some of the things that you're seeing now with respect to patterns that have developed over the last seven to eight months? >> So I think the two areas which clearly are evolving very quickly are on kind of the front end of the life cycle where DevOps is more and more embracing value stream management, value stream mapping. And I think what's interesting is that in many ways, the product is becoming the new silo. The notion of a product is very difficult by itself to actually define. People are starting to recognize that a value stream is not its own little kind of island. That in reality, when I did find a product this product, oftentimes as dependencies on our products and that in fact, you're looking at kind of a network of value streams, if you will. So on that and there is clearly kind of a new sets if you will of anti-patterns where, you know, products are being defined as a set of OTRs. They have interdependencies and you have to have a new set of silos. On the other hand the other kind of key movement to ease around the SRE space, where I think there is a cultural clash. While the DevOps side is very much embracing this notion of OTRs and value stream mapping and value management. On the other end, you have IT operations teams. We still think business services, right? For them they think about configure items, think about infrastructure. And so, you know, it's not uncommon to see, you know, teams where, you know, the operations team is still thinking about hundreds of thousands, tens of thousands of business services. And so there is this boundary where I think, well, SRE has been put in place, and there's lots of thinking about what kind of metrics can be defined. I think, you know, going back to culture, I think there's a lot of cultural evolution that's still required for, you know, true operations teams. >> And that's a hard thing. Cultural transformation in any industry pandemic or not is a challenging thing. You now talked about AI and automation of minutes ago. How do you think those technologies can be leveraged by DevOps leaders to influence their successes and their ability to collaborate and maybe see eye to eye with the SREs? >> Yeah, so there're kind of too, so even for myself, right? As a leader of , you know, 1500 people organization, there's a number of things I don't see, right, on a daily basis. And I think the technologies that we have at our disposal today from the AI are able to mine a lot of data and expose a lot of issues that as leaders we may not be aware of. And some of these are pretty kind of easy to understand, right? We all think we're agile. And yet when you start to understand, for instance, what is the is a work in progress, right, during the sprint? When you start to analyze the data you can detect for instance, that maybe the teams are over committed, that there is too much work in profits. You can start to identify kind of interprocess either from a technology or from a people point of view, which were hidden. You can start to understand that maybe the change failure rate is dragging. So I believe that there is a fundamental role to be played by the tools to expose again these anti parents. To make these things visible to the teams to be able to even compare teams, right? One of the things that's amazing is now we have access to tons of data not just from a given customer, but across a large number of customers. And so we start to compare all of these teams kind of operate and what's working, what's not working. >> Thoughts on AI and automation as a facilitator of spiritual co-location? >> Yeah, absolutely. It's, you know, there's a the problem we all face is the unknown, right? The velocity, the volume, variety of the data, every day we don't really necessarily completely appreciate what is the impact of our actions, right? And so AI can really act as a safety net that enables us to understand what is the impact of our actions. And so, yeah, in many ways, the ability to be informed in a timely matter to be able to interact with people on the basis of data and collaborate on the data in the actual matter, I think is a very powerful enabler on, in that respect. I mean, I've seen countless of times that for instance at the SRE boundary to basically show that we'll turn the quality attributes of an incoming release, right? And exposing that to an operations person, an SRE person and enabling that collaboration dialogue through there is a very, very powerful tool. >> Do you have any recommendations for how teams can use, you know, the SRE folks, the DevOps says can use AI and automation in the right ways to be successful rather than some ways that aren't going to be non-productive. >> Yeah, so to me there's a part that the question really is when we talk about data. There are different ways you can use data, right? So you can do a lot of analytics, predictive analytics. So I think there is a tendency to look at, let's say a specific KPI, like an availability KPI or change failure rate. And to basically do a regression analysis and projecting all these things is going to happen in the future. To me that's a bad approach. The reason why I fundamentally think it's a better approach is because we, our systems the way we develop software is a non-leader kind of system, right? Software development is not linear in nature. And so I think there's a, this is probably the worst approach is to actually focus on metrics. On the other hand if you start to actually understand at a more granular level, what are the things which are contributing to this, right? So if you start to understand, for instance that whenever maybe, you know, you affect a specific part of the application that translates into production issues. So we have, I've actually a customer who identified that over 50% of their unplanned outages were related to specific components in your architecture. And whenever these components were changed this resulted in this implant outages. So if you start to be able to basically establish causality, right? Cause an effect between kind of data across the last cycle. I think this is the right way to use AI. And so pharma to be, I think it's way more about kind of a classification problem. What are the causes of problems that do exist and affect things as opposed to an hourly predictive which I don't think is as powerful? >> So I mentioned in the beginning of our conversation that just came off the BizOps manifesto. You're one of the authors of that. I want to get your thoughts on DevOps and BizOps overlapping, complimenting each other. What, from the BizOps perspective, what does it mean to the future of DevOps? >> Yeah, so it's interesting, right? If you think about DevOps, there's no founding document, right? We can refer to the Phoenix project. I mean, there are a set of documents which have been written, but in many ways there is no clear definition of what DevOps is. If you go to the DevOps Institute today you'll see that, you know, they are specific trainings for instance on value management on SRE. And so in many ways, the problem we have as an industry is that there are set practices between agile, DevOps, SRE, value stream management, Ital, right? And we all basically talk about the same things, right? We all talk about essentially accelerating in the meantime to feedback, but yet we don't have a common framework to talk about that. The other key thing is that we add to wait for genius, Jean Kim's last book to really start to get into the business aspect, right? And for value mapping to start to emerge for us to start as an industry, right? IT to start to think about what is our connection with the business aspect, what's our purpose, right? And ultimately it's all about kind of driving these business outcomes. And so to me, BizOps is really about kind of putting a lens on kind of this critical element that it's not business and IT that we in fact need to fuse business and IT. That I need needs to transform itself to recognize that it's this value generator, right? It's not a cost center. And so the relationship to me, it's more than BizOps provides kind of this over all kind of framework, if you will. That set the context for what is the reason for IT to exist. What are the core values and principles that IT needs to embrace to, again, change from cost center to value center. And then we need to start to use this as a way to start to unify some of, again, the core practices, whether it's agile, DevOps, value stream mapping, SRE. So, I think over time, my hope is that we start to organize a lot of our practices, language and cultural elements. >> Last question Serge in the last few seconds we have here, talking about this, the relation between BizOps and DevOps. What do you think as DevOps evolves? And as you talked to circle some of your insights, what should our audience keep their eyes on in the next six to 12 months? >> So to me the key challenge for the industry is really around. So we were seeing a very rapid shift towards kind of project to product, right? Which we don't want to do is to recreate kind of these new silos, these hard silos. So that's one of the big changes that I think we need to be really careful about. Because it is ultimately, it is about culture. It's not about kind of how we segment the work, right? And any true culture that we can overcome kind of silos. So back to, I guess, with Jeffrey's concept of kind of the spiritual co-location, I think it's really about that too. It's really about kind of focusing on the business outcomes on kind of aligning, on driving engagement across the teams, but not for create kind of a new set of silos which instead of being vertical are going to be these horizontal products. >> Great advice Serge that looking at culture as kind of a way of really addressing and helping to reduce, replace challenges. We thank you so much for sharing your insights and your time at today's DevOps Virtual Forum. >> Thank you. Thanks for your time. Serge Lucio, Lisa Martin, we'll be right back. (upbeat music)

>> Announcer: 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 CIO at Forrester. We've also got Serge Lucio, the GM of Broadcom Enterprise Software Division. And Glyn Martin, the head of QA Transformation at BT. Guys welcome back. Great to have you all three together. >> Hi Lisa. (Serge speaks faintly) >> Good to be here. >> All right. So we're all very socially distanced as we 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 colocation. 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 Glyn, 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 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 challenge is 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. There's a Surgeon I worked together a long, long time ago, so just it's been what, almost 15-16 years, since we worked at the same place. And yet I would say there's probably still a certain level of spiritual colocation, between us. because of this 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.(chuckles) >> 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 of colocation. The cultural impact and how technology can move it forward? >> Yes, so I think, while I'm going to sound very similar to Jeff in that respect. I think it starts with kind of shared purpose, and understanding how individuals teams contribute to kind of a business outcome. What is our shared goals our shared vision with what is it we're trying to achieve collectively. And keeping kind of the line to that. And so it really starts with it Now, the big challenge always is over the last 20 years, especially in large organization has been specialization of roles and functions. And so we all have started to basically measure which we do on a daily basis using metrics, which oftentimes are completely disconnected from kind of a business outcome. Or is it on purpose. We kind of revert that to Okay, what is my database uptime? What is my cycle time? Right. And I think which 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 benefiting this business outcomes. So, probably one of my theories experience was to actually witness at one of our large financial institution. Two stakeholders across development and operations staring at the same data. Like which was related to economy changes, test execution results, coverage, official liabilities, and all the overran direction of 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 they can start to basically communicate, and understand how they jointly or complement to do that kind of common vision or objective. >> And Glyn, we talked a lot about transformation with you last time. What are your thoughts on spiritual colocation and the cultural part of 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 we would constantly found that with our continuing relationship with Broadcom. What it also does, are those 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 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, depending on what area BT you're in. Whether it's consumer, whether it's a mobile area, whether it's large global or government organizations. We 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 it's a from a number of different aspects. That you have the right partner, and to drive the right culture here, and 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 a quite a bit of a buzz phrase. And they're kind of testing well at the moment. But I could talk about things like Continuous Delivery Director to Broadcom 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 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 of have much more intuitive and insightful conversations with other teams and reduce those organizational silos. >> Thanks, Glyn So we kind of sum that up autonomy, collaboration tools that facilitate that. So let's talk now about metrics. From your perspective, what are the metrics that matter Jeff? >> Well, I'm going to go right back to what Glyn said about data that provides visibility that enables us to to make decisions with shared purpose. And so business value has to be one of the first things that we looking at. How do we assess whether we have built something that is valuable? 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. 'Cause 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, 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 defects found in pre production. And their developers were in fact measured on that ratio and told them that guess what quality is your job too. Not just the test departments 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 how full was the parking lot at 9, and how full was it at 5 o'clock. I can't do that anymore, since we're not physically colocated. But what you can do is you can look at how folks are delivering. You can look at your metrics in your SCCM 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 going to 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. Glyn 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? >> I mean, Jeff provided some great advice. Actually, he talks about value, he talks about flow, both of those things are very much on my mind at the moment. But there was a time, listen to a speaker called Mia Kirsten, a couple of months ago, he talked very much around how important flow management is. And remove 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 waterfall to agile. And the problem with moving from waterfall to agile is, with waterfall, the 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 you know, if we're doing things quick, and we're getting stuff out 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, in an investment setting up agile teams training agile teams. Are we actually seeing them deliver more quickly? And are we actually seeing them deliver more value quickly? So yeah, those are the two main things for me at the moment. But I think it's also about, generally bringing it all together DevOps. We've got the kind of value ops, AI Ops. How do we actually bring that together to so we can make quick decisions, and making sure that we are delivering the biggest bang for our partners. >> Absolutely biggest bang for the partners. Serge your thoughts. >> Yes I think we all agree, right? It starts with business metrics, flow metrics. These are one of the most important metrics and ultimately, I mean, one of the things that's very common across I highly functional teams is engagements, right? When you see a team that's highly functional, and that's agile, that practices DevOps everyday. They are highly engaged. That definitely true. Now back to you, I think, Jeff's points on weaponization of metrics. One of the key challenges we see is that organizations traditionally have been kind of, setting up benchmarks. Right. So what is a good cycle time? What is a good mean time? What is a good mean time to repair? The problem is that this is very contextual, right? It's going to vary quite a bit, depending on the nature of 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 is about are 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 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 I 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 that there is reviewing the metrics, there is I think a lot of work that we need to do in terms of classifying this untied PaaS. 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-patterns. >> Yeah >> But Water Scrum Fall, right. Is the key one right? And you will detect that through kind of a defect rival rates. That's right, that looks like an S curve. And so I think it's the output 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 had been in industry for a long time, we know the anti patterns, 'cause we've seen them in our career,(laughs) 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. 'Cause as a manager that maybe only a 10 year veteran or a 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.(chuckles) >> That would right? Insight, always helpful. All right guys, I would like to get your final thoughts on the fit one thing that you believe our audience really needs to be on the lookout for. and to put on our agendas. For the next 12 months. Jeff will be 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 central 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. Glyn where do we go from there? What's the one silver bullet that you think that needs to be on the look out for? >> (indistinct) out I certainly agree that low code is next year, we'll see much more low code. We've already started going moving towards more of a SaaS based world but low code also. I think as well for me, we've still got one foot in the kind of cloud 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 kind of the life cycle When I heard the word scrum for it kind of made me shut it. 'Cause 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 expect to see much more of that next year. Yeah, thank you. I haven't got any food analogies unfortunately. (laughs) >> We all need some peanut butter and chocolate. All right Serge, Just take us on that sir. What's that nugget you think everyone needs to have on their agendas? >> That's interesting, right? So a couple of days ago, we had kind of a latest state of the 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 this spiritual colocation 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 tie 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 into allowing everything they do from a metrics to delivery to flow to those metrics. And only with data, I think, are we going to be able to actually start to to restart to align kind of all these roles across the 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 colocate with us today. Guys, thank you. >> Thank you Lisa. >> Thank you. >> Thank you. >> For Jeff Hammond, Serge Lucio and Glyn Martin. I'm Lisa Martin. Thank you for watching the Broadcom DevOps virtual forum. (upbeat music)