Innovation Series Part 2 - Feasibility

ABOUT THIS EPISODE

In order to determine feasibility you need to have the right people at the table. In this episode we discuss selecting the right people for your innovation session and potential pitfalls to avoid.

Most importantly, what should you do about the hippo in the room? Kurt Baumberger, EVP, Strategy & Innovation at Shadow-Soft, is back with the answers in part 2 of this 3-part series in Innovation. 

Join us as we discuss:

  • How to get hundreds of ideas at your next brainstorming session
  • Consistently generating holistic solutions
  • Tackling your product backlog the right way
  • Improving company buy-in!

You're listening to application modernization, a show that spotlights the forward thinking leaders of Highgro software companies. From scaling applications and accelerating time to market to avoiding expensive license and costs, we discuss how you can innovate with new technology and forward thinking processes and save some cash in the process. Let's get into it. Welcome back. We're talking more about steps to innovation with Kurrent. This is part two. If you haven't listened to part one, stop this one, go back to part one, listen to that very slowly and then come back to part two, because it will probably be more helpful, maybe a little bit more focused, like our friends, about exactly. I think that, you know, you definitely have to listen to the first one because it really lays out the foundation of Um what has to be built, and that's what the focus is here. Is Now we're gonna start building something, but if you don't know who you're building it for, if you don't know what their big pains are, you know you're just building for the sake of building, and that's not going to have any validity in the marketplace or viability in the marketplace, because your organization is not going to solve a really big problem. So definitely listen to podcast number one and then tune back in to this one and we'll tell you how to go build your product, and it's probably different than what you might think. I love that. It's the Radio Hook. We're ready to go. So let's talk about what's different about that. Let's talk about feasibility. What's feasible is, you know, really taking a look at what assets do you currently have, you know, and some of these from an I T perspective or they're gonna be legacy systems. Right. So you can't just assume that you're going to have all of, you know, this new infrastructure in place and this whole new development capability. Um, what you have to do is say, okay, what is existing? So get an inventory of the tools that are there. Um. But what you want to do, too, is you want to start really with a post it note and a sharpie. I mean, honest to Pete, that's what it is. It's a post it note and a sharpie. Um. So if you think about if you're gonna do a digital interface, okay, if you're gonna do it for a phone, then ironically, the size of a large posted note is exactly the size of your phone. You can lay it over your phone and you can see that. So start there. What's the home screen look like? Then where do you go? Where do you go map it out, Um, and recognize that this is where you're really doing a lot of divergent thinking. So you want to have all kinds of different inputs. You want to be able to think freely about, you know, what's the art of the possible and how is everything going to come together? So when you're prototyping, you really want to make things, UM, real. But before you get into making it real, Um, it's a great idea to go through an exercise of just pure brainstorming and ideation. And I would imagine that, Nick, you've been in, uh, a couple of different brainstorming sessions and Um, describe for me, like what's a typical brainstorming session? How long is it? What happens? Yeah, it's a good questions. So I think the ones that I've been involved in, we we tend to come in together, maybe not as prepared as you think, like we...

...come with ideas, but we haven't thought through what those ideas might be or how that could be constructed. So I like to do a bit of planning. So I think this. It's probably different based on the individual. Everybody kind of conceptualizes ideas differently. But yeah, we usually, you know, take some ideas, we throw them on a board, we start stack ranking them for some arbitrary reason and then, uh, we pitched them to each other and see if we can solve the world's problems with them in that meeting. That's probably not the best way to do it, but that's typically what happens. How long are those meetings? Hours, Um, and what are the group dynamics that typically go on? In your experience generally there? Um, they're mostly upbeat if you have the right people on the road. I found the larger larger the group, the more frustrated people become. You've got to have the right collaborator, collaborators in the room most of the time. That's very not declarative of me. Most of the time. No, every time. You've got to have the right collaborators in the room and I think it's good to have some variety and role for those people so that you can see things from different viewpoints. Um, if you have five of the same software engineers in the room and they do the same type of software engineering, you're not going to get probably a full view of data structures or security implementation or infrastructure, which is often where everything starts. So I think, I think you know. Like if you're in a small organization, you tend to bring a lot of different skill sets into a room. The question is, are you bringing too many? If you're in a big organization, do you have enough variety? I think we're probably be the biggest challenge, but that would be my specific experience. I think you nailed a lot of those things. So usually a brainstorming session is an hour and a half to two hours M that's what most people sign up for. Um there's usually a lot of people in the room and you tend to break up into smaller groups and try to come up with ideas. The challenge is that everybody's trying to figure out how to position their idea and how to sell their idea as opposed to generating ideas. You know. So what you really want to do is you want to get into the idea generation process and that's very, very different than the group dynamic. Plus it it eliminates the hippo. You know what the Hippo is. I don't. It's the highest income person's opinion. Yes, the hippo. So typically killer. Yeah, exactly. Um, you either are playing to the hippo or you're letting the hippo dominate. And so brainstorming, as we know it, is broken, and it's not just broken, it is a total waste of time. Here's a different way to do it. One of the things that you've done is you've gone through and figured out what's desirable. You know what people need. So take those needs and then break up, not as groups but as individuals, with a big stack of paper and a sharpie. And what you want to do is you want to phrase each need as how might we okay, how might we do x, and that that phrasing is very important because it suggests certain things. How might we suggest that there actually is a solution out there? And so that's very important and automatically opens up your mind. There's something that happens to your mind when...

...you hear those words that opens it up from where it was. The second thing that you want to do is, when you're generating ideas, you want to draw them pictures, because people dream in pictures, not in words, and what you're doing here is you're dreaming, and so what you want to do is you want to draw pictures. Now some people say, Oh, I can't draw. Well, if you can draw a circle, if you can draw a triangle and you can draw a square and a rectangle, you can draw anything. All you have to do is combine them in different ways. So if you had to draw a dog, you put a circle down, you put two triangles for the ears, you put a rectangle for the body and then two four other rectangles for the legs. And guess what you got? You got yourself a lovely dog. It's an ugly dog, but it's a dog. So anybody can do this. What you really need to be able to do is to unleash your creativity, and so the best way to do that is to start drawing with your left hand, because the left hand will free up the right side of your brain. Almost everything we do, and particularly in technology, is left brain focused, very analytical, very linear, and what you want to be able to do is open yourself up to think um in a transformative way, and what that means is you have to free up that side of your brain. Now there's lots of things you can do. You can walk around backwards. You can do one handed push ups with your left hand, other physical stimuli that will open up your brain, but the easiest thing is to just start drawing with your left hand. That's the warm up. But then once you start generating the ideas, it has to be rapid, and what I mean by rapid is you need to generate an idea every fifteen to twenty two. That is seems like it's impossible for people, but it's not. You need a coach who can come in there and say, okay, how might we do x? Draw it, and these are the coin of some of the coaching commands that I would give. Is like, okay, draw what you're thinking, what's connected to that? What else is playing into that? What else is really necessary? Okay, new idea, and then you put it aside and you come back and you do the next idea. It'll take you five or six iterations before you really start to feel like you're in a groove Um, and then all of a sudden you'll come up with things that you hadn't even imagined before, and so that whole process is what we call the generation phase Um. But once you get through that, you can prompt yourself along the way with how might a child look at it? How might your grandparents look at it? You know, what ideas would they have? If you had any superpower in the world, what would you do? You know, get yourself to think again, not in a linear fashion, but in a lateral fashion. How do you go from one to the other to the other? And for those of us who focus on technology, that's gonna be a stretch and it's gonna feel awkward and you're gonna be wanting to judge it and rank order things and set priorities, but you don't do that now. Now is where you're just generating all of these different ideas. So you'll find out that in twenty minutes time, each individual will have generated about fifty to seventy ideas each individual. So, depending on how many individuals, and to keep the maths simple, will say there's ten people in the room, we've just generated five, seven ideas.

When have you ever been in a brainstorming session that generated that many ideas that quickly? And I would bet, I bet my bottom dollar, that no one's haven't done that. Zero, but that this is only the first step. The next step is for you to go and share with a small group. Um, it's kind of like playing cards. Take your best idea and it's your trump card and lay it out and then the next person says, Oh, I've got to play the same suit for another trump card. How can my ideas build on your ideas? and You keep going around until you've got everybody's ideas out there, mixed and matched together, and then all of a sudden you've got something that is not a point solution, but it's a holistic solution. And once you feel like nobody has another card to play, then you stop. Set that aside. Then you come back, somebody else plays a trump card and then you go around and you do it again. What you'll find is that you'll end up with eight to ten really good holistic solutions, whereas before, you know you would only come up with a point solution. Now that you've got eight to ten them. From that point then you want to take a look at what resources do we have, because some of them are going to be quick to build and some of them are going to be very difficult to build based on the resources that you currently have, and that's usually a good way to do your ranking is just say well, especially in technology. We're not able to do this given our current infrastructure. Okay, that doesn't mean that you can't, because you could change your infrastructure if the idea is big enough, change the infrastructure. You know, one of the things shadow soft does really well is kubernetes. KUBERNETIES is a whole mind shift, you know, into container ization and orchestration and and security, up and down ephemeral data. You know, there's all kinds of things that are in that Um. But you have to be willing to say hey, I'm going to do something different and it's going to be different enough that it's going to be transformative, and that's what we talked about in the first podcast, is to not make incremental improvements but to make transformative change, because that's the kind of change that we need to have happen in order to create value for the business. So this whole brainstorming idea is about coming up with what's feasible, but it's not putting so many constraints on it that you get into the incremental improvement on you have to be able to do something that's transformative, because that's where the value creation is. In fact, Mackenzie got so frustrated in doing all of their consulting that they hurt innovation, innovation, innovation from all their customers, and what they found was that they had to stratify it. So they came up with this thing horizon one, horizon two and horizon three. And so horizon one is all these incremental improvements. And there are ways to make process improvements. That's what six sigma does. There are ways to make things more efficient. That's what lean does. It strips out things that don't have to happen, but it's not going to fundamentally change the business. Then there's horizon two, and that's where you're doing something that is transformative. That's kind of where you're looking at things and saying, wow, we've got a whole new way to tract product for Um, the origination from...

...the manufacturer to the endpoint delivered to the consumer. Now Amazon is a great example of that. They don't do it from the manufacturer that you can see, but they do have their supply chain backwards Um, so that they are getting information from the manufacturer. And of course Walmart started all of that, you know, thirty years ago, forty years ago, Um, so that they could see that from end to end so it's not like it hasn't been done. That gets back to this whole steel. Like an artist, find somebody else who's done it and say, well, what if we did it like them? What if we did it like them? And then that becomes kind of a springboard for new ideas. And so as you're generating these these bigger ideas, you have to be focused on horizon two. Now, horizon three is when you are doing something that's completely disruptive and that's like Uber and lift, completely disrupting. You know the transportation business. Most of the time all we're really focused on is horizon too. If you come up with two or three horizon two ideas in your career, you're a rock star. You come up with one, you're the most valuable person and become indispensable within your organization. So you know it's there's big pay out there. There's very low payout on the incremental kind of approach. So when I think about innovation and I t well. Even even if I think about the let's say the Agile framework, we have backlog. When we finished the sprint, we go to the backlog, we select some ideas, we have a meeting where we take down requirements and then we do an estimation on those requirements, which are always wrong every single time. And that may be that may not be specific to software engineering, that that could be every thing, but especially in software engineering, the estimations that we use point values. We don't even put people hours on it because we don't want to be that descriptive about what it takes to actually estimate and complete a project. So when I look at that, I go there's not a lot of innovation going on. The way we the way we maybe develop software is more organized. But I but I think for a lot of people they go, Oh, agile, Agile's innovation. Now Agile is just a tool, it's a framework, it's a way to get things done. Um, so why not? So my quick question around innovation and I would be do you think it would be like some organizations have an innovation group and that's what they do, but I would look at that and go if they're just focused on innovating, how does the rest of the organization benefit from that that's doing the work day to day? Do you think innovation teams should be formed from practitioners in the business, or do you think having a u, a specific group around innovation is the way to go. I think that innovators need to be trained. Now you can have some power users that are, you know, a department of people, but ultimately, in order for innovation to scale through your organization, it cannot be confined to a small group or small department. It has to be training people throughout the whole process. Now, training is, in my mind, doing. It's not sitting in the classroom, it's actually, give me a problem, let's solve the problem and guess what, we're going to solve it in ninety days. Um, surprise, surprise. Right. The other thing is that you were talking about sprints. What I would say is that we have completely mismanaged what the whole sprint process is all about. The sprint process is about coming up with...

...a tangible, concrete deliverable every two weeks. Some people do it every week, some people do it every month. I can tell you that the data is telling us that that's not the right cadence. The ideal scenario is to do it from the first of the month until the fifteen and then from six until the end of the month, and the reason for that is organizationally, it gets you into this cadence where nobody's wondering what the date is, nobody's wondering when the sprint is gonna Ender, when it's going to start. The executives and stakeholders who have to review it know that they have to keep the fifteen and the end of the month free for them to provide feedback, and so everybody organizationally can then manage their calendars and manage expectations to keep innovation going, because again, if it's not done in ninety days, it's going to fail. The second thing about sprints that we have completely mismanaged is we go into this, as you mentioned earlier, the product backlog, and then you say, okay, what are we gonna pull forward? What's missing in that is the loop back to the stakeholders. You know, after you deliver the sprint, you need to go back to the stakeholders and let them play with it, and it's got to be a physical manifestation. Can't be a power point presentation. You know, if I had my way, I'd say death to power point Um because I feel like people use it as a crutch. If you think about a new idea Um, the way that you communicate that idea and get feedback is by turning into something physical. If you're going to build a building, what do you make? Do you draw a picture of it? You could, but a lot of times it's a three dimensional model. Why is that? Well, because people will need to see scale and perspective and they can say I like this, I don't like this. And the questions that you need to ask when you're getting feedback are really simple and there's only four of them. What do you like, and why is that? And what don't you like and why is that? Okay, that's all you need, because then what you'll do is you'll filter through what people really like about the idea and what they don't like, and then that what they don't like. That should define your product backlog. But we don't do it that way, right. We just throw all these things in there and we hit the first ones and then we think about, okay, well, what's next in the sequence? What can we pull forward? And you're doing a kind of a forced ranking in there, right, that's based on your beliefs, not the end user, and so it's really running its head on the development process, because that's not how it's been done before and that is how it has to be in order to create big economic value for the business units and to make yourself indispensable in the organization, you've got to show big change, and the only way to do that is to get feedback, because what happens when you do that? You're also getting buy in, because people become part of the deal, are part of the idea. Now right there's you know. They've given their feedback. They're psychically involved. They want to know when's this coming out? When can I start doing it? You'll find out who wants to be a power user and you need those power users to diffuse the UM solution across the organization. Probably find your detractors too, exactly and spend time with them, because what they don't like about it is going to be very instructive. You don't have to necessarily make them happy, because some...

...people are never happy, but what you do need to do is you need to listen to them and find out why they dislike it so much, and then you see if that's something that should be in the product backlog or not Um. But it's a very different process. It's not what we typically do in technology, and yet it's so critical that we do it, because you'll never figure out what's feasible to be built. Um, unless you go through this iterative process. That's really good. That's helpful. Is that the breadth of feasibility for this, for this part of the discussion? Do you think? What is there a little bit more? So let me just summarize it, if I might. So the first thing is to start with then needs in mind. Okay, so we did that in the desirability and the second thing is to phrase those needs as how might we okay, so how might we do this, which opens up your mind to these ideas. The third thing is to generate ideas as individuals in a room and to do it by drawing pictures. Don't describe them, do not use letters, do not use words. You can have thought bubbles, you can have other sorts of things, but do not do that and then mix and match them. Is the fourth thing, to come up with a holistic solution and then take those holistic solutions and build a rough prototype, and by a rough prototype I really mean post it notes or, you know, pages that you just drop things on, because there's no point in investing a lot of time when you're just gonna find that half of it's wrong. So get it out there and start to get into the feedback loop, which is, for every sprint, get feedback, build again, get feedback, build again, but stop after three rounds. And the reason for that is all the data shows that you'll make a quantum leap from version one point Oh to two point Oh, to three point Oh, and then it's just incremental improvement. So those people that you're getting feedback from will get you to that final destination, but you have to go through these loops. So that's the last thing that I would just say is have the discipline to go through those loops so that you can make that quantum leap. And some of it might be so important that you may have to change your infrastructure, you may have to develop things in ways and use tools that you've never used before. But that's okay, because now you've got buying in across the organization because the end users have said yes, I really want that. Well, they say yes, I really want that, and then you go back to your CTO or C I o and say I need more money. You say, well, why? Well, because these seven people say it's absolutely critical. Okay, well, then I can go to the CFO and get the money. You know or the CEO if I need to. But Um, I need that organizational support in order to get the investment to make that transformational change. So part of its innovation and part of it is organizational influence and in my experience it's really fifty mm hmm. Yeah, I can see that, because going through the process of what makes something desirable, it could be something that people could do around a barbecue right very easily,...

...but getting organized around it and putting some plans in place a lot harder, much harder. Yeah, but what you'll find is that, um, and going through and by staying true to the Ninety Day time frame, is you'll get. You'll get organizational buy in left and right, because you're like, oh, we learned this from them, oh, we learned this from them, oh, we got this better, and so we tweak this and we tweak that, and so ultimately, when you come in to make it viable, you know how's the organization going to support it? Um, which we'll talk about in the next podcast. There will be objections, there will be people who resist, and the best way to overcome objections, or I call them the organizational antibodies that just come in there and try to kill, you kill new ideas. Right, that's different. Stop, you know, Oh, this is gonna Change. Stop. Is You have to have that support that you got from figuring out what's desirable and figuring out what's feasible, Um, from the stakeholders, the people who are suffering, because it's very hard to say no if you articulate how people are suffering and all the problems that come from it. And now you're here with a solution that's going to fix all that. So, Mr Naysayer, Mr Objector, is it the pain that you want to create for everyone, is to keep them this way when you know that there's an easy solution? Help me understand where you're coming from on that. You know, yeah, it's very different. We'll talk about that in the next podcast. All right. Well, stay tuned. That one's coming next. Under feed. Application modernization is sponsored by Red Hat, the world's leading provider of enterprise open source solutions, including high performing Linux, cloud, container and kubernetes technologies. Thanks for listening to application modernization, a podcast for high growth software companies. Don't forget to subscribe to the show on your favorite podcast player so you never miss an episode, and if you use apple podcasts. Do us a favor and leave a quick rating by tapping the stars. Join US on the next episode to learn more about modernizing your infrastructure and applications for growth. Until next time,.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (29)