 From the SiliconANGLE Media office in Boston, Massachusetts, it's theCUBE. Now, here's your host, Stu Miniman. Hi, and welcome to a special presentation of theCUBE here from our East Coast Studio, and happy to have joining with me Bob Ellis. Bob is the founder and chief consultant of Analyze, Innovate, and Transform. Bob, before I want to have you introduce yourself, but for our audience, we've been talking a lot about kind of digital transformation, and there's so many things that go into that, everything from, you know, kind of mobile, how things like cloud, you know, I tend to focus a lot on kind of the infrastructure and cloud pieces out of it, so very much some of the tool set. But I think with you, we're also going to be talking about kind of the organizational, the processes, the mindset, some of those great organizational pieces, which, you know, I like too, but why don't you introduce yourself to our audience, you know, your background and what you do today? Sure, Stu, thank you very much. So yeah, like many of us in the industry, engineering, background, and management science, degree MS from MIT, and the discussion here is really about enterprise agility, and there's a third leg of innovation. The third leg of innovation that I'd like to talk about is as we all know, the technology innovation is phenomenal in the industry, there's tremendous technology innovation, there's amazing product innovation, there's new products coming out all the time, there's product innovation is also amazing. I will claim that the third frontier of management and our industry and sustainability of larger corporations is really management innovation, and that's what I want to talk about today. So Bob, you're a consultant today. And can you talk about, you know, what is the typical company you're dealing with? Is this something, you know, is it startups? Is it, you know, global enterprises? You know, what's the client? Sure, sure, that's a very good question, Stu. Typically what happens, the startups are all six, well, many of them are successful, right? They have the innovators, lots of innovation going on, it's typically a small group of people. Communication is very clean. As companies grow, they tend to get larger, more people, more communication challenges, there's specialties within those organizations, and when you start looking at workflow through these companies and through the systems, and the workflow is really the value flow, they tend to get constrained through that management system, and that really is what enterprise agility is about, is understanding what that system is, innovating in that space, and accelerating that value flow through the system so those companies can remain competitive. Yeah, that's definitely a huge thing we've been hearing for many years now. I mean, agility is really what we're talking about, being able to react faster, and being able to understand it. How, you know, IT for the longest time has been, you know, it was a cost center, it was, you know, the group that would tell you no, or, you know, slow roll things, so how much of this is kind of IT focus, how much of it is kind of a broader, you know, company development? Great, so it's interesting, agility, agile, scrum, these terms have kind of grown up around the world of IT and software product development. They actually apply to all value streams of a company. You can be in weather forecasting and try to figure out how to get your weather forecast out faster or depending on what your, what value it is that your company is delivering to your people, to the customers. And so it's really the value stream that matters and the responsiveness really comes down to how fast can you move from an idea or a concept to the value delivered to the customer and adopted. So it may include, like you mentioned CICD, you mentioned DevOps, there's, it's about getting that value to the customer and deployed to the customer so that they can actually be using that value and ultimately paying for that value, assuming that you're, whatever you're providing is something you're charging. Yeah, so Bob, like yourself, I've got an engineering background. I remember back in undergrad, you know, you talk about the manufacturing revolution. So, what, just in time, and Lean talked about taking inefficiency out of the system and being able to kind of meet the customers, you know, at the time they need it, when they need it, it sounds a lot like what we're talking about, from a technology standpoint. Exactly, so I've been in industry for many decades and my first work out of business school, I got into management consulting and the consulting then was really the manufacturing systems and you would go into these companies and it would be about over the wall into manufacturing and it's interesting because the software and the agility in software and Scrum and Waterfall and comparing Waterfall, for example, to the Agil and Scrum processes, it's no longer about Dev handing over the wall or to a different organization to test and then another one over the wall to the release people that are doing stabilization tests. The idea is that the Scrum cycles, the iterations or sprints are, all of that is done in every two week period or every one week period. So, the idea is you have potentially shippable product at the end of every iteration and so with that you get a lot of feedback into your system which allows you to be agile in terms of addressing new markets and new needs. You might discover new technology things that need to be done. There may be improvements in the process that are revealed and the whole idea is these feedback loops and the PDCA give the teams that have been working on these things if they analyze and understand those they can improve what they're delivering and so you can actually get faster value delivery to your customer. You can get more on target to your customers. You can, the results of experiencing these systems is phenomenal between when you're going from a six month waterfall process where there might be some feedback in that system but the really crisp feedback of working softer to customers to getting demonstration in terms of exactly how it's working. The feedback cycles in an agile system are much, there are just many, many more of them and so the system becomes much more responsive. Absolutely, you mentioned the feedback cycles. We've definitely been hearing when I can change those cycle times if the feedback loops help me whether I'm talking about data and how I interact with my customers or just internally how when I'm setting goals you don't just set a yearly goal and go do it anymore you've got to be a little bit tighter on there. Can you talk about some of the kind of the optimizations how customers determine where they make the optimizations whether that's very fine grained, very broad grained. How does that happen? Very interesting. So there's a lot of frameworks out in industry. There's a Scrum framework which a lot of people have heard about. There's some scaling frameworks that are out there and there are multiple different frameworks. The bottom line is every company is a unique value stream that is delivering and through understanding what that value stream is and also the culture of the business because when you're changing the way that people are doing work you're really affecting, you're touching the culture of the organization and the intrinsic motivators of the people because people may be super specialized, super expert in one area and then you're asking them for example to work instead of as an individual maybe you're asking them to work as a team and the team has deliverables within this iteration that include development and test and stabilization and so some of the ideas that the team is working together and the people are helping each other on that team to meet the team deliverables and so it does affect the intrinsic motivators and through innovation and helping the organizations and the people understand what those intrinsic motivators are and to broaden their intrinsic motivators even so that instead of just having a very tight area of expertise for example they encourage them to be innovators and innovate outside of your box and get the people to really innovate and get fulfillment through innovation even beyond their area of expertise and once that becomes an intrinsic motivator and then the culture starts changing and then the organization can change and ultimately we wanna get these organizations to a mindset where it's not just a new process that they're delivering against but the business being all of the people in that organization are really conscious and cognizant of the workflow or the value flow through the system and how can the organization accelerate that value flow through the system and it can be all sorts of different impediments that are slowing that system down and Stu brought up earlier like DevOps for example is traditionally a big friction point in terms of delivering software where you see some companies like Google and Facebooks that are deploying every day to customers you know how do these other companies that are on these release schedules that may be every quarter or every six months they're releasing and how can we accelerate through that release cycle so that we can have faster and faster releases and so it's all understanding that system innovating, trying things, having an organization that gives you the opportunity to try these things if they're not good ideas you fail fast on them and you move back and the idea is to leverage every person in those organizations so that the organization can move fast. So that's really interesting because God I think from a manufacturing standpoint it seems like people were just another piece of the equation. I think back when and I took some Six Sigma classes and it was just like let's take variants out of there and let's get everything more efficient but understanding motivation is critical. Simon Sinek did a video recently that kind of been all over the web talking about millennials and they said they will trade off being part of something bigger and helping the cause as opposed to just purely from a monetary standpoint. So does your consultancy, do you help companies? How are they at kind of understanding and motivating people? I mean we know for the longest time only 20% of employees are fully engaged and interested in their work. Most people kind of show up, punch the clock, automation and other things are all just making it less and less likely that you're going to want to be engaged in the work. Yeah we're really, so the models, the frameworks absolutely support self-organizing, self-managing teams and all of that has to do with the motivators. Understanding what those motivators are collectively having that joint respect across the individuals within that team and there are different roles within that team by the way. They're in the scrum framework for example there's the product owner who owns the business decisions so they're really deciding what is the priority of doing the work that's in the backlog. The team of typically developers and testers, those are the technical experts and so that's a second role and that team essentially defines the work. They clarify, they negotiate the definition of the work with the product owner and then they decide how much work they can do in that iteration and then they figure out amongst themselves and mostly technology innovation in terms of how to actually deliver that work to the definition of done by the end of the iteration. And so, and then the scrum master typically is really the orchestrator or the facilitator. They're not a manager, right? They're more of a leader or in some terminology servant leader where the idea is that you're enabling that team to execute and deliver that value, identify and remove impediments from the system and help that team execute against its mission. And so that triumvirate allows the team to operate very effectively because we know exactly where the authority is for certain decisions. What kind of trainings involved in this? Most of the terms you throw out there is, I got a bachelor's in engineering, I got my MBA, it's a little bit dated on some of this, but boy, that's not the things that today's workforce is trained for. So how do they get involved? Maybe talk about the on ramp and how do you scale an organization with this? That's great, those are good questions as well. Training, there is definitely different terminology and as long as people have a common terminology, it's easier for that organization to make shifts into the new space. There's the concepts like John Little of MIT introduced to industry really in systems manufacturing and then systems is lean and how much work really in process affects how responsive the system, how fast can you get that work through the system depends on how much work is in that system. And if you can reduce how much work is in that system, you can actually produce that work more quickly and then replan the next iteration and you can be more responsive to the marketplace. So there's a lot of, I'll call it theory, there's a lot of practice, there's a lot of just basic terminology that needs to be agreed upon so that everybody can communicate and execute as effectively as possible and also continue to make improvements. Because ultimately where we want to get the organizations from a consulting standpoint is to adopt the mindset of continuous improvement in everybody in that mindset. So everybody can contribute ideas and improve how the system will work. Now with that said, sometimes there are centralized decisions that are more efficient than distributed decisions. And so when that is recognized, then the teams need to agree and follow suit that yes, this is a centralized decision and we're gonna follow suit on that. One example that might be the start and end day of an iteration because you want your teams to execute together. All right, Bob, let's talk about what are the metrics? What comes out of this? Company goes through it. What can they start saying? They're more profitable, they're more competitive. What are kind of the hero numbers that they come out of this with? Sure, absolutely. So some of the primary metrics, I'm glad you asked that question because having the manufacturing back, I've been all about metrics my whole life, right? So you have predictability, really important for big companies that have planned releases that are every six months or so. We all know what it is, if we miss a GA date, we do not want to miss a GA date. Part of that predictability is also delivering against the features that we're committed to in the plan. So you want to always be delivering against your highest value features and against whatever your committed plan is, which is n minus x months before your delivery. As your release cycle gets shorter and shorter, your predictability actually becomes less important because you just have a constant flow of releases and flow of value to your customers. So that particular measure actually changes over time, but it does consciously, it's a function of how quickly you can release your cadence to release to your customers. So another one is productivity. So productivity is a very interesting one because if you look at these frameworks on the surface, it's like, okay, where's my productivity going to come from, right? So there are organizational behavior theories that are implemented in many of these practices. And for example, there's a daily standup meeting, which a lot of these teams, when they're first starting Scrum, they don't really understand the benefit of having a daily standup. They think this is a status meeting. What that meeting is really about is it's maximizing the communication bandwidth between the developers and testers so that they can collaborate and figure out how to deliver their work item, which is typically a total effort of one or two days of work. That's how small these work items are as when they're defined effectively. And they're literally, it's a collaboration between these people and they want to get up and they want to have that Scrum meeting or the daily standup and have that collaboration so they can figure out who's doing what during the next 12 hours or whatever hours before the next one, the next 24 hours usually, although some people aren't working at night all the time. Of course, in fact, and that's actually a good point as too, is this is about sustainable delivery. It's not about asking people to work harder. It's about asking people to work in a smarter framework and smarter meaning that framework is designed from a management standpoint to be more effective. You hear some of these words, Sprint, Scrum, things like that. Oh, Jesus, am I gonna be working 20 hours a day? So it's not about working harder. It's about working smarter. And so the collaboration is one area where there's more effective communication so you don't have all these emails and delays going back and forth between the same kinds of people. Another one is context switching. If you eliminate the work in process so that your dev test team is working on just a few work items at a point in time, they're not context switching and context switching has been studied to create as much as 40% of overhead for a team that's delivering work. So if you can eliminate say even half of that or two thirds of that, that is a huge bonus in productivity. Another one is quality. Quality is feedback cycles. More feedback cycles, you get more quality. You can define that quality as bugs downstream. You can define that quality as customer feedback that you're getting earlier because you're able to demonstrate software earlier. And through those feedback cycles, you still prioritize all the work and that basically there might be a core feature that you're delivering against but you might get feedback from your downstream demos, et cetera that you wanna, and the business, the PO will prioritize that work for one of the upcoming sprints to execute against. And so the quality system is phenomenal. Another part of the quality system as the scrum teams evolve, the impediments go through phases, right? Initially, the impediment is typically the backlog and getting the backlog of work items really clean and well defined so that the teams can execute against that. The next large kind of category is the flow of the work through the system because even in a one or two week iteration period, the team will have kind of a natural tendency to still batch their work. So they'll do all the development in the first week and then do all the tests in the second week and then everything hopefully gets delivered in the last day and the integration domain and all that happens in the last day and what the teams learn is over time that that system can actually be improved by doing your dev and test on one work item in your integration and then move to the next one to the next one. So maybe there'll be two or three work items in process for a four or five dev test team which would have a couple more of the PO and that scrum master for a total team of seven. That's typically the flow is the next impediment. The third impediment is the technical practices and this is where the DevOps comes in and the CI CD comes in. It's like, okay, how quickly can we integrate this new code and the new tests that we just wrote, automated tests are typically a definition of done, right? Into that CI CD suite so that we can have constant coverage on our current, our check-ins as well as everyone else who's contributing toward the same product so those teams can get fast feedback. So you have the technical practices or your third area of impediments and then the next area of impediments actually come down to organizational impediments. Things like, is the team motivated as a team or are we still motivating individuals as heroes and heroics are rewarded as an organization? And so some of those organization impediments are the impediments that ultimately drive the organization toward the mindset so that they can ultimately become the agile enterprise across all of their work streams. And so it's a journey. It's not something that organizations can just do on day one and move into it on day two or even hire a team of consultants to come in and do a transformation, right? It's hard. It's a cultural change and it takes a lot of energy, a lot of investment, a true understanding by the leaders of the company to understand that management innovation and responsiveness to the marketplace really is that third frontier of industry competitiveness and it will help our, the high tech companies which are faced with all sorts of disruptions and new technologies. Oh my God, you know, outsourcing to low cost regions. There's all these things that are going on that disrupt the technology industry. And through, so my hypothesis here is that it's through management innovation and implementation and really learning and sharing these learnings with the industry as a whole will move us further as an industry in terms of delivering value to our end customers. It's great. You went through a bunch of the challenges there. I'm curious, you know, in the companies you've worked with, you know, are people ready for this? You know, are there generational issues? If somebody's been in a company for 10 years, do they just have the antibody built in and, you know, they need to move and do something else and we have to bring in a new workforce or, you know, how do companies in reality work through some of these issues? So it's hard. So a lot of what you see out there, if you just go into any high tech company, you'll see teams like grassroots, teams will be trying this in general. You'll also have leadership, which has different levels of buy-in. Some of the leadership will be like, okay, you're the development organization, you're responsible, just take your delivery dates and, you know, if you don't do that, well, we're gonna like talk, right? And then other leaders, the more progressive leaders are really understanding that it is their responsibility to manage the end-to-end delivery system of the value stream and to start seeking out what are those opportunities to as an organization to invest in those things so that we can have that higher velocity flow through the system and fewer impediments and be as responsive to our customer base as we need to be given our whatever market segment and industry that we're in. And I'll claim that every one of those different market segments has different challenges. And so the leaders need to understand the value streams that you guys are all delivering against your, for your business on behalf of your customers and how do you remain competitive in your marketplace? Yeah, and absolutely, you know, one of the hypothesis out there, I mean, this isn't just a high tech problem, right? I mean, this is, you know, if you're a 150-year-old financial institution, you know, you're gonna have a lot more software now in your environment. Absolutely. So, you know, is there anybody that this isn't for or is this, you know, if you go forward, is, you know, what's your viewpoint? So I, so just kind of looking at industry in general, the financial services firms are really, they're actually what I would call leaders in adoption in this space, right? The product innovators, you have the, you know, the ones like Google and Facebook and those that are the online websites, they are like figured it out. They figured out how to do all this really continuous flow of value delivery. The product companies that are on release cycles have more of a challenge and they're beginning to get it and they're beginning to understand that this really is a competitive weapon and that they can go in and implement more greater responsiveness and strategically position themselves to essentially have a higher value company because now you can get to market when there's disruptive technologies facing you. You can shift faster than the market itself is shifting. You can deliver your products now to your customers before the customer changes their minds and ultimately it's all about market share and early adoption and getting that product out to market as quick, absolutely as quickly as possible. Great, last question I have for you, Bob. Two-parter is, you know, what, I want you to talk to the C-suite and kind of, you know, your advice to the C-suite as well as kind of take the average worker. Somebody's been, you know, out there doing stuff five to 10 years, you know, what do you see as some kind of, you know, real growth opportunities for them in their career? Sure, absolutely, yeah. So from a C-suite standpoint, if you think about concept to cash, ultimately as your value stream, if you can get your concept to cash on a faster cycle, you don't need as much investment to get there, right? I mean, that's ultimately the CFO, the CEO, the VC community, right? Faster time to market, faster value delivered and you have a business that has higher value, right? Even, you know, taking away, don't even talk about the market share gains, but just the ability to get market more quickly. Another big factor in these systems is quality, right? Because you have such fast feedback in the system, the quality, typically the number of bugs, like when companies implement this, literally the number of bugs after integration goes down by like, numbers like 50% of bugs go away. It's a huge, huge changer, right? Market share gains. If you can grab another one or two points of market share, you tell me, what will that do to the valuation of your business, right? And it's, there's different ways of looking at these things. Life cycle profits ultimately is the measure that I like to use in terms of measuring the value of the business. And that ultimately could be, you know, driven from this system, as well as all sorts of improvements to delivering that value more quickly. That is really what you're driving, is the life cycle profits, which ultimately the C-suite, again, I'm sure, is interested in is the valuation of the companies. So it absolutely drives to the valuation of the companies. In terms of the individual contributors, the awesome innovators of these companies that we have, all the technology people, the engineers, the developers, the testers, the automated testers, what I would encourage people there is really understand not only the technology environment, the product environment, but look at your delivery system. How can you deliver more quickly, right? How can you look at that system from an end to end? What's creating bugs downstream? What's creating more work downstream? Where are the batch processes? Batch processes slow things down. Batches can be anything like, you know, I want to do a big huge check-in before I merge to main, or it can be just a large work item, right? I want to have a 20-person day work item instead of a one to two day, you know, person day work item. Those are batches of work, and smaller batches move that work through the system more quickly. And so if you look at it from a management process standpoint, and think about it as innovation, right? We're all innovators. We love, we're all creative people at heart, right? You know, anybody that's not an innovator, right? It gives fulfillment to anybody who is, and I encourage everybody to innovate, and this is a ripe area to innovate, and learn, of course. It's not only about innovation and understanding theories, but wherever you can practice some of these things, you're contributing not only to your company, but you're contributing to yourself as well in your career and the longevity of the company that you're working in, and the industry as a whole. So that's my short answer to your question. Awesome. Well, Bob, you know, really appreciate you coming and sharing this. You know, in the past, often we'd say enterprise agility, that was an oxymoron, right? You know, it's heartening to look kind of 2017 and looking forward that there's this opportunity for deeper engagement, more innovation, and yeah, time to value is, you know, crucial. So, you know, agility and feedback loops and everything else. So thanks so much for joining us, and thank you for watching theCUBE. Check out silkenangle.tv for all the video and wikibon.com for all the research.