Lean vs Agile vs Design Thinking

thanks for coming it's gonna be a good talk I think you're gonna like it it's gonna be fun I'm really happy to be back here it's my second time in Malmo I was here the last time I was here the Eurovision was here I don't know if you recall I was a few years ago it was a lot calmer in the city this time around then it was the last time it was a lot of fun I'm gonna tell you a story this afternoon about lean agile and Design Thinking my background is in design I've been doing a lot of work in the agile space doing a lot of work in the lean startup space over the years and I've seen a lot of of the attempts to make these ideas work well together I'm gonna share some of those ideas with you today give you some things to take home some practical tips that you can use hopefully to make your team's be more successful build better products satisfy your customers needs and ultimately build better businesses that's the goal but to get started I want to tell you a story about my favorite movie always a good place to start my favorite movie is Goodfellas how many of you have not seen Goodfellas I don't have that kind of time we don't have two hours to sit here and watch it and then talk about although we sure that'd be a great presentation Goodfellas if you don't know it's one of the quintessential kind of American gangster movies right fantastic movie with an amazing cast and great lines there's it's a movie filled with great scenes and great dialogue but this is my favorite scene in the movie now you have most of you haven't seen the movies which is kind of so I'm gonna spoil a little scene for you just one one tiny bit of the movie so what's happening in this scene so this is um you've got Robert De Niro obviously you've got Ray Liotta there on the left and you've got Joe Pesci there to the right of Ray Liotta now they're gangsters and they have a problem and it's in the back of ray Liotta's car that's where the problem is and they're stopping in late at night to Joe Pesci's mom's house that's Joe Pesci's mom to pick up a knife a big butcher knife that they need to solve the problem that's in the back of ray Liotta's car that's what's happening in the scene now it's late at night they stopped in and she wakes up it's an Italian household she says no no you gotta stay and eat you can't just come in and pick up the knife and go you gotta stay you gotta have a meal you gotta eat so they sit down they're having this late-night meal and as they're sitting around and having a conversation late at night the conversation turns to this painting and she it's her painting she painted it and she passes it around the table and as they're talking about it Joe Pesci says what is one of the more memorable lines in a movie filled with memorable lines and I have a clip of that third 30-second clip of that what he says in this particular scene here's what he says listen my painting what do you want from me all right so if you haven't seen it Elyse you have a teaser now like the whole movies like this it's fantastic you never left see it look he says I just won dogs going one way one that's going the other way and he got this kind of middle said hey what do you want from me right I'm from New Jersey by the way I can talk like that and look what does this have to do with software development you might be asking yourself well first of all that's not my presentation I'm sure what's happening there but that's fantast op and it's lovely it's not really clear what happened to my it's back now so you might be asking yourself what does that have to do with software develop so I was working with a client of mine a client uh in in the u.s. happened to be a bank in this particular case it's a big bank and I was dealing with one of their transformation managers you know all the banks are transforming these days they're all becoming digital companies right and I was talking to my client and he was he was in charge of transforming his cross-functional development team into a modern software product development team and he said look I'm teaching my tech guys agile I got one guy one dog going one way right I'm teaching my product folks lean and lean startup in the enterprise going the other way right now in his particular case yeah she had a third dog yet his design team design teams go in third ways like I'm teaching them design thinking and this magical synthesis this nexus of process and collaboration and shared understanding and language and and amazing product success isn't happening they don't have a shared language they don't know how to work together they have different rhythms different Cadence's and they're not you know that this this amazing burst of creativity collaboration agility isn't working and I'm here in the middle said hey what do you want from me I trained everybody and all the modern stuff right I got agile training I got product management training I got designer design thinking training and it's just not coming together and I can't figure out why this really got me thinking to understand because again you know in all respects he's doing all the right things in this particular case right and it got me really thinking about the problems that he was trying to solve and what he was doing in this case and what I see happening in a lot of the organizations that I work with is this is that we try to fix everything with process right we've got this these process hammers right the agile process hammer it doesn't work hit it with the agile hammer right doesn't work hit it with the lean or the Lean Startup hammer I've designed thinking we got a design thinking hammer now let's just hit it with the design thinking hammer and and hope that it will make things better right we have this sense that if we just apply the right amount of process everything will start to work better than be better collaborations better conversations with the ultimate goal of building better software for our customers and the reality is that this isn't true so how do we get around this now as I was thinking about this it dawned on me that startups don't have this problem right startups generally have a small amount of people right and so there's no real deep discussion about are we agile are we lean are we gonna use design thinking right everybody's working very quickly to make sure that we don't run out of runway because if we make enough wrong decisions enough times we will run out of runway and we will go out of business but some startups get lucky and they find product market fit and they scale and they grow to become larger and larger and larger companies and as the companies grow we have more options with more choices because we have more money first of all we can hire specialists whereas before we could hire somebody who maybe could do two jobs now we can hire individuals right we can build larger teams and it feels like we have seemingly endless runway like we can just keep going forever because generally speaking as the companies get larger and larger and larger if you make enough must if you make mistakes nothing really happens very rarely to someone actually get fired even in the United States right it doesn't really happen if someone gets fired for making a big mistake and and most importantly larger organizations assume they already know everything we're big or successful we're the market leader right why do we have to you know to do anything differently at this point look how big and successful and market leading we are right and yet and yet in all of my travels and I work with companies around the world I see this all the time these talking heads we want to be lean we want to be agile we want to recapture that innovative spirit we had as a start-up we seem to have lost the speed the time to market I don't have that phrase resonates with you right how do we recapture that how do we bring that together and the interesting thing is that if you read the material on lean and agile Design Thinking it seems to focus on a single team right here's how you make your team agile here's how you make your team lean or apply Design Thinking to a team but when you take those processes and you stretch them to larger and larger and larger organizations to more teams five teams 15 50 500 teams they seem to break and so the question is why so to answer the question why I did some scientific research and my scientific research I mean I asked Twitter that's it I just posed the question to Twitter that was the extent of my scientific research and these were the answers that came back these were the themes that came back from my scientific research exercise my Twitter research exercise right these were the themes and these are to be clear I got a lot more answers than this but these are the themes that I see consistently with every organization that I work with right we already know what we need to do why do we need to waste time learning again we're big we're successful or market-leading let's just ship more software process everything has a process eighty-five approvals and a mysterious VAE that block anything that's not the old way of working that seems to be a big deal particularly in larger organizations lots of upfront planning if we don't write an 85 page business case for this thing no one's going to approve it or fund it so we have to in and then we have to live and die by the numbers that we put in that business case and by the date that we put in that case as well silos rights and no collaborations developers not talking to designers designers not talking to product managers and so forth valuing business need over user need and not realizing they're the same thing so short-term gains right not actually thinking about who's the customer what are we trying to make how are you trying to make them successful and then lastly worrying about our brand right that seems to keep companies away from these agile and lean practices it's scale because there's an expectation of a level of service and if we put out lighter weight less functional products maybe less polished products that may damage the brand and we don't want to do that now the interesting thing is that when I started down this path there wasn't a lot of material about agile as I told you it was kind of its scale it was focused on on individual teams but today as you start to look and to try to out there if you're any kind of a leadership is team leadership position or organizational leadership position and you're trying to figure out how to build this collaboration and how to build as collaboration and scale there's no shortage of recipes out there everybody's out there trying to sell you some kind of a framework that will allow you to then scale these practices and build that kind of collaboration and perhaps there's no better better visualization of that framework of those options than this chart now look this chart is terrible and in fact the first time I saw this chart I felt like this right and you should too look this chart is terrible not because of the aesthetic choices that this designer of this our consultant made now look by the way if you haven't seen this before what this is is well it says it it's the agile landscape version three by the way so maybe there's a version four he caught a lot of crap on Twitter for this particular chart but look an unjustly so I believe this is a terrible chart not because of the aesthetic choices so what's happening here if you can't see it every one of the stops on this London Tube map style illustration is a technique that's broadly discussed or used in the agile world everything is on your scrum extreme programming Kanban five wise design sprints spikes literally everything everything is on here right now the reason why this is a terrible chart is not because of the aesthetic choices that this consultant made it's because it's true right these are your options you try to build a better collaboration like my client right he went out into the world and he's like okay here all my choices I chose the three things that seem to be the most relevant the most popular and I tried to put them together and it didn't work right and so the question that become is how do we get away from this right and into a more tangible practical way of building better collaborations between software developers designers product managers and ultimately building better products and services for the people that we service okay so let's talk about this for just a second so what's a jewelry about it's not gonna be a crash course in agile like I promise you does that me geez sorry let's not do that again agile was conceived by seventeen software engineers on a mountain in Utah at high altitude where the air was thin 17 years ago as a bid to you know to overcome this frustration that they had with software development it was unpredictable it was complex it was difficult to meet customer needs it was difficult to predict budgets and deadlines and they figured there had to be a better way and so at the end of that long weekend on the mountaintop they descended biblically from the mountain giving us the agile manifesto now the agile manifesto if you've read it and it's sure you should read it it doesn't say things in there like you will stand up every day at 9:15 for 15 minutes right none of that crap is in there right it really doesn't it doesn't it's a philosophy for work it really isn't it's a good one overall and perhaps the most important part is this piece they're just saying look software development is complex and unpredictable okay as you start to build stuff you will learn new things or new things will happen in the world as you discover that change if it shifts the plan that you originally made for the product that you're building change course that's it that's agility in a nutshell like we could end the session here you can go home and say I learned what agile is it or a def right but that's literally it you make a plan you start to work and as you discover new things if they disagree with your plan you change the plan that's all these guys we're saying is that we work differently and yet what's happened is that most organizations have taken the agile process and they've productized it and they bring it in and they hire it for a different purpose not for agility right not for responsiveness but to create more high quality code faster that's why most organization to bring it for productivity for efficiency right that's why most organizations bring in agile right because there's this belief right that this is what software engineers have to be doing all day long right literally there's it can be no break if a software engineer steps away from their keyboard at any given moment right bad stuffs gonna happen really bad stuff and why right why because this is what we care about making the software right velocity that's what we optimize for that's what that's what's happening right the spirit was learning agility responsiveness the reality is this let's crank out features right high quality features as fast as we can and there's this belief that the more features we make the more value we deliver right and that's one of the things we have to get away from right because the reality is this just because you can build it does not mean that you should for example the airplane that got me here has and fewer wings than this airplane and it worked just fine right to get here as well so that's that's you know start to think about agile that's kind of where we end up let's talk about lean for a second lean is fantastic in that lean if you take it again in spirit I'm gonna give you a 30-second conversation around lean you know there are volumes like this thick on it so forgive me if I cut this short right but basically the the guys at Toyota we're struggling with a production and quality issue right they were dealing with a post-world War two Japan when you've got the American car manufacturers like GM and Ford producing tons and tons and tons of cars Toyota says look we can't compete on quantity so we are going to compete on quality efficiency and variety and to do that we are going to completely turn the manufacturing process on its head now what they're doing here is they're saying look traditionally car manufacturing is a push process push means we're just gonna make a product and push it onto the market and hope that people use it we can't afford that because if we make stuff that people don't buy or don't use we go out of business so they turn it on its head they say look we're gonna make a pull model a pull model simply says we're going to look for signals from the market that tell us what to make when to make it where to make it and how much of it to make and then we're only gonna do that and all that stuff in the middle is waste we're gonna minimize that because we can't afford it and along the way we're gonna trust our people the people who make the product the people closest to the product to make the tactical day-to-day decisions because they're the closest of the product they have the the the most feedback the most understanding of what's happening here we're going to empower them to make those decisions that's what lean does and what and the amazing part here is that lean if you if you started to try to combine lean and agile together it should put a brain on that agile delivery process because it infuses this concept that you can't predict the future right that's what Lean Thinking is about it's about we're moving from that position of doubt to a position of certainty always and to reduce the risk of going too far in the wrong direction we work in small batches Sprint's iterations short cycles help us get there and move forward more quickly and so we've got that now Eric Ries did a nice job in 2011 by talking about this in Lean Startup he said look start asking yourselves for everything that you're working on not can we build it but should we build it right do customers want it will they pay for it and if so terrific then we can try to scale it and build a business around it and we can run experiments to learn this the problem with Lean Startup particularly in high-growth companies and large companies is that nobody wants to buy experiments they want to buy apps they want to buy systems and so we're dealing with that now the last thing before we start to solve all this stuff is Design Thinking right super popular digging a lot of companies this is what most people think it is can't do design thinking without the post-it notes some people think it's this crime we lock ourselves in a room for a week generate some creativity it's not any of these things it's this it's simply saying look designers have some tools for solving design problems let's take those same tools and apply them to business problems right and this stuff should sound familiar to you if you know anything about sort of the core principles of agility and the core principles of Lean Startup like we want to empathize want to understand the customer what are they trying to do want to define solutions we want to id8 on those solutions create some some variations we want to prototype and test them and then based on what we learn we're going to baby productize if some of these things or build them right we talked a lot about that now the nice thing is that at least two of these things work well together the design thinking process fits nicely into the Lean Startup build measure learn loop it's the learn piece it's in there right how do we learn we we do all this prototyping and that type of thing and then organizations right try to bring this in together with the agile piece as well and this is where it starts to really struggle because we're trying to mesh these three processes together that have different languages and different Cadence's and different measures of success this is where my client was ultimately struggling at best this is what I've seen customers do they built some kind of a Frankenstein process that is you know kind of works and is kind of weird and awkward and make some weird noises right but doesn't really function to the best possible ability so the question is how do we bring these things together well most importantly we need to integrate the principles of these ideas not the processes try to layer these processes on top of each other ends up in that Frankenstein situation but the principles the principles of agility the principles of Lean Thinking the principles of design thinking work really well together I want to share with you ten of those principles in the time that I have left and tactics for each of those principles to help you at least think about this when you go back to work think about how might we change the way that we work to apply some of these principles because this is the way that we should actually be working if we're looking to build customer centric successful services products right and then ultimately businesses around that let's start with this one principle number one customer value and business value are the same thing it's true you make your customers successful you respect their time you help them achieve their goal but make them better at work make them better in their home life get them home to their kids football game on time right they will reward you they'll tell their friends they'll tell the internet they'll tell their boss they'll buy more stuff from you ignoring customer value and optimizing for short-term business value is risky and can cost you the success of your company let me show you a recent story Gibson guitars is out of business you guys know that it's really sad they went bankrupt Gibson guitars noticed a shift in the market place no one was buying guitars anymore right drastic drop-off in sales and so they brought in a new CEO the CEO was all about innovation right all he wanted to do was velocity let's make more stuff more innovative pedals more new technologies new fancier guitars integrated with those technologies and they push that out there and they pushed all this innovative stuff out there for the sake of innovation not because any customer was actually asking for it and nobody bought it and they went out of business and they continued to focus on the things that made them successful to this point right we're big we're successful where the market leader why would we change our approach to our business and this is what the Gibson guitar website looks like today now what they fail to recognize is that yes sales were dropping off but there were new buyers coming on and 50% of those new buyers were women and women generally speaking don't care about / what they care about is buying guitars that fit them guitars that they can play and learning how to play this is Fender guitars website fenders thriving they're doing really well they paid attention to the market they empathize with their customers and they're building products and services that actually meet customer need they're delivering customer value and their business is thriving by paying attention to what's happening in the marketplace they're adjusting the way they deliver that value through code through product through service right and they're thriving and succeeding and what they're doing here is they're taking a user-centered perspective on the success of their products and services right not a feature centered perspective right but a user centered perspective how are we making our customers more successful right who are the customers and what are they trying to do and what this lens ends up doing is it changes the definition of done if we're talking about the agile language right it changes the definition of done from output making a thing to outcome changing customer behavior that's our new definition of done right did people buy more stuff did they learn how to play guitar if so are they coming back and telling their friends that's what we're looking at and it's these outcomes that tell us when we've delivered customer value and most importantly it's these outcomes to tell us when we're done when do we move on to the next thing when do we stop working on something right how comes help us and do that and that's one of the key things to take away here is that change in customer behavior is our measure of success that's our first principle customer value and business value are the same thing principle number two working in short cycles right upfront planning trying to predict the future trying to understand exactly what the software will do when we're done and how people will use it is an exercise in frustration and mostly futility when we do long term product planning and roadmaps right this is what we're asking our product development teams to do this is what we're asking our software engineers to do our product managers and our designers they try to just divine the future right but we build iterative continuous systems we don't know what it's gonna look like in the future and we don't know what the competition is going to do and we don't know what our customers are gonna do with these products and services by working in shorter cycles we learn more quickly and I want to be clear by shorter cycle I mean anything shorter than what you're doing today so we can look at the digitally native companies like Amazon and Google and Facebook and see how how often and how regularly they deploy code and that's fantastic for inspiration but if you work in a bank and it takes you six months to ship something today and you can get it down to three months that's a win right it's twice as fast as you were before that's good and our goal with these short cycles these Sprint's these iterations is to collect evidence right if we're moving from doubt to certainty at the end of every cycle we look back and we say hey does it still make sense to be working on this is the feedback from the market from our data from our team's from whatever right this says saying that this is still a good idea if so you get to take the next short cycle forward nothing next nine the next one right and if at any point at the end of the short cycle we retrospect we reflect and we say hey are we still headed in the right direction are we still making sense right if the feedback says no this doesn't make sense anymore then we have to change course that's agility right that's the thing that we talked about at the beginning right shorter cycles means lower investments means lower risk means it's easier to change course right and as our friend the richest man in the world likes to say the great thing about fact-based decisions is that they should overrule the hierarchy right we're collecting evidence at the end of each one of these cycles and we try to make evidence-based decision-making based on customer behavior to help you do that let me give you the two key questions I teach every team that I work with okay at the end of every cycle as you're planning your next cycle ask these two questions okay first is this what's the next most important thing we need to learn not ship learn right that's a that's a very explicit choice there what's the next most important thing we need to learn what's the where's the risk in the thing that we're building and look sometimes that's going to be market risk or user risk or design risk other times it's going to be technical risk all of those conversations are important right what's the next most important thing we need to learn and then what's the least amount of work that we need to do to learn that right how can we do risk this the fastest so that we don't spend four cycles or ten cycles to find out that it we shouldn't have done this I said we spend one or two max right those are your experiments does your MVPs right those are the things that we put out into market to understand how well we're going to solve this particular business problem okay principle number three retros and I told you that that the manifesto doesn't have this like you will stand up every day at 9:15 kind of stuff but it does talk about retros and retros are great right retros allow you to kind of look back on a short time frame and just talk about hey what worked well right let's keep doing that and what didn't work well let's change that right we talked about there's a thousand ways to do them right there's this this is I use this one a lot I found this one on the internet I like this one I've done I've done these the 4l4 ELLs retro whatever it takes but the framework ultimately doesn't matter the conversation matters right and the conversation has two purposes for retros first you're going to make the product better what did we learn as we shipped product as we got code into users hands and what's different about that and then second we're going to improve the process hey last week you know took us forever to get the designs to the developers right and by the time they got it there was no time to implement the design to its fullest the designers repairs the developers were pissed what do we do about that next time right if that happened for a one week sprint or a two-week sprint okay right as long as we tried something different the next time that happens for ten sprints in a row retros help you undo that kind of stuff okay principle number four go and see right this is there's all kinds of names for this going going with the gemba you hear this from from lean folks right Tom Peters famous business management guru talks about managing by walking around right managing look if you're not a manager forget that managing buy and just leave the walking around part right walk around the office see what other teams are doing right see what's working for them right how do they structure their their meetings their Cadence's their practices and then amplify the good patterns bring them to your team if you manage some teams bring them to multiple teams and don't worry about the labels if something works inside your organization it makes people productive more collaborative it builds that shared language I don't care if it's lean or agile their design thinking who cares if it works amplify those patterns and do that but just walk you'd be amazed and it's particularly you've got a big office right what people are doing in the corners they're building really interesting practices you can learn from them and amplify those patterns principle number five test only your high-risk hypotheses remember I told you what do you need to learn first what's the least amount of work that you need to do to learn that the least amount of work you need to do to learn that is your experiment now look we rarely if ever have a hundred percent budget for learning right we have to ship efficient product bit to ship code how do we test the most important things that look hypothesis statements are our best guess about how we between how we solve a particularly thorny or risky business problem for our customers right and so we believe that we can change behavior if a specific customer base gets some kind of a benefit from a feature that we want to build right if you were to fill this out it could look something like this right we believe that a 50% increase in retention right that's a change in customer behavior will be achieved if college students have more time for school work that's their benefit right with a food delivery service from the University cafeteria right that might be a good idea it might be a bad idea right but these are our hypotheses we're gonna have a lot of these as we look to build new products and services for our team but the problem is is you can't test everything because we have to ship stuff as well and so I like to use this framework to focus on which hypotheses you should actually test how to focus your learning if we're gonna build lean thinking design thinking into our agile processes right we've got to focus on the most important thing we need to learn next the hypotheses that fall into this quadrant the quadrant of high risk and high perceived value to be clear it's perceived because you don't know you think it's a good idea but you don't know because you can't predict the future right and risk again is going to be contextual might be technically challenging it might be a business risk or an adjacent market or whatever it is the stuff that falls into this top right corner that's where your learning activities go that's what your design thinking your Lean Startup your research your discovery work right those are the things those where you apply those processes right because if something falls into this bucket high risk low value just throw it out don't work on that if something falls in the top left if you believe it's high value and it's low risk just build it right the stories put it in your backlog write the code ship it right and if your hypotheses fall down here in the bottom left you certainly don't need to test them in most cases you don't even need to build them there might be some table stakes stuff stuff that you have to have to run in your to operate in your market or in your industry but you certainly don't need to test that so if you're gonna build lean lean startup design thinking UX research into your agile processes focus it on the high risk high value hypotheses next one of the most important things that I've learned in my career do less more often it's one way to harness these new process these new ideas of agile and and again Lean Startup and so forth into a way that that everyone can accept regardless of what they do on your team right so instead of trying to do a kind of a massive discovery phase upfront or a big design phase or a research phase upfront right we do less we do a much smaller scale effort we just do it more regularly because we've got this time box that repeats itself every week or every two weeks right I'll give you an example I spend a lot of time in the first half of my career doing traditional research sitting on the other side of the one-way mirror eating a lot of candy for two days and if you ever if you ever done that I don't if you have but I can tell you and you know ten people come through on the first day ten people come through and they test your product for you on the second day and I guarantee you that by the end of the first day you know everything that the people are gonna say on the second day right complete waste of time if you're doing if you're doing good good work instead right again coming back to this question what's the fastest way to learn the next most important thing and we can run these experiments based on what do we need to learn next what's the fastest way to do that let me show you some examples the echo in this particular case Amazon realized that the most important thing they needed to learn next was what are people gonna ask this thing and what's a good answer right voice interface that's probably good right now look Amazon is good at writing code and deploying code and shipping and regularly they could have just written stuff and seen how it works instead what they did was they ran an experiment they did less more often they built what's called a Wizard of Oz where they put a customer with a fake Alexa in one room and a microphone and the customer would talk to the Alexa and ask it questions and in the room in an adjacent room said an engineer with a laptop and he heard those questions and he would type those queries into Google get the answer and then speak those answers back in a microphone so it feels like the Alexa is answering your questions right the reality there's nothing there they did less and they do this kind of experiment experimentation more often they're learning right based on the most important thing they need to learn next right here's another great example I love this example I came across this just this year yes know what's happening here that's right testing self-driving cars this is Ford Motor Company Ford Motor Company's been building cars for a hundred years right what got them here is not gonna get into self-driving cars integrated software integrated Hardware right the most important thing they needed to learn and the fastest way that they could do that was by disguising this guy as a car seat they put him behind the wheel and then they put him on the road why right to learn the next most important thing which was how will people react to a self-driving car right because look they could have written the code they could have built the hardware they could have integrated it all and hoped that it would work but the results here could be tragic and so instead they did less more often right they did product discovery to unto test their highest risk hypothesis which in this case literally involved a costume that was it right again principle number seven working as a balance team this is the one that gets broken again and again and again and again and it's like book after book after article after blog post after conference talk talks about this and it still happens so rarely teams successful modern software development teams are small six to ten people okay smaller teams are more accountable they're more agile they move more quickly there's no hiding in a small team okay successful modern product teams are dedicated they work on one thing at a time not three everybody on the team works on one thing at a time some reason it some reason organizations across the world seem to think that its engineers can only work on one thing at a time but designers and product managers can support multiple projects at the same time dedicated teams much more successful co-located ideally I know the previous session was about remote teams right and I recognize that this is our reality today co-located is best if you're not co-located then use the tools that you learned about in the last session but in all in order for the tools to work you have to be awake at the same time right so that's the key here if you're not co-located overlapping time zones okay cross-functional teams all right all too often I hear about the developer team right or the delivery team and the discovery team right those need to be the same people product design engineering working together on the same thing at the same time it's the only way that collaboration works otherwise it's just waterfall we're just handing off to each other over time any way you slice it and again just like the lean folks taught us we want to make our team's autonomous and empowered if we're working in short cycles if we're learning if we're if we're iterating every week or every two weeks so what if we get it wrong right we don't need to micromanage these folks if they make a mistake they'll find out at the end of that cycle and they'll course correct that's the whole point of this way of working we have to let our teams do their jobs and make the tactical day-to-day decisions so they don't have to run it up 85 approval levels to make that happen and it's amazing what happens this is when you do that I am this is an award that I got in the early 2000s from my team I worked on a browser at AOL back because we were working across I was a designer in case you're wondering still am right I've working with my engineers and I got a rogue developer award for inspiring undocumented creativity and engineers why because we talked to each other right and we shared knowledge and we were on the same team working on things at the same time so it was a bit of a joke but again it makes the point three more things principle number eight one of the most important things that you need to be clear about is radical transparency as an organization how do you build transparency about what we're working on why we're working on it how we're doing and what success looks like if you can build that into your team's into your team start with your team and then scale that out the collaboration is better people are far more engaged in making the customer successful and there's lots of ways to do this rituals work really particularly well this is the Karate Kid please how many of you have seen the Karate Kid all right good we don't have to explain this one too much but really quick sobering fact Ralph Macchio Daniel son he's 50 years old today hits home a little bit anyway Daniel son comes to mr. Miyagi says hey I want to learn karate mr. Miyagi says that's great paint the fence he said I want to learn karate says that's terrific wax my car unbeknownst to Daniel son he's learning karate right he's waxing he's getting emotions right rituals particularly the scrum the agile rituals work really well to teach teams transparency if you just want your team's that be transparent and be like all right whatever right stand ups do stand up every day right that's the beauty of stand ups they drive transparency the team's might not know why they're doing stand ups at first right but it becomes very clear that if every day you you have to stand up I have to stand up in front of my team and I have to say to my team well yesterday I bought some shoes online today I'm going to put some money on the horses and what's getting in my way is all this work stuff right that conversation gets really old really fast right stand ups drive transparency and what the team is doing a scrum of scrums demo days demo days are fantastic you can demo working code you can demo an experiment that you ran you can demo a customer conversation it doesn't matter as long as you're showing the work that your team is doing drive that transparency in their access to customers drives transparency make sure that you seek it out and that your company grants it to you right we're coming up on Black Friday in the United States this is literally what it looks like it's actually this coming Friday it's gonna be fantastic and the reality is that the more kuffs customer access that you get the more you can get a sense of what's actually viable because of this concept of MVP permeates the way that we work and we all have a different version of what minimum actually means but access to customers tells us is it actually viable right and that's the key here is to use that customer feedback to drive our decision-making and to drive that home right the other thing that helps drive transparency in this particular case is access to data there was a conversation in the keynote this morning around Star Wars or Star Trek I am strongly on the Star Trek side so you'll see a lot of that over here but access to data is key I used to work at a company where the only way to get any kind of analytics or reporting was to spend a certain amount of hours per month in the biq the business intelligence or business insights group q right and the CEO could always jump the queue if he wanted to so you don't get you report that month you don't know how your products are doing right we give our employees access to electricity and heat and air conditioning and coffee we give them access to data everyone should be able to measure what's happening with their products so they understand how things are going that drives transparency in our decision-making two more things principle number 9 and this was tough if you're not in a leadership position then this one's tough but it's a good it's a good question to ask right what are the incentives that we have as software developers right product managers or designers as team members what's the incentive that we have because it really changes right to help based on the incentive to help us determine you know what our asses on the line for right that's the key in all of this right in other words what are you getting paid to do every every day at work are you getting paid to ship software right or are you getting paid to deliver customer value because those are two very very different things right are you there to create output period end of story as long as we get the features out or are you there to make customers successful right and in most organizations that are trying to build this collaboration between lean agile and design thinking they are asking their teams to deliver customer value and they're paying them to deliver features and those are two contradictory things and that's where a lot of this stuff breaks down so if you're not in a leadership position I would ask this question I would I would review it and I would bring this up with your leaders and your managers to understand what's driving the way that we get paid and what we're being asked to do because that's often where a lot of this conflict lasts okay last principle is this the only way that these these ideas of lean agile Design Thinking work well together is if we make learning a first-class citizen of our backlog I've worked in too many organizations where we've got sort of the real work backlog which is all dev work and then design product management research product discovery all was over here right and the teams coming in to work and they've got at least two backlogs with number one priorities on them to choose from guess which one they're picking from every single time the dev work every single time right we've got to unify the work into one place and learning has to be a part of that right and look lots of ways to do this the easiest thing to do is just to track it to visualize it the same exact way that you track every other piece of work right you make cards virtual physical whatever cards for the dev work do it for the learning work as well write down your hypotheses write down how you're gonna do that learning right what's what's the experiment what's the what's the MVP that we're gonna build assign it to someone and if you're going to estimate and I'm not opening up that can of worms ever right that's your choice but if you're going to estimate all right put that on there and then once you've done that put it in your backlog the same backlog where everything else goes right explicitly prioritize the learning work against the delivery work because there's complicated there's implications to this right anything that comes downstream from the learning work is inherently at greater risk then the things that come above it and that's okay let's talk about that and if we learn something from our learning our discovery activity right there Design Thinking or lean startup activity that changes the downstream prioritization of our work that's okay that's agility and that's the whole point of trying to build this new way of working and so to kind of summarize all of this together these are the principles that I covered and they work with any methodology right you can take the practices that work for you but if you embody these principles you start to build cross-functional collaborative teams that focus on customer value and ultimately deliver great products and services right and I appreciate you listening today and I will say thank you very much [Applause]

Channel: Coding Tech

Views: 124,456

Rating: 4.8971534 out of 5

Keywords: lean, agile, software development, design thinking

Id: _4VPfmtwRac

Length: 46min 27sec (2787 seconds)

Published: Wed Feb 06 2019