 re-invent things that were already in the industry and then we would go look in the industry and go, oh, wait a minute, we would have saved ourselves a ton of time if we would have just understood that we didn't have to go invent scrum, scrum already existed. But I'll give you a little bit of that as I go through and we're talking about customer value. My background is I used to be a senior engineering director at Intel Corporation but the span of my career is actually much longer. I was with Intel for 32 years. I had within that and I don't think I was stagnant that I just I just went into Intel and that's all I did was just one job. I actually had 10 different careers when I was in the company. The company is large enough that enabled me to be able to do when I first came in. I came in as a microprocessor design engineer and I worked on something called the 286 microprocessor. How many people know what a 286 is? There's a few of the few of the old-timers that are here. The rest of you millennials, you know, yeah, I won't try to date myself too much with that. I do come and approach everything with an engineer mindset though. Since I did, I'm a formally trained as an electrical engineer. I find that the way that I approach problem-solving is very much from the engineer mindset. I've been doing that for a number of different years. One of the outcomes that is is that, you know, and I didn't get my coffee so I'm gonna probably not be able to solve too many problems here today but you know it's problem coffee and a solution comes out the back end and the output of that is also sarcasm. Meaning I look at the world and I look at the things that we're doing in the agile community as well as leadership and innovation and I see some things that we're doing wrong and so part of what this presentation is gonna do is hopefully bring some of that around to all of us. My background, Intel's a small company, right? Little tiny company, not too many people there. We know everyone's name. You know, it bugs me the most about working for a company that was 100,000 employees that I'd always get somebody coming up and say, hey, do you know Persana? And I go, yeah, I know a number of people who remain Persana and it's just a it's a common thing that people will come up with you on but this is what a typical project looks like at Intel. When we produce the next series of microprocessor, there's a high degree of structural complexity that we have to deal with. There are 30 different components that have to come together in order to put together that laptop that's up there and we've got to coordinate that as we all go through. Other things we have to deal with of course, because we're in 162 sites worldwide, we actually have this big social complexity. An agile adoption in India is different than an agile adoption in Norway and it's different than in the United States on the east coast and on the west coast. They're all different. They're all unique on how the way that they go up and that work gets done. The last one is just strategic complexity. You guys get to work on one thing right and just one thing by itself. True one project. No, it's multiple projects and with us what we had is that microprocessor in that particular laptop up there is actually goes also into the chip the device will also go into a desktop computer about 16 different flavors of a desktop computer, multiple different versions of a laptop, notebook, pads, surface tablets and other things. If you look at from a requirements management perspective, we were always being pulled a bunch of different ways. The last thing that I'm going to talk about and this is just really brief and I let everyone know this when I'm doing presentations because two years ago I had a stroke and I'm not sure if you know what the stroke is. I had a blood clot that broke off and settled into my brain and I couldn't remove my entire right side of my body as well as I couldn't speak and nothing is more annoying for me than my inability to speak, but that's the medicine that was going into my arm that broke the blood clot up and I bring it up for two things. Number one, my voice is different. You might not know it but to me my voice is different and so it's distracting and sometimes I will stutter a little bit and that's just the reaction of after I've healed up I had to repeat myself with a number of different things. I apologize for that but my primary reason for bringing it up is remember these signs if you have any of these and I know it's not 9-1-1 what number do you call for emergency? Call that up, get in there because what I learned about that shot that they gave me is it's only effective three hours after the stroke starts. After that it doesn't work anymore meaning that the brain tissue is dead and you unfortunately become part of the statistic that they can only use these types of drugs four percent of the time. Don't be part of the four percent is what I'm saying. First sign of a stroke or the symptoms that you're going to have a stroke is your first stroke. So just that's my public service with that. You guys are familiar with these, right? Tracking. Why do we have them? Why do they exist? What's that? You have to track where it's at. Why? Progress? Why? Whether or not it reaches what destination? What's the most important destination? What's that? The goal or target? Sense of timing? You guys are also practical. The reason why this exists is because I want it now. I want that package now. When I go up to Amazon or whatever ordering system that you do, I push that button and I want it to instantaneously appear. These tracking labels are to give us something to do in the meantime. It's an accommodation of speed meaning that I can watch my package start off in New York. It spends some time for some reason which I don't know why it's in Kansas City for a while. I think it might go and do some sightseeing or whatever it is but it spends a couple of days there and it eventually gets to me. But it's an accommodation. Now we as a society have become very obsessed with speed and efficiency. I love this guy. It's just amazing. But speed and efficiency, if I think of my corporate life, that's all of the programs that we ran were about speed and efficiency. Now the engineer in me says that you can make some other efficiencies as well but that's for another talk. Do not try this at home. I don't think that's going to have a good result. But if you look at our life cycles, the way that we've assembled different things, the little artifacts, if I have to dig into most companies, you probably have a life cycle that looks similar to this. We explore some stuff. We develop some stuff. We deploy some stuff and then we support some stuff, right? Is that sort of your corporate cycle? That's waterfall in some regards. Or if I shrink it really small, then it becomes scrum or some other iteration that's out there. But if you were to look at this, could I actually say with all of these activities that we're doing, could I actually see where the value is being created? Could I say that you're actually, is there more value in exploration or development or deployment? Or likewise, this is how our org charts look in our companies, right? We end up having a group of people that, all they do in their job is explore. Bunch of people who develop, bunch of people who deploy, bunch of people that support. And it becomes really difficult for us to understand where the value is. And it all becomes so activity based that all we talk about at most adult conferences is the activities and the processes and the methods that we use to the point that all we're doing is talking about these cool things. And we try to simplify it to the point where we're losing, I think, what we were trying to do in the first place with Agile. This constant sort of just over and over mentality of refining and refining another thing and refining another thing and refining another thing bugged me when I was working in the company. Because there is an Agile principle that we were ignoring. It was called simplicity. And that simplicity principle and the other one, which is value, we were not doing. And if you look at this, if you read through the Agile manifesto and if you look at what it's focused on, it's focused on how do we deliver the best possible value to the customer. And sometimes that's not speed. Sometimes that has nothing to do with the efficiency of how we work. It has everything to do with what the product that we're actually getting to the customer itself. And so my quest over the last five years internal to Intel was how do we make this principle and set of values come to life and that we can actually start to go look at and address value more effectively. Which got us to the first problem. Our first problem is if I had to ask what value was, what's value to you? Something that's important to you. What's value to you? Something that you're looking for. Value to you? Something of benefit to humanity or yourself? Both. I want both of those. So we had hundreds of stakeholders and we're trying to go off within the stakeholder group. We started asking what was valuable to them and what we found was is that we didn't have a common definition within the company. And now the question is could we have a common definition? If we look back and think about what we were doing with value is we were conflating a whole bunch of stuff together. We were munching it into one thing that we kept talking about. To one, if you were on the delivery side of the business, value was about how did I deliver? How did I get it out the door? The customer had a different perspective. The executives had a different perspective. And it wasn't until I saw Don Reinerston's book talking about flow that I got to understanding that we were pushing all these things too close together. Meaning value by itself actually is a standalone thing. These other things like cycle time, product cost, development expense and how we manage risk within our companies, those were different animals. But they affect value. But they're not value, if that makes sense. How many of you, of course, you know, does anyone not have a smart phone in here? Everyone does, right? What's your favorite application on your phone? What's favorite? What's what? What's up? What's up application? And how much did that cost you? It was free. Wow. So free. And do you care when it gets delivered to you? That free app, when it gets its you do? Yeah, you care if it, you know, you might leave it even if it's free, but you find value from it. But some of these factors here really to you, if I had to say tomorrow, the price of that application is going to 100 US dollars. Is it valuable to you anymore? No. So see how those things play off of one another. For free, I'll take it. Sure, it's highly valuable to me, but if it cost me 100 dollars, I don't want it. You can keep that app. I'm not pushing the button. So this equation for us started to go dig through about this. What does value and how does value intertwine? So, of course, I pulled up the dictionary on this and said, OK, this is exactly what we had just talked about. It's in regard to something that's important or of worth to somebody. And then the second one is, and this is the interesting one, is it interacts with our own value system? That's why certain applications work really great in the United States. But if they don't fit the values of India and it's the same application, it fails miserably. So there's another interaction, another core level of the things that are coming together on this. Now, I put this definition up to one of our executives and they couldn't comprehend it. They couldn't comprehend how it fit in the business. And they sent me out of the meeting. Don't you ever talk about value anymore? Come back in here so that we can have a meaningful conversation. And so with that, I started thinking about what lexicon we had. How did we actually define value itself? And some of it actually starts from our corporate value system. Does anyone, can anyone share with me what their corporate value is, one of their main values are? Okay, those are good. How about others? What's that? Customer focus, customer orientation as we called it until. How about others? What's that? Honor. Ownership. We want to take ownership and we need to drive that ownership. Those are all great. If you notice, some of these though are very internally focused on my behaviors versus what we're actually delivering. And if you look at what this quote that came from Nintendo, I thought was really great. Because what they said was, yes, we are a game development company, but we develop games for everyone. Which means that if you, anyone play Mario Kart? Yeah. They make that so that if you're five year old to 99 or 120. And I hope to be playing at 120 Mario Kart or something else. But they, their whole thing is it needs to be fun for everybody. It's their motto. It's how they review things. And those values, by the way, the reason why you bought the, you know, the latest version of Super Smash Brothers is because you already know that they've got your back on this. And you're just clamoring and waiting for the next version of it to come out. Another example, and I don't have a picture of it, is a company in the United States called John Deere Tractor. They changed their corporate values to from deliver tractors to feed the world. See how that fits in your, suddenly your brain has to expand a little bit to go fit that in. Okay, well, we're a tractor company, but now our mission is to feed the planet. How do we do that? And what happened is is that simple change of language, simple change of focus of where the major value was being delivered for the company is that their cells went up, employee satisfaction went up, and they developed one of the coolest tractors I've ever seen demoed. They literally can plant a seed within a one inch by one inch square. GPS controlled tractor can come in, plant that seed, and a week later they can come in and plant another seed right next to it, and they grow crops in two different levels, and they're able then to go slice one off one week and then go slice the other one off in another week, so they're increasing the yield of an acre of land. Pretty amazing stuff, just by that simple shift in language. So we lacked a language to talk about things inside of Intel. So a group of smart people got together, one of them by the name of Eric Simpson, he came up with this, well wait a minute, most of our conversations are sitting in three different areas. They're sitting and talking about the business side, which is the economics, the technology side, which is the implementation, and the conceptual side that was talking about the usage, but most of those conversations were all off on their own. They they seldom crossed over. What we did have a lot of conversations on was this business to technology conversation, the delivery of something, the ingredient, and what this, what we saw was is that we had lots of discussions that were over here about supply chain, and we had lots of methods by the way in that space as well, and I'll show you a picture of what those methods looked like in a second, but what we didn't have a lot of conversations in, and when we defined value, how could we codify this where it's something that everyone can understand? And what we came up with is value is a promise that a company extends to its users, whether it be for free or whether it be for some monetary value, and by the fact that they purchased it and they got that product and looked at it and it met their expectation. That is value to them. We fulfilled a promise. We said this was in our product, it was in our product, and it worked, and it worked well. So just by having that one discussion about how the value meant for us as far as how did that interact, we suddenly started to have some really cool types of discussion about, well, usage is about desirability, usability, and also usefulness, these conceptual values, and then we suddenly started to go, well, what does the business care about? It's marketable, it's profitable, it's affordable. Those words suddenly started to fill in the rest of the lexicon, and I'm not showing you the whole picture because this thing actually breaks off into even a huger lexicon, but we now had a place where we can start to talk from it. We now had a definition for value and how value interacts within our business. So then we did what all good agilists do is we do an analysis to see how are we doing. We took each post-it note, represented a meta set of methods that we actually had as a company, and what we determined was, which actually wasn't a surprise, by the way, that we had mostly methods that were about how do we manage implementation. We had lots and lots of, we ran out of room, there's another slide over here, some place with even more on it, but what we were surprised with is, number one, we actually had, if you think of the traditional business methods, we've had something that existed forever. Most of them, though, didn't adopt agile. They weren't incremental, they were non-compatible. The other thing that we found that was kind of disturbing is that we had very few and we debated whether or not that one method that was managing value across that boundary of whether or not it was truly maybe just that it really belonged in the usage, and we kept kind of putting it in and out of there. So we knew we had a gap. We had to go address this. The reason why this was important, because if you look at all of the methods that we're using, that's how we codified getting work done, and that's actually how outputs occur. From a systems perspective, a system is going to deliver exactly what it's been designed to do. So we had a system that was good at designing and implementing and delivering things, speed, efficiency. What we were lacking though is, is all the way from the front end of the process, that our mindset is we're looking at new opportunities, things that we could do as a company. We had a whole bunch of problems in our values and culture and other things. The heuristics, and I'll talk about what heuristics are in a second, but this toolkit was weak, because if I applied the agile values here, this was lacking, and if I applied the value equation that we had came up with, we were also lacking here, so the behaviors were not coming out the way that we expected. And it was no fault of anyone but our own inability to go look at these heuristics. And heuristics, by the way, are ruled the thumb. These are the things that when we're approaching a problem, that's what we reach for. It's our most powerful toolkit that we have that we say to solve this problem, what am I going to do? The lights are not working. I should test to see whether or not the electricity is on. I'll take, I'll take a knife and I'll go put it into the plug. Is that a good heuristic? No, that's a horrible heuristic. But, you know, there might be ways of approaching how would I check? First thing I do, I would look at a power cord, make sure that things are plugged in. Problem solving techniques that we've learned over time that were passed on through stories. My dad used to do things with me to improve my heuristic system. He used to tell me go to the toolbox, Ray, and go get me the left-handed screwdriver. Left-handed screwdriver. Okay. And I'd go to the toolbox and there would be like, you know, different screwdrivers in there. And I'd reach my left hand in and I'd get the screwdriver where the blade was coming out that side and I'd walk back over to my dad and I'd be all happy and he would come up and he would grab it purposely with his right hand and he would go, no, that's the right-handed one. Go back again. But anyway, these things might not be good enough to get the goal that you want, but they get us closer to the goal. I've already said that words were powerful. Words drive behaviors within organizations. Do you remember the, what I showed in the very beginning, exploration, followed by what? Developed, followed by yeah. Have you guys heard Conway's law? At all? Conway's law basically states that if you create such an animal like that you're gonna probably more than likely create an organizational structure that looks exactly like that. So we were suffering from Conway's law of people not talking to one another. So we actually redefine the words in our life cycle. And this is what they became. Opportunity, concept, candidate, solution, obsolescence. By making this one move Conway's law went out of existence for our organizations that would adopted this. Meaning, if we wanted to go define an opportunity we now had to ask ourselves the question what would, what would, how would we define an opportunity? Who would we need? What would be, do we need HR? Do we need finance? Do we need the developers? Who, who needs to be participating in framing those? Now, we didn't have to worry about measuring one opportunity by itself. What happened is, is that when we had a list of opportunities something magical occurred. We can now compare opportunities against other opportunities. And by doing that one simple act of saying that this phase of our work is in an opportunity phase it also kept these back end people from getting all wrapped around the axle because we didn't have a quality plan, a risk management plan, a whole bunch of other different artifacts that really didn't make any sense over here. So, we could actually though measure value there. As we did concept work we did several number of prototypes. We could give those prototypes to people and they can tell us whether or not it'd be valuable or not for them. And likewise, we started to drive conversations to something we never talked about. How do we end of life a product? There's a, there's a concept called core versus context. Not to have you guys heard of this. What's our core business and what's context? Meaning work comes in typically emergent. It flows into this core meaning it's our bread and butter how we make something. And then it eventually becomes context because everyone else in the planet starts doing it. It becomes a commodity. When something becomes a commodity what's the only way that we can be cost exactly. I'm not sure who said that you get a star whoever you were. The mystery voice from out there. So, we were now able to say that look there are certain things that after we've had them to solution we can start to progress them away. So, that was a big revelation for us. Then we started to put on our systems engineering hats and we started to think about well what type of, you know, we had those missing methods. What do we need? And what we discovered was is that there was a couple key heuristics that we knew about this kind of timeline. Number one, we knew in the very beginning we knew the least about something. In the opportunity phase we had no clue that it was going to take us 20 hours, a thousand hours. We just know we had an opportunity and we knew very little about it. When it gets to obsolescence we knew the most. The other heuristic that was is that we know if we know very little about something we need to learn very quickly. Meaning we need methods that have very fast feedback cycles over here. Versus at the end, slower feedback was okay. So with that mindset we started to think well what methods do we have in our toolkit? And what we discovered was is that we already knew how to do this sequential phase development waterfall and we developed some strengths in how to go do incremental delivery through scrum. But what we were missing was response pattern. The way that we would be approaching all of our projects would be in this since analyzed, respond decision process or a since categorized response process. You would watch people and how they would do it. Meaning they would analyze a bunch of data and they would respond or they would look at existing norms and then they would respond through that. What we were missing over here on this other side was really small short experiments as Linda was talking about this morning. How do we experiment our way when we have very little we needed to create safe to fill probes and safe to fill probes doesn't have the same decision mindset that we would have later on in the environment. And so we had to create methods that did an act since respond pattern and a probe since respond pattern. We needed more of those to come into existence. Does that make sense? Yes. Time to market? That's a good question. It's called a due date. It's we need to have some product by this particular date or it will not be in the store by Christmas or it won't be in the store by IT refresh or it might not be there for all these different market windows. We knew if we missed that window there was not enough time to manufacture it. Exactly. But we learned a whole bunch of stuff along the way when it had to happen. Meaning we learned that we had some areas that we in fact didn't understand our capabilities that we needed to build. So these methods though that we were using these frameworks and other things we actually had to go expand to a new set of frameworks. And primarily these were the ones that were the most that we used. Three circle model I already showed you. Something called Cannevin. Cano model, safe to fill probes and solution mindsets. I'm going to go ahead and explain two things today. But at a very high level detail I encourage you to find me after class if you want to learn more about them. The Cano model was something as we were defining value how could we go off and understand whether or not something was valuable or not. I'm not sure if you guys realize this. If you meet the minimum number of features for something in VP the most you're going to get is a customer going to deliver that. Example, anyone staying in hotels? Right? What's the minimum viable product of a hotel? What do you expect? A bed to sleep? A clean room? Wifi but you're from the states man. Expected. These are things that are expected. What happens if you get into your room and there's no bed? Do you stay at that hotel? No, you call down could someone please bring me up a bed? But it's expected. It's expected to be there. If it's present you probably don't care about it. It's like okay, it's just like another room. But I can tell you at this hotel they put chocolates in my room. Somebody snuck in and I don't know when they did. I literally walked outside. I came back in and then suddenly my bed was folded down. There was chocolates on my pillow and I'm like chocolates and I was tweeting about it. I was like this is great. I'm excited. I've got something that differentiates it. And what we have to do when we're looking at opportunities is we're trying to weed out what those exciting things are because we want people who are out there saying take my money. Why would I stay in this hotel versus another hotel? It's just a commodity. I need to go figure those things out. So our MVP group to not just having categories of just line items of just we got to go produce that because everyone else has it how do we mine out those excited and use those as the covering point of how we push products and not push products in the way traditionally you would think. We wanted our customers to grab us by the shirt and pull that product into existence. I'm going to skip Kenevan just a matter of time but I want to talk about safe to fill probes real quick. Is that safe to fill? Maybe. I don't know. It could be a good method. Is that safe to fill? Probably not. Definitely not that. I wouldn't go there with the clown. But failure and this is something that Linda was talking about earlier today. To change our definition to an early life cycle work in those early methods we had to actually take and say what does fail mean to us? And by the way when I was looking for pictures of this guys I could not find any pictures of women doing stupid things. The only thing I could find was pictures of dudes doing things bad like this. I mean like these guys. I mean come on couple flip-flops and a power click. But safe to fill means that we're going to minimize harm. Harm to our business, harm to people maximize learning and whatever we do it's going to be an emergent thing. Whatever comes out is going to be exciting when it does. Or it could be ho-hum, it could be anything but it's a learning process. This is an example from Angry Birds. The guys who invented this they had so many different experiments and games they almost went bankrupt and then they recovered themselves and then they had one product that actually resonated. Lots of safe to fill experiments and basically they came out the other end hopefully doing good. Probe structures and this is what a safe to fill probe looks like. We do set a hypothesis. It's some scientific that we say we think we'll learn that. We do, we monitor, we measure and we learn and we refine. And that's how our safe to fill probes work. We looked at naive, designed to fill, coherent different ways that we can not just do one experiment but do multiple experiments around the problems. Give you one example as I wrap up is we had a digital health team that said this fix that we need to go off and do is going to take us six years to do or something like that. It was some big number. We had to totally redesign the product. So we actually did a naive experiment. We told the engineering team to go to a shopping mall because the target market for this product was these senior citizens. We said talk to a senior citizen tell them about the problem and have them give us their way that they would fix it. And what it occurred was they came back and they said we're kind of embarrassed. All we have to do is change this one feature up here and we could do it within a week. Just by simply executing a naive experiment they basically were able to cut off the entire back end of this big long development cycle that they were going to do. Just by setting up a different experiment. Much time there? Five minutes? So, safe to fail probes when we have them we're looking at how do we then if it succeeds do we know what the signs of success would be? So when we were filling out these experiment cards we would ask ourselves that question do we know would we know the signs if it failed? Likewise if it failed how could we dampen it? Meaning how can we destroy the experiment? Meaning we don't want to continue keeping it we just want it to go away. If it succeeded how did we amplify it? Scale by the way the proper use of that is amplification. How do we make something bigger that can support more? Did we have ways of harvesting the knowledge from it? And then the last one they didn't have a deadline safe to fail experiments were about one day's worth of work. Sometimes they were two to three but we wanted them to be short and concise. The deadline was important because if you look at deadlines what humans are really bad about if you give me no deadline I will put as much exotic stuff together and I would just continue to go play the heck out of whatever it is I was building as an engineer. But I can tell you that like on my slide back here I knew that I had a delivery date of a particular time it had to be done by a particular time in order for me to present to you. So deadlines help gain focus within your organizations don't think that deadlines are something that are awful they're actually good In closing there's a couple things that I also learned along this journey. If you get a chance to read the discussion of the method it's a book by Billy Von Cohen it's out of print but you can get used copies of it. The thing that I found interesting about this book is it actually defines something that I never thought about. When I walked through the door you guys all go hey that's the guy who worked on the 286 microprocessors or hey he worked on USB he's actually one of the guys who actually brought you Wi-Fi Centrino we enabled all the hotspots across the planet you didn't know that right before I came through this door what I am known for is that I basically am able to go find the best possible change every job that I get they look at these three qualities of myself and that's what gets me my next job I know how to get the best possible change I know how to use the available resources that are in my myths and I can deal with environments of high degrees of uncertainty and in the case of Intel high degrees of politics anyone from Intel here by the way anyone from Intel legal in particular okay but dealing with those things this is what we do well in pushing value and helping value come into creation the methods I hope today that I showed you give you a little bit of insight I understand in an hour we can't possibly go dig into all of the methods and everything else and what I invite you to do is to basically look at this from one aspect number one I have to say this in every talk that I do agile is not destination business agility is not your destination either it's how you create value for your customer is your destination and the method that you choose from early life cycle all the way through this true business agility is about looking at the systems that you have and starting to understand how do I fill in the gap of weak things that we have around us weak things like having a poor ability to measure something like value not having common definitions other things that we can get large groups of people to kind of just get together and work together more effectively and with that I'm done is there any Q&A time that they have to go on yes it can work for both so the question was just safe to fail only work for new or can it also work for existing it actually works for both because the have you ever done planning poker in your agile it's when one thing that bugs me the most is when someone says 100 when reality is it doesn't mean 100 it means that I don't have a clue yeah and so in those particular cases I would be safe to fail probes I would not launch a sprint on an incomplete story I would launch a safe to fail probe to write a better story make sense well you guys are easy thank you you're a great audience