 From around the globe, it's theCUBE with digital coverage of BizOps Manifesto Unveiled brought to you by BizOps Coalition. Hey, welcome back everybody. Jeff Frick here with theCUBE. We're coming to you from our Palo Alto studios and welcome back to this event is the BizOps Manifesto Unveiling. So the BizOps Manifesto and the BizOps Coalition have been around for a little while, but today's the big day that's kind of the big public unveiling and we're excited to have some of the foundational people put their name on the dotted line, if you will, to support this initiative and talk about why that initiative is so important. And so the next guest we're excited to have is Dr. Mick Kirsten. He is the founder and CEO of Tasktop. Mick, great to see you. Coming in from Vancouver, Canada, I think, right? Yes, great to be here, Jeff. Thank you. Absolutely. I hope your air's a little better out there. I know you had some of the worst air of all of us a couple of weeks back. So hopefully things are getting a little better and we get those fires under control. Yeah, things have cleared up now. So yeah, it's good to be close to the US and it's good to have the air a bit cleaner as well. Absolutely. So let's jump into it. So you've been an innovation guy forever, starting way back in the day in Xerox PARC. I was so excited to do an event at Xerox PARC for the first time last year. I mean, that to me represents, along with Bell Labs and some other kind of foundational innovation and technology centers. That's got to be one of the greatest ones. So I just wonder if you could share some perspective of getting your start there at Xerox PARC. Some of the lessons you learned and what you've been able to kind of carry forward from those days. Yeah, I was fortunate to join Xerox PARC in the Computer Science Lab there at a very early point in my career and to be working on open source programming languages. So back then in the Computer Science Lab where some of the inventions around programming around software development came such as object-oriented programming and a lot of what we had around really modern programming languages constructs. Those were the teams I had the fortune of working with. And really our goal was, and of course there's as you noticed there's just this DNA of innovation and excitement and innovation in the water. And really it was the model that comes all around changing the way that we work was looking at for how we could make it 10 times easier to write code. Like this is back in 99 and we were looking at new ways of expressing especially business concerns, especially ways of enabling people who are who want to innovate for their business to express those concerns in code and make that 10 times easier than what that would take. So we created a new open source programming language and we saw some benefits but not quite what we expected. I then went and actually joined Charles Stimley the former chief director of Microsoft who was responsible, he actually got Microsoft Word as out of Xerox PARC and into Microsoft and into the hands of Bill Gates and that company I was behind the whole office suite and his vision and the one I was trying to execute with him working for him was to make PowerPoint be like programming language, make everything completely visual. And I realized none of this was really working that there was something else fundamentally wrong that programming languages or new ways of building software like let us try and do with Charles around intentional programming, that was not enough. That was not enough. So the agile movement got started about 20 years ago and we've seen the rise of DevOps and really this kind of embracing of sprints and getting away from MRDs and PRDs and these massive definitions of what we're going to build and long build cycles to this iterative process. And that's been going on for a little while. So what was still wrong? What was still missing? Why the BizOps coalition? Why the BizOps manifesto? Yeah, so I basically think we nailed some of the things at the programming language level. So teams can have effective languages deployed to software to the cloud easily now, right? And at the kind of process and collaboration and planning level agile two decades ago was formed. We were adopting all the teams I was involved with and it's really become a solved problem. So agile tools, agile teams, agile ways of planning are now very mature. And the whole challenges when organizations try to scale that. And so what I realized is that the way that agile was scaling across teams and really scaling from the technology part of the organization to the business was just completely flawed. The agile teams had one set of doing things, one set of metrics, one set of tools and the way that the business was working was planning, was investing in technology was just completely disconnected and using a whole different set of measures. It's pretty interesting because I think it's pretty clear from the software development teams in terms of what they're trying to deliver because they've got a feature set, right? And they've got bugs and it's easy to see what they deliver. But it sounds like what you're really honing in on is this disconnect on the business side in terms of, you know, is it the right investment? You know, are we getting the right business ROI on this investment? Was that the right feature? Should we be building another feature? Or should we be building a completely different product set? So it sounds like it's really a core piece of this is to get the right measurement tools, the right measurement data sets so that you can make the right decisions in terms of what you're investing, you know, limited resources. You can't, nobody has unlimited resources and ultimately you have to decide what to do which means you're also deciding what not to do. It sounds like that's a really big piece of this whole effort. Yeah, Jeff, that's exactly it. Which is the way that the agile team measures their own way of working is very different from the way that you measure business outcomes. The business outcomes are in terms of how happy your customers are, right? Are you innovating fast enough to keep up with the pace of a rapidly changing economy, a rapidly changing market? And those are all around the customer. And so what I learned on this long journey of supporting many organizations transformations and having them try to apply those kinds of agile and devops, is that those are not enough. Those measure technical practices, those measure sort of the technical excellence of bringing code to the market. We don't actually measure business outcomes. And so I realized it really was much more around having these end-to-end flow metrics that are customer-centric and business-centric and market-centric where we needed to go. Right. So I want to shift gears a little bit and talk about your book because you're also a best-selling author for a project, a product. And you brought up this concept in your book called the Flow Framework. And it's really interesting to me because I know flow on one hand is kind of a workflow and a process flow and that's how things get done and embrace the flow. On the other hand, everyone now in a little higher level, existential way is trying to get into the flow, into the workflow and not be interrupted and get into a state where you're kind of at your highest productivity, kind of your highest comfort. Which flow are you talking about in your book or is it a little bit of both? That's a great question. It's not one I get asked very often because to me it's absolutely both. So the thing that we want to get to, we've learned how to master individual flow that there's this beautiful book by Mihaly, teachings Mihaly, there's a beautiful Ted talk by him as well about how we can take control of our own flow. So my question with the book, with Project for Prize, how can we bring that to entire teams and really entire organizations? How can we have everyone contributing to a customer outcome? And this is really what, if you're the biz off, manifest the wits, is a focus on outcomes, on using data to drive whether we're delivering those outcomes rather than a focus on proxy metrics such as how quickly did we implement this feature? No, it's really how much value did the customer get out of the feature and how quickly did we learn and how quickly did we use that data to drive to that next outcome. Really the companies like Netflix and like Amazon have mastered, how do we get that to every large organization, every IT organization and make everyone be a software innovator? So it's to bring that concept of flow to these end-to-end value streams. And the fascinating thing is we've actually seen the data. We've been able to study a lot of value streams. We see when flow increases, when organizations deliver value to a customer faster, developers actually become more happy. So things like they're inflating up for more scores rise and we've got empirical data for this. So the beautiful thing to me is that we've actually been able to combine these two things and see the results in the data that you increase flow to the customer, your developers are more happy. I love it, I love it, right? Because we're all happier when we're in the flow and we're all more productive when we're in the flow. So that is a great melding of two concepts. But let's jump into the manifesto itself a little bit and I love that it took this approach really of having kind of four key values and I think it's 12 key principles. And I just want to read a couple of these values because when you read them, it sounds pretty brain dead, right? Of course, right? Of course you should focus on business outcomes. Of course you should have trust and collaboration. Of course you should have database decision-making processes and not just intuition or whoever's the loudest person in the room and to learn and respond and pivot. But what's the value of actually just putting them on a piece of paper? Because again, this is not, these are all good positive things, right? When somebody reads these to you or tells you these or sticks it on the wall, of course. But unfortunately, of course, isn't always enough. No, and I think what's happened is some of these core principles originally from the agile manifesto two decades ago, the whole DevOps movement of the last decade of flow, feedback and continual learning has been key. But a lot of organizations, especially the ones undergoing digital transformations have actually gone a very different way, right? The way that they measure value in technology and innovation is through costs. For many organizations, the way that they actually are looking at their moving to cloud is actually as a reduction in cost. Whereas the right way of looking at moving to cloud is how much more quickly can we get to the value to the customer? How quickly can we learn from that? And how quickly can we drive them next business outcome? So really the key thing is to move away from those old ways of doing things, of funding projects and cost centers to actually funding and investing in outcomes and measuring outcomes through these flow metrics, which in the end are your fast feedback group for how quickly you're innovating for your customer. So these things do seem very obvious when you look at them, but the key thing is what you need to stop doing to focus on these. You need to actually have accurate real-time data of how much value you fund to the customer every week, every month, every quarter. And if you don't have that, your decisions are not driven on data. If you don't know where your bottom like is, and this is something that in the decades of manufacturing, car manufacturers, other manufacturers master, they always know where the bottleneck in their production process is. You ask a random CIO and a global 500 company where their bottleneck is and you won't get their answer because there's not that level of understanding. So to actually follow these principles, you need to know exactly where your bottleneck is because that's what's making your developers miserable and frustrated and having them context switch on trash. So the approach here is important and we have to stop doing these other things. There's so much there to unpack. I love it, especially the cloud conversation because so many people look at it wrong as a cost-saving device as opposed to an innovation driver and they get stuck in the literal and I think of the same thing always about Moore's Law. There's a lot of interesting real tech around Moore's Law and the increasing power of microprocessors, but the real power I think in Moore's Law is the attitudinal change in terms of working in a world where you know that you've got all this power and what will you build and design? I think it's funny too, your comment on the flow and the bottleneck, right, because we know manufacturing, as soon as you fix one bottleneck, you move to your next one, right? You always move to your next point of failure. So if you're not fixing those things, you're not increasing that speed down the line unless you can identify where that bottleneck is or no matter how many improvements you make to the rest of the process, it's still going to get hung up on that one spot. That's exactly it. And you also make it sound so simple, but again, if you don't have the data-driven visibility of where that bottleneck is, and these bottlenecks are just as you say, if it's just whack-a-mole, right? So we need to understand, is the bottleneck because our security reviews are taking too long and stopping us from getting value to the customer? If it's that, automate that process and then you move on to the next bottleneck, which might actually be that deploying yourself into the cloud is taking too long. But if you don't take that approach of going flow first, rather than, again, the cost reduction first, if you don't take an approach of customer centricity and you only focus on optimizing costs, your cost will increase and your flow will slow down. And this is just one of these fascinating things where if you focus on getting value to the customer and reducing your cycles on getting value, your flow time from six months to two weeks or to one week or to a day, as we see with tech giants, you actually can both lower your costs and get much more value. And of course, get that learning loop going. So I think I've seen all these cloud deployments and modernizations happen that delivered almost no value because there was such big bottlenecks upfront in the process and actually the hosting and the AP testing was not even possible with all of those inefficiencies. So that's why going flow first, rather than costs first or project versus so key. I love that. And it begs repeating too that, right, within a subscription economy, you know, you're on the hook to deliver value every single month because they're paying you every single month. So if you're not on top of how you're delivering value, you're going to get sideways because it's not like, you know, they pay a big down payment and a small maintenance fee every month. But once you're in a subscription relationship, you know, you have to constantly be delivering value and upgrading that value because you're constantly taking money from the customer. So it's such a different kind of a relationship than kind of the classic, you know, big bang with the maintenance agreement on the backend. Really important. Yeah. And I think in terms of industry shift, that's it. That's what's catalyzed this industry shift is in this SaaS and subscription economy. If you're not delivering more and more value to your customers, someone else is and they're winning the business, not you. So one way we know is to delight our customers with great user experiences. Well, that really is based on how many features you delivered or how many quality improvements or scale or performance improvements you delivered. So the problem is, and this is what the business manifesto as well as the flow framework touch on is if you can't measure how much value you deliver to a customer, what are you measuring? You're just back to, again, measuring costs and that's not a measure of value. So we have to shift quickly away from measuring cost to measuring value to survive in the subscription economy. Mick, we could go for days and days and days. I want to shift gears a little bit into data and a data-driven decision-making, a data-driven organization. Because data's been talked about for a long time, the huge big data meme with Hadoop over several years and data warehouses and data lakes and data oceans and data swamps and you can go on and on and on. It's not that easy to do, right? And at the same time, the proliferation of data is growing exponentially. We're just around the corner from IoT and 5G, so now the accumulation of data at machine scale, again, is just going to overwhelm. And one of the really interesting principles that I wanted to call out and get your take, right, is today's organizations generate more data than humans can process, so informed decisions must be augmented by machine learning and artificial intelligence. I wonder if you can, again, you've got some great historical perspective, reflect on how hard it is to get the right data to get the data in the right context and then to deliver it to the decision makers and then trust the decision makers to actually make the data and move that down, you know, as kind of this democratization process into more and more people and more and more frontline jobs making more and more of these little decisions every day. Yeah, and Jeff, I think the front parts of what you said are where the promises of big data have completely fallen on their face into these swamps, as you mentioned, because if you don't have the data in the right format, you've connected that they're like, well, you've not modeled that way the right way, you can't use human or machine learning effectively. And there've been the number of data warehouses in a tip point of price organization and the sheer investment is tremendous, but the amount of intelligence being extracted from those is a very big problem. So the key thing that I've noticed is that if you can model your value streams, so you actually understand how you're innovating, how you're measuring the delivery value and how long that takes, what is your time to value through these metrics like flow of time, you can actually use both the intelligence that you've got around the table and push that down as far as you can to the organization, but you can actually start using those models to understand and find patterns and detect bottlenecks that might be surprising, right? Well, you can detect interesting bottlenecks when you shift to work from home. We detected all sorts of interesting bottlenecks in our own organization that were not intuitive to me, that had to do with more senior people being overloaded and creating bottlenecks where they didn't exist, whereas we thought we were actually an organization that was very good at working from home because of our open source routes. So the data is highly complex, software value streams are extremely complicated and the only way to really get the proper analysts and data is to model it properly and then to leverage these machine learning and AI techniques that we have. But that front part of what you said is where organizations are just extremely immature in what I've seen, where they've got data from all their tools but not modeled in the right way. Right, right. Well, all right, so before I let you go, say you get a business leader, he buys in, he reads the manifesto, he signs on the dotted line, he says, Mick, how do I get started? I want to be more aligned with the development teams. You know, I'm in a very competitive space, we need to be putting out new software features and engaging with our customers. I want to be more data-driven. How do I get started? Well, you know, what's the biggest inhibitor for most people to get started and get some early wins, which we know is always the key to success in any kind of a new initiative? Right, so I think you can reach out to us through the website on the business manifesto, but the key thing is just to get started and to get the key wins. So take a product value stream that's mission critical. It could be your new mobile or web experiences or part of your cloud modernization platform or your analytics pipeline, but take that and actually apply these principles to it and measure the end-to-end flow of value. Make sure you have the value metric that everyone is on the same page on. The people on the development teams, the people in leadership are all the way up to the CEO and one of the, where I encourage you to start is actually that end-to-end flow time, right? That is the number one metric. That is how you measure whether you're getting the benefit of your cloud modernization. That is the one metric that Aiden Cockroft, one of the people I respect tremendously, put into his cloud for CEOs metric, the one way to measure innovation. So basically take these principles, deploy them on one product value stream, measure end-to-end flow time and then you'll actually be on your path to transforming and to applying the concepts of agile and DevOps all the way to the business, to the way in your operating model. Well, Mick, really great tips, really fun to catch up. I look forward to a time when we can actually sit across the table and get into this because I just love the perspective and you're very fortunate to have that foundational base coming from Xerox PARC. I think it's a very magical place with a magical history. So to incorporate that and to continue to spread that well, good for you through the book and through your company. So thanks for sharing your insight with us today. Thanks so much for having me, Jeff. Absolutely, all right. And go to the bizopsmanifesto.org, read it, check it out. If you want to sign it, sign it. They'd love to have you do it. Stay with us for continuing coverage of the unveiling of the business manifesto on theCUBE. I'm Jeff Brick. Thanks for watching. See you next time.