 Welcome to Agile Roots 2010, sponsored by Version 1, Rally Software, Vario, AmirSys, Agile Alliance, and Xmission Internet. Innovation Games, Software-Powered Innovation Through Collaborative Play by Luke Holman. And without further ado, we'll start the program. Luke Holman is doing amazing things. He's going to tell you all about it, but if you go look at the work he's done and the organizations he's worked with, I don't think he can help but be impressed. And Luke's going to tell you a little bit about himself, so I won't ruin the story. Thank you. Hi, everyone. And it was very kind to say, I'm doing amazing things, but you're going to find out that it's not I, it's we. There's a lot of people doing amazing things. And one thing I thought was interesting is, I think Andrew was asserting that people in this room would have a full deck of cards. Many people who are new to Agile sometimes think we're crazy, right? So we may not have a full deck of cards. This is a little bit about me. And the reason I throw this slide right now is that six-year-old girl who is convinced she's a pirate is the reason why I wasn't able to come to the conference yesterday because it was donuts with dad's day. So I wanted to be there with Josephine. So I wanted to thank Andrew for being really flexible about letting me come at a time that was convenient for my family. And I appreciate that. As you can see, I try to work hard, but I play at work. And we're going to talk about play and what that means and how that works. And I'm going to try and do something a little different, which is rather than talk about, has anyone read that Standish report stuff about how terrible we are and software, how all these failures exist? Anyone read it? Boo. Say boo. Boo. Because I think that we should actually celebrate software-powered innovation. And I think we have the greatest job as software people. And I mean this completely sincerely. This is the magic that you create. And I'm going to pump you up a little bit about what you do around the world. Now, of course, I have a picture. And real briefly, if you're an innovation games trained facilitator, raise your hand. We've got Dale. We've got, who else? There should be. Israel is here or he was here. We've got Anders. And of course, Jeff Patton is a trained facilitator. And if you know Jeff, you know he's always doing his slides up until the last minute. So last night I was changing some slides, so I thought I should throw a picture of Jeff in there. Let's talk about software-powered innovation, software magic. Remember when this was innovative? Remember? Or am I dating myself? But that was innovative. It was. We had that innovation with MS-DOS. And then we had more innovation. The original mouse from Engelbert in 68. And if you've never seen the video, the actual video of Engelbert doing telepresence in real-time high-depth bitmap displays from 68, you have no idea what we still haven't yet to accomplish. Collaborative video editing in 68. Right? And then that became Xerox stuff. And of course, Father Steve. And now we have the Mac and we have the iPad. And although my wife disagrees with me, I think it was a perfectly justified reason to get Marvel Comics on my iPad to justify the iPad. Because if you read Iron Man on an iPad, it's like, oh man, it's for work. Really. It is. Okay. And now look at where we are, right? You think Tom Cruise in the movies, but there's people who are doing work with embedded systems with a company called Intuitive Surgical, which actually enables doctors to operate on patients in very non-invasive ways. And you know what? You did that. Maybe not you personally, but us as the community. Because this is all lumps of metal without software. It's all lumps of metal without software. And it's not just the user interface that I'm talking about. We've had innovation, software-powered innovation, as we have learned as a community to solve problems about architecture and scaling. Remember when we did two-tier and we thought that was cool, and then we're like, oh no, you're putting the business logic in the user interface. Oh no, no. So we did three-tier and then we did four-tier. Now we have 17-tier because that's cool. Right? One more tier. It's got to be better. And then we created data warehousing, data warehousing architectures, data warehousing pictures. Again, we're solving these amazing problems. And we came up with patterns as a way to share the stuff and communicate this. And this is all software-powered innovation. Magic that you create. Magic that software people create every day. It's a great profession. And it's not just that the user interface at the architecture level. If you look at the world of innovation, because I'm here to talk a little bit about innovation and collaboration and collaborative play, if you look at the world of innovation, there's many kinds of innovation in the world. There's business model innovation. And there's process innovation. And there's channel innovation. And there's distribution innovation. And there's all sorts of products and services. And they are all powered by software. I know the hardware thing is important, too. I don't want to discount those hardware guys. I know he's laughing. He's like, don't show that on YouTube. This is all powered by software. Business model innovation, right? Zip car, changing the way we drive, changing the way cities engage transportation, powered through some of the work, because it's sophisticated routing and scheduling. Software people did that. You did that. Supermarkets. In the 50s, the biggest supermarket had approximately 8,000 items. Why? Because that was the limit that a human could manage the inventory. That was the paper limit. Now you go in and you have 8,000 kinds of ketchup. Some people say that's not so good. If you like a lot of different variety in your ketchup or your salsas or your pickles and your olives and stuff. That was all done because a software person did that. Back to the car. How many computers in the average luxury car? Five. Five? How about an order of magnitude more? 30 to 50. How many millions of lines of software code in the average car? 10 to 20? About five. Five to 10. We have a variable valve timing, which helps improve fuel economy, where you start off with 8 cylinders if you're pulling a heavy load and then on the highway you've got the 2 and 4. GM had that working in the 70s, but it took a vax to run it. Moore's Law kicks in. Software people get more efficient. Now we have variable valve timing. Cars are safer. Materials are safer. We're as a society where you are creating a better society through software. World's tallest building. Elevators won't work without software. What we do. Software innovation is everywhere. This is Jeffrey Moore with one of his recent books dealing with Darwin. He talks about all the different ways you can innovate. All the different exciting ways you can innovate. Of course, as you can imagine, given my lens, I just see all software. This is pretty cool. Software, I think, being in this profession, I told Andrew that part of what I wanted to do in this talk was give a little bit of celebration of what we do as a profession. Independent of process. Independent of agile or not agile, whatever. Just what we do. If you think about your world and how software affects your world, it is a way cool profession to me. I give a longer version of this talk to high school kids and college kids trying to get them to join our profession. Because this is really cool stuff. We do really cool stuff. Broad universe. Now, when you think about it, what causes and creates and enables and promotes innovation? Give me some shout-outs. What do you think creates this notion of innovation? What? Need. Yeah, you've got to understand the problem. Even if your customers don't know they have a problem, you can help them. That's true innovation when you're helping them realize that they don't even have a problem you're solving for. What else creates this notion of innovation? Competition. Two people said competition. You bet. One hand clapping isn't very interesting. Competition is good. Competition is good and it does create innovation. Scarcity creates innovation. What else creates innovation? Innovative stuff. I got a little something. I know, but I do have stickers if you want them. The only problem with my stickers is when my kids read my stickers, those are these work stickers. Who's wrong? Back-off-take stickers. It's great to get modded by the IRS. Legitimate production. Play. Play creates innovation. Absolutely. Play creates innovation. Absolutely. What's creativity? Vision. Yes. What else is creativity? All these things create innovation. One of the things I want to talk about is that we aren't talking about innovation. I'm not talking about invention. Invention is the theme of this stuff. That's cool. But innovation is actually putting it into practice. So what I want to talk about is the goal of the library to play. Not so much anything in the invention side, but in the innovation side. And there are people who study this. People who are core-studying this. And they're not necessarily from the software community. So one of the people who studies innovation, which we're going to talk about is the idea of putting things into practice. A common way to talk about this is what's called new product development. The field of new product development. And there's a guy named Robert Cooper. And he has a model of new product development called stage eight. Now, when stage eight is understood, it's very compatible with agile. When it's misunderstood, people call it a waterfall. Because they see that Bob says, how do you front-end homework before developing an invention? They call it a pickup line design, and they don't do that. That's not what he's saying. He's saying, do your homework. On your screens, someone says, what's the problem that you're solving? On your screens, you are customers before you just run out and start developing. Make sure that you can get a new one on what the problem is. But look at some of the other things that Cooper has found to be drivers and supporters of the notion of innovation. Can you see the agile man that's been over here? Part of the case? Robert, let's read us twice for now. What part of the agile man do you see right here? Customer focus. Number one, how about spiral development? Spiral development. This was done before we had other methods. Spiral development method was really the more prominent agile method. Very big spiral. Loose with music. That's what I'm talking about. That's what I'm talking about. Loose with users throughout the world. That's what I'm talking about. Methods of comfortable teams. Sounds interesting. Polistic effective cross-functional teams. Now, when Bob Cooper is saying cross-functional, he doesn't know the potential of the developers that will help move on. He means truly cross-functional. Marketing and sales and marketing and distribution and manufacturing where we've got to create a product and modeling and marketing. Pretty improbable stuff. Any doubt that I say anything worth tweeting at? Yep. All right. Tweet tag. Okay, now, if you can't remember the agile man best spell, here it is. We can hear you again. Now, it includes all of the 14 practices, but here's the course of the individual interaction towards the software and customer collaboration. So we're going to talk about the notion of collaboration and play as it relates to this great thing that we get to do. We get to write software. We get to be innovative every day. And the world of innovations really to me, lives itself. I don't know if there's other stuff. But, when you think about the other stuff like someone said in the fact that well, you know, there's a lot of innovations that occur in material science that allow you to do a software. I'm going with that. Did you, by the way, model those material science in the basement using the software tool? Or was it me? All of the innovation across the control and through the chemistry and drug research. I agree. Here it is. Did you manage to experiment with software? Did you analyze and did it with visualization tools in the paper houses? Yep. External collaboration is successful. IBM, every year, does a survey to 1,000 CEOs. In 2007, the topic of the survey was global innovation. 500 plus of the world's top CEOs survey. Now, I can't get that kind of data. You probably can't get that data because we're not IBM and we're not doing a lot of them. But, looking for data. Now, look at what the survey says. The most significant sources of innovative ideas. And it says employees as number one. Mmm. What does this mean? What is your number one? Well, I actually think that while the data is presented accurately here presenting in a misleading way. Because what I'm going to do is I'm just going to take those bar charts and then move them around a little bit and then I'm going to break it up to internal versus external. What happens? Two to one. Two to one. External collaboration is considered to be essential for innovation by 500 of the world's top CEOs that survey by IBM. This is interesting. This is interesting. Bob Cooper, who studies new product development says, do your own work to collaborate with the customers to inspire them to develop them. Where do you have the link? IBM says, where's the source of external or where's the source of innovative ideas to go outside? So how did we get there? Alice suggested just play. I'm going to go with Alice. So let's find out who you talk with. Dennis, you missed the shout out. Dennis is another trained facilitator. For my trained facilitators, we're going to do a game called Spider-Wave. There's paper and crayons around you or pens and pencils. What I want you to do is draw a circle in the middle of the paper. Write your name in the center of that circle. I want you to write the names of the people that you collaborate with at or on a regular basis. And I want you to draw lines between your name and their name. And I want you to draw those lines in any way you want to represent the relationship that you have with that person. If it's a good happy relationship, pick a good happy car. If it's not so good a relationship where it's contentious, but a contentious color, go draw. You have about 3-4 minutes when you'll be walking around and helping and answering questions. By the way, this will work better if you draw as it is, not as you wish it were. As it is, not as you wish it were. And don't try not to cry. I got one guy back here who's laughing so hard, but I think he's crying. Alright, you got a point of view on that? You got a point of view on that? Ron, once for yes, twice for no. Yeah. We're still working. I know. I know. So, I'll tell you another version of this statement we did with some customers. Now, I want you to take a second sheet of paper, a second sheet of paper, because this is the names, right? The names are not something that we could share, but I'd be interested in seeing the results. And Dale, raise your hand, Dale's one of my training experts. He's going to help me. He's going to help blood results. Do it again. But this time, I want you to replace the name with the role that the person is playing. You know, developer or tester, if you still have differentiated roles in your acting, that would be interesting because you might, right? Look at that interaction. I think we're close enough. This is the game that we played with Paul Spiderweb. Now, normally, when we're playing this game, we're asking customers of our client to draw pictures of system relationships or other relationships that are related to us. We do this collaboratively. Here you're moving it in a less collaborative form to illustrate a point. Now, when you're looking for paper, I get to do the Dr. Phil. How's that? Working for you. Are you talking to interesting people? And more importantly, are you talking in a way that suggests that you are in fact engaging in customer collaboration? Are you talking with people outside your building or inside your building? Are you really, truly regularly talking with your customers? Now, Dale, raise your hand. If you would like to see what other people wrote, and you want to hand us the version of this that doesn't have individual names but roles, hand it to Dale and we'll take photos of it and we'll post it on our website and see what happens. I'm going to show you some pictures and I hope they come through about other people who've done this exercise. So, keep in mind that we're Agilists, right? We're Agile Roots. Right? So, we favor customer collaboration over contract negotiation. We do, right? All right. So, developer one. Interesting. They have developer, developer, engineer, management marketing. Marketing, that's a big red line. It's not coming through. Red, equal, miscommunication. Green. Good. But that's it. Clear. Change another developer. Right? Blue. Directly understood. Right? Jacket to be avoided if possible. Now, did you see any customers in that picture? And how about your picture? Let's try it again. Developer two. Have the tense problems. The closest this person gets is product management. But, of course, product management isn't a customer. They're just a customer proxy. Sometimes, they're good customer proxies. And sometimes, they're just frustrated X engineers who want to build it and want to build it. And now, they power it down. It's not demand and control. I'm just prioritizing it. Think about it. Manager one. Do this with a manager. Look what happened. Wait a minute. Developers, we're not talking with customers. But who gets to talk with customers? Managers. I'm a manager. I talk with a partner. Customer. Partner. Customer. Interesting. So, if we're so agile, where are all the collaborating customers? They're passing. You'll have to tell me why you're shaking your head. I've got to find out. If we're so agile, we've got a guy in the middle of the road going. If we're so agile, we're all collaborating customers. We're going to talk about that. Now, that's one big asterisk. Is it not? Yes. Yes, it is. So, hold on that point. We're going to go back to that slide. I think that one of the reasons that we may not have this notion of customer collaborations because our tribe of azurists has equated many times the collaboration of the talking. Collaboration to interviewing. Tell me what you want. Write a user story with me. Which is effectively telling me what I want. It's a survey. Right? So, it's like you're talking to the pig. Okay. This isn't collaboration. This really isn't collaboration. Now, think about our tribe. We've said write better tests, do better stuff and we've created a whole infrastructure of testing and a guy I trust again, Dale, he's like, dude, have you seen this new book on agile testing and testing your products? Yes, we have books on some of that. But where's the stuff about collaboration? Where have you been taught how to really collaborate? And it's important to understand that collaboration is not. It's more than talking. So, what is it? Let's deal with Wikipedia, right? Because when you're doing talks you can either steal images online or you can collaborate it right away. Go to Flickr or borrow Wikipedia. I love Wikipedia. Bless you. So, collaboration, it's recursion which always you like because I'm an expert. It's recursive. But it's about a goal and it's the intersection of working together with these common goals, right? And so we share. This is collaboration. How do we do this with customers? How do we teach ourselves in our community and our world to do collaboration? And collaboration is hot, hot, hot. Hot. I'm from Silicon Valley, right? Which is like the land of $80 billion of uninvested venture capital within 15 miles of my house. And they are shoving money at social networking, social gaming in collaboration. It is hot. It's hot, hot, hot. And yeah, most people do collaboration because they think it's a platform and it's not a platform. But we do need tools. We do need tools to collaborate. But collaboration isn't the platform. And when you log into a lot of these management tools it's like, you log in and here's your task board. Here's your task list and it's about you. Well, I thought collaboration was about working with others. And yet, I am important in the role of collaboration. My task is not important. If I'm going to work on a task board and it's not sharing. Especially in business people like, hey, we're going to share. It's like, you know, glitter. Kind of, but not really. Sharing isn't collaborating. Sharing is sharing. That's okay. Sharing is part of the collaboration but it isn't collaboration. And it's not notifications. There's a big hot movement right now. How do I notify you? How do I signal you? How do I create the right compound board so that you can organize your work and we can combine the mechanisms between the different functions. This is good but it's not collaboration. And yet, we do need to be older. And the other thing that I think really interesting is that there's this notion of transparency in adult in the sense that everything's got to be transparent. But guess what? It's not how humans work. We can't work where everything is always transparent. People need an opportunity to have private spaces, semi-private spaces to engage in negotiation, to engage in collaborative acts. So how do we do this? Maybe it is the tools. Maybe we don't have the right tools for collaboration. We can talk about what kinds of tools is this for collaboration. Alice has been distributing some tools for collaboration at the conference. There are lots of tools for collaboration. So let's talk about what, if it's not the platform but tools are important and it's not sharing but sharing is part of the collaboration. What is this thing? Well, collaboration does need tools. In the land of computer-supported cooperative work, we organize the activities of people in the same time, different time, same place, different place. When we have different mechanisms, right? We have in-person games for what we do. We have online games. This is the same game done in-person and online because the context will determine one or the other. We have co-located teams and the extruded teams in terms of how people work. Now, in-efficient games what we do are serious collaboration tools. It's kind of fun. My old company was at the Ossetian Newlands in the in-efficient games company partly because this is hard to speak and read and spell. This is a Forrestner report where they're talking about, wait a minute, there's something happening in the industry that says gaming in serious games are really important. Some things happen. What are these things called in-efficient games? They're serious games. These are games that are played to solve complex organizational problems. Andrew made a shout-out in my introduction of some of our clients. We're really proud of some of these clients. We've done some really interesting work with some of these people. We're going to talk about them. Now, these games are not silly games they're not fun and they're not humorous games. So we're trying to distinguish this notion of a serious game or collaborative play from something like going to the water park or playing a game or something like playing paintball or something. It's more like spellers of the time which is a game where collaboration matters and how you play matters. There's an element of competition or there's an element of collaboration here. Does anyone of them know Yooker? All right. Yooker is a really fun card game usually played with beer because I spend a lot of time in the Midwest and I do have a beer for the interaction. But if y'all come over oh yeah, they can get a beer from the beer interaction. And it's this notion of competition and collaboration. Now, one of the reasons that we struggle as an industry to talk about this notion of serious game or serious play is that we do not have a word for this in language. As you understand linguistics, you understand that language and it's really hard to understand something that we don't have any words for because it's always action and wrong. Serious game. Serious play. Well, how can that be? So I'm going to give you a dimension that says these are the things that you might find pleasurable and these are the things that you might find not pleasurable. We'll tell the things that you find pleasurable will play and the things that you find not pleasurable not to play. So far as good? And then over here we're going to put not work, which is leisure and what I need by not work is you're not paid to do this. You choose to do this or you're coerced to do this as you'll see in a minute. And then we'll put over here the things that you do which are to work really. You get paid to do them. Now for me, and this picture there's a completely personal. I'm going to give you my version of this picture. For me, that's not me, but that's a picture that looks like me. I have this hedge of idea on the side of my house and it's the evil idea that needs shading about every six weeks. It's anything long, it's 18 feet high, it's 3 feet wide. I do not find shading the idea into a pleasurable activity. To me, this is work. Now I have a friend, Sandra. Sandra is wonderful and she is a gardener who loves spending time in her garden. Her idea of a happy weekend is wake up Saturday morning and come home going night dirty with dirt and making her garden beautiful. That's not my idea of where things go. Are you with me? You can start to see this. Now for me, I actually do like playing poker. I think it's a fun game. It's playing it simple. It's a good game to play. So I'll put you girl here. Now that work, I run a small business. This is a picture of quick books of Cali. I don't find one of my books pleasurable. An account, however, might. It's not my cup of tea, but for an account or tax attorney or something like that, that kind of work could be fun. Of course, I find playing games. You can look at this world and the challenge is we're happiest as humans when we are operating in that space. And if you look at that article, you'll find that part of this is that this guy has done brain scans between two eight-year-olds building the Lego City and two adults collaborating pairing in PowerPoint and the brain scans are the same. The level of pleasure, the level of engagement and the level of thought is the same. Makes sense. They're working in a pleasurable way with a common goal for truly collaborating. So, and it is fun. So one of my clients is version one. Version one came to us and said, we've got some part of our background that we would like to prioritize with our customers. We played three different games. These are the actual unedited triggered scripts from three games, you know, where I just said you enjoyed the experience. Yes, it was fun. Now what was the last time that your customers thanked you for giving them a survey? Maybe not. So what happens is it's not only that your team has a better response, your customers can engage in this process and this notion of collaborative play starts to affect people in really profound ways. Now, when you look at the world of collaboration the definition talks about having a goal. Now these are some of our client projects. And if you start to look at the goals, right, I want to prioritize the project portfolio, I want to do new product development. This was a really interesting project between NetApp and SAP. NetApp came to us and said, we're finding our software is used in interesting ways with SAP software. And I said, great SAP is a customer, how about we bring SAP in the room in terms of the research, which the project affects both companies. A little bit of shuttle diplomacy, but both companies agree to do a joint research project. So when you think about collaboration, and you start talking about extending your notion of collaboration to your customers, include the people in your ecosystem. Your partners and suppliers start to think about who now I collaborate with to make something happen. Now we did a game with these people on spider web. We had webs, now we did an extremely abbreviated version. Most of the time the game takes two hours for a single game with customers. With the game here, we had a spider web. One spider web. We had six spider webs drawn by customers. Just one of those spider webs was eight feet long and six feet high. Showed all of the relationships and interventions of a complex IT environment. Amazing stuff. And you can use that to do what someone shot out earlier, which is, what is the foundation of the innovative project? Understanding the mark of need. Requirements come after the industry. Requirements shape your industry. Understanding the mark of need is part of that first step towards true innovation. Now, enterprise goals, what's interesting is all of these goals are verbs. We want to do things like envision the future. We want to prioritize stuff. We want to plan and sequence. We want to establish boundaries and understand relationships. These are part of the verbs. And this is where we start to see the distinction between these kinds of games that I'm doing or games like Alistair is doing, which if you look at traditional tools, chat is good, but chat isn't a sufficiently kind of application to help you collaborate with customers. Because it's not tuned towards the goal. It's like using a hammer to screw boards together. It's the wrong tool. It's not a sufficiently advanced tool. So what we're trying to do is create a set of higher level tools that enable you to collaborate with customers. Now verbs mean action. Right, verbs mean action. Now, I'm a Marvel guy, but I know there are DC people in the world, so I throw in some DC stuff. Right, verbs mean action. And to take action, we need to both create the goal and an entry action. And then we need to reduce ambiguity so we know older building, reduce equivocality so that we can do anything. Reduce equivocality so that we have a higher degree of confidence that the team is operating as a team, and then we can do the normal stuff, which Agile helps with, which is identify, distribute, perform, integrate and verify that the work is going. So collaborative play helps with these things, and Agile kicks in because those things are efficient. Right, so these things are not antagonistic, they're very supportive. Now, I mentioned that you want to solve specific problems with specific tools. James Bond would be horrified if he fired up a blender. He would. Because he asked for it, shaking. Not smoking. And certainly not well done. So, here are some examples of the games that we have. All of the games are at visitgames.com. If you want to give me 83 cents, you can buy my book. I thank you. Right, so we have product box with such a vision. We have remember the future, understanding shared success. We have spiderweb, which you played, which helps you understand conflict relationships. We have start your day. One of the things that people make mistakes on in the department's gallery is they ask people, tell me how you need this done. And they forget that the relationship that you have to a product or service changes is over time. The way you use TurboTax in September is very different because we use TurboTax in March or April. The way that amusement park needs to manage the database of customers is radically different in September than it is in May. Right, and what we want to do is we want to give customers that we're working with an identification of need, an opportunity to tell us how the when changes the how. Because those things will change. We want to understand hidden needs and problems. There's a game called show and tell. There's another game, speedboat. How do you understand things that are going wrong? If you want to break speedboat down into your developer and you're like, look, I understand developer. I really need a developer centric. You can use speedboat to identify a technique with that. There's a lot of folks at innovationgeams.com that explains how to deal with it. You can leverage these teams in teams that are internal. There are three games towards prioritization because prioritization is such a hard problem. You can prioritize benefits. You can build great road maps or you can use buy a feature. Buy a feature I'm not going to talk about it except to say one of the fun parts about buy a feature is when you get customers to create their own money it really personalizes it. These are Scott Bucks Scott Bucks from Intuit. At the top it says the life and design you trust innovatively must. Scott Bucks they use Scott Bucks when they're playing buy a feature. Now, why is road mapping important? I'm trying to bring this on. Why is it so important? You can change these numbers. You can change these numbers. I chose what I thought was reasonably fair of fully loaded developer being salary plus benefits, plus office days, plus gear you can raise or lower that number but I picked a hundred feet. A little over silky valley, a little high part of the places. Let's say that your iteration length is three weeks fair enough. I'll build three weeks, two weeks four weeks. One week one hour continual. If you look at it that means that your iteration cost every three weeks you're paying 8,500 bucks a little bit more. Your team size is 8 because the money's co-located team sometimes. That means that your iteration is costing you $1690 pay. Let's say that you pull down 60 points because you're really planning poker at home-based estimates. We know these aren't transferable or comparable however they are way to understand what things cost. And this is an epic. And epics are really big and really big stories. Our experience is that epics break down into as many as 20 to 50 discrete stories. The big chunk of work breaks down into all this other stuff because we're doing lots of elaboration and making it big smaller because and this is one of the problems with agile right? Customers like big chunky work developers like you and it's this dichotomy of customers want these big things and agile people want these small things that is this notion of decomposition. Nonetheless let's say that your average big chunk of work costing $150,000. I don't know about y'all but you can't be making a lot of mistakes at $150,000 in these successful business. And so there's some worthwhile you know, some goals to understand what's going on here. Well let's look at the agile planning and you know have you seen this, the agile planning circle? Have you called the agile planning onion? Have you heard it called the onion? No? I don't like calling it onion because I need to make you cry when you've got it. I call it the flame because agile words are hot. We don't have to have to. There's flame. Right. So you have to manage the questions and the perspectives according to the time frame and wrote that fully kick in at many months to many years as opposed to these other things. You can start to see in the overlap of the different organizations that we work with. Now do you want to see a roadmap for it like that? Marketing comparison? Yeah. What do you look like this? Is it somebody's worst? Just pull out the website. It's a really blue marketing and it says nothing. Look at it. What does it say? Nothing. It's pretty wild. They're going to fix stuff. They're going to produce stuff. They're going to fix stuff. Now this is an actual client roadmap from one of our projects and you can see because pretty thing the picture is messy. So here you can see there's a question mark that was going to happen. This could go here or here and solve a problem. So how do we create this? How do we get there in a collaborative way? Many of you have probably sat in experience with the customers. We bring customers into the room maybe at the customer advisory board or a user group meeting and your marketing team presents the roadmap in power. And you're like what do you think? And your customers are sitting there going well clearly they don't really want to know anything because they think it to be in power. Because power point is not a medium for collaboration. It's a medium for presentation. And that's not to... I'm not looking at power point. Power point is fine. I'm using it right now. What I'm saying is that if your goal is to collaborate with customers, that meeting is not the right meeting. There's this really interesting gap. You really do want to collaborate with your customers. You really do want to get their feedback on your roadmap. And they want to give it to you. And yet the tool doesn't allow for that. So let's drill into this just a little bit. Does your roadmap look like this? These are actual pictures of from the product tree in action. Where we are representing and it's kind of hard to see it's a little faded. But these are actual trees that are the features of the emerging software product. The elements of the roadmap are represented as apples and leaves in the feature. When I say apples and leaves, I really do mean go to a school teacher supply store and spend four bucks and buy apples. Put a piece of