1 00:00:00,000 --> 00:00:04,700 This Workshop is about lean ux lean ux focusing on 2 00:00:04,700 --> 00:00:07,600 bridging together, design product and engineering 3 00:00:07,600 --> 00:00:11,500 and building agile teams teams 4 00:00:11,500 --> 00:00:15,900 focused on their agility. Not the process of agile and doing. So 5 00:00:15,900 --> 00:00:19,200 by building a collaboration that is 6 00:00:19,200 --> 00:00:23,300 cross-functional, and iterative and built a shared understanding 7 00:00:23,300 --> 00:00:27,700 amongst those teams. And I like to start the 8 00:00:27,700 --> 00:00:29,400 workshop with this slide. 9 00:00:30,400 --> 00:00:34,900 What it says at the bottom, there is the other day. My dog got attacked by a raccoon, so I 10 00:00:34,900 --> 00:00:38,700 set up a trap and this is what I call it. And the 11 00:00:38,700 --> 00:00:42,900 reason that I like this slide is because just because 12 00:00:42,900 --> 00:00:46,500 we are designing a product to do something 13 00:00:46,500 --> 00:00:50,600 specific to be used by a customer in a specific way. 14 00:00:50,800 --> 00:00:54,800 We really have no idea how that product is going to be used until 15 00:00:54,800 --> 00:00:58,900 we actually put it into the field and test it. For example, in this case, 16 00:00:58,900 --> 00:01:00,000 the goal was to catch a rat. 17 00:01:00,200 --> 00:01:04,900 Who was bothering the dog? Instead we caught the dog. And so 18 00:01:04,900 --> 00:01:08,200 our job as creative 19 00:01:08,700 --> 00:01:12,800 product development, people is to figure out how to 20 00:01:12,800 --> 00:01:16,700 best meet our customers needs. How to best meet our businesses 21 00:01:16,700 --> 00:01:20,500 needs, and 2D risk, the product development process. 22 00:01:20,500 --> 00:01:24,400 So that when we invest in the production of these 23 00:01:24,400 --> 00:01:27,700 products, they stand the greatest chance of success. 24 00:01:29,700 --> 00:01:33,800 And that's what this Workshop is all about. How do we do risk the product development process, 25 00:01:33,800 --> 00:01:37,900 how do we create successful delightful products that meet both our 26 00:01:37,900 --> 00:01:41,800 customers needs and our businesses needs in the most effective 27 00:01:41,800 --> 00:01:43,100 and the most efficient way possible. 28 00:01:45,000 --> 00:01:48,800 And so we're going to start the story of how to do this with a story of failure, 29 00:01:49,400 --> 00:01:53,600 and there are lots of stories of failure out 30 00:01:53,600 --> 00:01:57,800 there. One that I like to talk about is the story of plancast 31 00:01:57,800 --> 00:02:01,900 plancast is a social was a social event sharing site 32 00:02:02,000 --> 00:02:05,200 that launched in 2010. 33 00:02:06,800 --> 00:02:10,800 I believe and the purpose of plant cast was to create a 34 00:02:10,800 --> 00:02:13,900 service that allowed you to sign up. 35 00:02:14,000 --> 00:02:18,700 Create an account and then broadcast out to your social network, where you're going to be, 36 00:02:18,700 --> 00:02:22,900 what you're going to be doing and what you'll be doing. Once you're there is a, for example, 37 00:02:22,900 --> 00:02:26,700 I'm going to this particular meet up. I'm going to this conference 38 00:02:26,700 --> 00:02:30,700 and people can sign up and follow you on 39 00:02:30,700 --> 00:02:34,600 plancast can get a steady stream of the events of where you're going 40 00:02:34,600 --> 00:02:35,100 to be. 41 00:02:37,000 --> 00:02:41,900 Now the interesting part about this is that this site launched two, tremendous Fanfare and 42 00:02:41,900 --> 00:02:45,600 hype. Lots of a claim by the folks in Silicon 43 00:02:45,600 --> 00:02:49,800 Valley because the folks who launched this company were 44 00:02:49,800 --> 00:02:53,900 serial entrepreneurs, from Silicon Valley, and the company launched 45 00:02:53,900 --> 00:02:57,800 and such meteoric, rise and success. And then over time, it didn't 46 00:02:57,800 --> 00:02:58,900 live up to the hype. 47 00:03:00,200 --> 00:03:04,700 And flatlined and usage, went down. And at the end, their assets were 48 00:03:04,700 --> 00:03:08,900 sold to a larger company. So plancast still exists to some extent, 49 00:03:08,900 --> 00:03:12,800 but certainly not in the vision that it once was as 50 00:03:12,800 --> 00:03:16,000 the startup Founders, had imagined it. And what's fascinating, is that in 51 00:03:16,000 --> 00:03:20,600 2012, the founder of the company, wrote a post mortem 52 00:03:20,600 --> 00:03:24,800 about Plan cast on TechCrunch and it was a 53 00:03:24,800 --> 00:03:28,500 very detailed post-mortem that talked about why they 54 00:03:28,500 --> 00:03:29,800 failed and it's very 55 00:03:30,000 --> 00:03:34,900 appropriate, that they actually wrote that on TechCrunch, because that's exactly where they launched, they launched on TechCrunch 56 00:03:34,900 --> 00:03:38,800 and they died, essentially on TechCrunch, and I've pulled a series of 57 00:03:38,800 --> 00:03:42,200 quotes from that post-mortem that talk about 58 00:03:43,000 --> 00:03:47,900 what didn't go well in the execution of the vision for plancast. And the one thing I 59 00:03:47,900 --> 00:03:51,900 want you to keep in mind as you're going through these quotes, is that the team 60 00:03:51,900 --> 00:03:55,600 worked for five months before they launched a single 61 00:03:55,600 --> 00:03:59,600 thing, into Market, five months of their time of somebody else's money 62 00:03:59,600 --> 00:04:03,400 and effort before they launched a single feature 63 00:04:03,400 --> 00:04:07,700 into Market. Here's the first quote, while the initial 64 00:04:07,700 --> 00:04:11,800 launch and traction proved extremely exciting, it misled us 65 00:04:11,800 --> 00:04:12,900 into believing, there was a 66 00:04:13,000 --> 00:04:17,900 Archer Market ready to adopt our product. So they launched and the hype is huge and the 67 00:04:17,900 --> 00:04:21,900 TechCrunch Crowd Goes Wild and they feel like they're getting a 68 00:04:21,900 --> 00:04:24,000 ton of feedback and traction. 69 00:04:25,600 --> 00:04:29,900 But what they're not testing to see is who is actually testing the site 70 00:04:30,000 --> 00:04:33,900 and working on it. And it turns out in retrospect that it was early adopters, 71 00:04:34,600 --> 00:04:38,600 VCS other entrepreneurs and Friends within that 72 00:04:38,600 --> 00:04:39,900 Silicon Valley bubble. 73 00:04:41,300 --> 00:04:45,600 And so they're looking at their numbers and they're seeing this, a hundred thousand people have registered and over 74 00:04:45,600 --> 00:04:49,800 230,000 people. Visit each month these days, 75 00:04:49,800 --> 00:04:53,900 these are called vanity metrics and they're called vanity metrics because they 76 00:04:53,900 --> 00:04:57,800 make you feel good about yourself. But they don't actually tell 77 00:04:57,800 --> 00:05:01,700 you anything about how your product is performing. Whether it's working well or 78 00:05:01,700 --> 00:05:05,800 working poorly of these hundred thousand registrations, how many 79 00:05:05,800 --> 00:05:07,300 people have actually shared a plan 80 00:05:08,800 --> 00:05:12,900 How many people have actually followed somebody on the service? How many of these people 81 00:05:12,900 --> 00:05:16,900 come back a second time or third time? And then for the second 82 00:05:16,900 --> 00:05:20,900 month and the third month, these numbers don't tell you that. So 83 00:05:20,900 --> 00:05:24,400 they make you feel good. But they don't tell you whether or not you're actually seeing any traction 84 00:05:24,400 --> 00:05:28,800 for your product and it gives you that false sense of success and a false sense of 85 00:05:28,800 --> 00:05:29,700 product Market fit. 86 00:05:32,100 --> 00:05:36,900 One of my favorite quotes is this, people often tell me, I like plancast, but I never have any 87 00:05:36,900 --> 00:05:40,700 plans to share this entire system was built around a social 88 00:05:40,700 --> 00:05:44,800 object called a plan. I'm going to do something. 89 00:05:44,800 --> 00:05:48,900 It turns out after they launched, they learned that 90 00:05:48,900 --> 00:05:51,100 people don't have these plans to share. 91 00:05:52,400 --> 00:05:56,600 The problem statement they set out to solve was that the average individual doesn't have enough 92 00:05:56,600 --> 00:06:00,700 insight into all the social opportunities going on within their Social Circle. 93 00:06:01,100 --> 00:06:05,600 And they didn't want people to miss out, but this was a personal intuition made by the 94 00:06:05,600 --> 00:06:09,800 founders. There was no proof that there was a wide Market need and no 95 00:06:09,800 --> 00:06:13,400 upfront. Research was done to validate the problem. 96 00:06:15,100 --> 00:06:19,900 And so after they launched, they find out that they built the service to share thing that people 97 00:06:19,900 --> 00:06:21,000 don't have. 98 00:06:22,900 --> 00:06:24,200 What's even more interesting? 99 00:06:26,000 --> 00:06:30,800 Is that for those people who did actually have a plan to share for the few individuals that did 100 00:06:30,800 --> 00:06:34,900 actually have a plan to share it, turns out that sharing a plan 101 00:06:35,200 --> 00:06:39,600 doesn't give you that same warm squishy, feeling that sharing a 102 00:06:39,600 --> 00:06:43,900 picture of your kid, or your pet, or your meal does on 103 00:06:43,900 --> 00:06:45,300 all the other social networks. 104 00:06:46,600 --> 00:06:50,600 And again, five months of work to launch, only to find 105 00:06:50,600 --> 00:06:54,400 out that people don't really get anything out of sharing these 106 00:06:54,400 --> 00:06:58,900 plans and as the system grew over time and they continue to develop it. They 107 00:06:58,900 --> 00:07:02,900 didn't see any social sharing and they couldn't understand. 108 00:07:02,900 --> 00:07:06,700 Why was there an opportunity for them to learn this before. They 109 00:07:06,700 --> 00:07:10,300 spent five months building the system and the site. 110 00:07:12,400 --> 00:07:16,900 The last quote, I want to use from this is this one, the 111 00:07:16,900 --> 00:07:20,300 team made a subjective decision before, launching 112 00:07:20,500 --> 00:07:23,000 not to have an invitation feature. 113 00:07:24,800 --> 00:07:28,800 They didn't know which features to build and so they took a philosophical stand against 114 00:07:28,800 --> 00:07:32,900 invitations for fear of being lumped in with the evite's and the other invitation 115 00:07:32,900 --> 00:07:36,500 services that are out there today. And when they 116 00:07:36,500 --> 00:07:40,900 launched, and they created a system where some people are actually sharing their plans 117 00:07:40,900 --> 00:07:44,800 about where they wanted to be. They created an environment 118 00:07:44,900 --> 00:07:48,400 where people were aware of all these great things that were happening in their Social Circle. 119 00:07:49,300 --> 00:07:53,800 But didn't feel welcome to attend any of these events. They didn't feel invited to 120 00:07:53,800 --> 00:07:57,500 them in essence, creating an anti social network in the 121 00:07:57,500 --> 00:08:01,700 process. And again, was there an opportunity for them to 122 00:08:01,700 --> 00:08:05,800 learn this, in advance of spending five months, worth of work, and of course, the answer is 123 00:08:05,800 --> 00:08:09,800 yes. Now what's interesting is that that's a start-up context, 124 00:08:09,900 --> 00:08:13,900 but whether you're in a start-up context or in an Enterprise context, companies are 125 00:08:13,900 --> 00:08:17,800 still working with old assumptions. The old assumptions that you have to 126 00:08:17,800 --> 00:08:18,900 design everything. 127 00:08:19,100 --> 00:08:23,900 Up front. You have to specify everything up front and make sure that everything is 128 00:08:23,900 --> 00:08:27,500 in place and defined before you ship it, off to production 129 00:08:27,800 --> 00:08:28,800 or to the printer. 130 00:08:30,500 --> 00:08:34,900 At the assumption is that we're building bridges. You have to determine where we're going to start and where 131 00:08:34,900 --> 00:08:38,900 we're going to end, and what's going to happen in between before we can lay a 132 00:08:38,900 --> 00:08:40,000 single brick. 133 00:08:42,400 --> 00:08:46,800 And the software context people are still thinking about this. We're still delivering 134 00:08:46,800 --> 00:08:47,600 software. 135 00:08:50,200 --> 00:08:54,900 In fixed format on a disk where we have an opportunity to design or build for 136 00:08:54,900 --> 00:08:58,800 six months, or a year or 18 months and then launch. And then 137 00:08:58,800 --> 00:09:02,500 people will go by this physical artifact and install the 138 00:09:02,500 --> 00:09:06,900 software. And then we have another year 18 months before we can update that and 139 00:09:06,900 --> 00:09:08,600 learn anything and move that forward. 140 00:09:10,100 --> 00:09:14,200 But that's not our reality. A reality has changed 141 00:09:14,800 --> 00:09:18,800 software. Delivery can now happen through a variety of different 142 00:09:18,800 --> 00:09:22,500 channels, the least of, which is actual physical 143 00:09:22,700 --> 00:09:26,700 material to deliver it on, we're delivering software now through the 144 00:09:26,700 --> 00:09:30,900 web and through mobile app stores and through any other channel that 145 00:09:30,900 --> 00:09:34,700 can get those bits onto people's devices in the fastest way 146 00:09:34,700 --> 00:09:35,400 possible. 147 00:09:37,000 --> 00:09:40,700 And this is fundamentally changed the way that software is being 148 00:09:41,600 --> 00:09:45,800 developed consumed and needs to change. The way that software 149 00:09:45,800 --> 00:09:49,400 is being developed because this is the new reality. 150 00:09:50,800 --> 00:09:53,100 Software is continuous. 151 00:09:54,900 --> 00:09:58,700 It's never finished. We're no longer working towards 152 00:09:58,700 --> 00:10:02,900 that disc that we put on a box and put on a Shelf. 153 00:10:03,800 --> 00:10:07,800 We're no longer delivering a finished product instead, we're delivering 154 00:10:07,800 --> 00:10:10,700 continuous incremental improvements. 155 00:10:12,300 --> 00:10:15,500 And that fundamentally changes our ability. 156 00:10:16,800 --> 00:10:20,900 In learning what we should build and what we shouldn't build which needs to 157 00:10:20,900 --> 00:10:24,800 change the way that we develop products to put a fine point 158 00:10:24,800 --> 00:10:28,800 on it. This is how often Amazon pushes code to production. 159 00:10:30,300 --> 00:10:34,300 every eleven point six seconds, Amazon pushes 160 00:10:34,500 --> 00:10:35,600 codes lie, 161 00:10:37,000 --> 00:10:37,700 To production. 162 00:10:39,600 --> 00:10:43,800 Now, they're not refreshing the entire Amazon ecosystem, every eleven and a half seconds, 163 00:10:44,700 --> 00:10:48,900 they're pushing small bits forward and because they're pushing these 164 00:10:48,900 --> 00:10:52,800 small bits, they get an opportunity to learn. Whether those small bits actually 165 00:10:52,800 --> 00:10:56,200 made a difference where they learn something, whether they made a change 166 00:10:56,200 --> 00:11:00,900 and if they did, they can scale that out further or 167 00:11:00,900 --> 00:11:04,900 they can optimize that and then scale it out. But if they didn't make a difference, 168 00:11:06,400 --> 00:11:07,700 They can roll that back. 169 00:11:09,900 --> 00:11:13,700 And it's those tiny bits of risk that allow them to continually 170 00:11:13,700 --> 00:11:17,500 improve their system. It to continually optimize and build better 171 00:11:17,500 --> 00:11:18,300 products. 172 00:11:20,000 --> 00:11:24,800 And this gets us out of this mindset of the model year, the 173 00:11:24,800 --> 00:11:28,700 nature of software being continuous. The nature of our learning 174 00:11:29,000 --> 00:11:33,000 being continuous because you can deliver software on a regular basis like that 175 00:11:33,900 --> 00:11:37,900 you're building a continuous learning Loop, that gets you out of this 176 00:11:37,900 --> 00:11:41,800 mindset of the model year, were no longer thinking we shouldn't be thinking 177 00:11:42,600 --> 00:11:46,300 how many features can be crammed in to the next iteration of our 178 00:11:46,300 --> 00:11:47,000 product. 179 00:11:48,800 --> 00:11:51,800 What will people pay for the next time we go to sell them? Something 180 00:11:52,700 --> 00:11:56,800 that mind change mindset has to change because we're no longer making 181 00:11:56,900 --> 00:12:00,600 copies of a known thing will continually evolving the 182 00:12:00,600 --> 00:12:01,200 system. 183 00:12:02,900 --> 00:12:06,200 And we're doing that through that continuous feedback loop. 184 00:12:07,400 --> 00:12:09,600 Which is the reality of how software is delivered today. 185 00:12:11,700 --> 00:12:15,900 And so what processes allow us to learn to 186 00:12:15,900 --> 00:12:19,900 work this way and to take advantage of all this new information 187 00:12:20,600 --> 00:12:24,800 lean ux is one of those processes and ux to talk about a 188 00:12:24,800 --> 00:12:28,400 properly we have to talk about three different things we have to talk about agile software development. 189 00:12:28,400 --> 00:12:32,700 We have to talk about Lean Startup and we have to talk about 190 00:12:32,700 --> 00:12:36,700 lean. First thing I want to mention is agile software development. 191 00:12:37,600 --> 00:12:40,000 Now without going too deeply into agile software development 192 00:12:42,100 --> 00:12:46,400 I want to talk about why it came to be that these 17 gentleman software engineers, 193 00:12:47,700 --> 00:12:51,700 About in the year 2000 were frustrated with the way 194 00:12:51,700 --> 00:12:55,900 that software is being delivered. They were missing deadlines. They weren't 195 00:12:55,900 --> 00:12:59,500 meeting customer expectations. They were continually negotiating with their clients 196 00:12:59,500 --> 00:13:03,900 about what they were building and how things were changing and evolving as they 197 00:13:03,900 --> 00:13:06,800 were writing code and they figured it had to be a better way. 198 00:13:06,800 --> 00:13:10,200 And so they send it a mountain and Utah 199 00:13:10,200 --> 00:13:14,700 where the air was thin. And they spent a few days up in the mountain, 200 00:13:14,700 --> 00:13:17,300 discussing better ways to do this. And when they, 201 00:13:18,500 --> 00:13:22,700 Descended from the mountain and he most biblical way they came 202 00:13:22,700 --> 00:13:26,700 down with the agile Manifesto. Now the agile Manifesto is a fairly short 203 00:13:26,700 --> 00:13:30,500 document and if you've read it, you'll know that there's 204 00:13:30,500 --> 00:13:34,900 nothing in there that talks about process. There's nothing in there that 205 00:13:34,900 --> 00:13:38,400 says, you will stand up everyday 9:30 for 15 minutes with your 206 00:13:38,400 --> 00:13:42,900 colleagues. You will work in two weeks Cycles. You will have a retrospective. None of 207 00:13:42,900 --> 00:13:46,800 these things are in there. In fact all the agile Manifesto is is a 208 00:13:46,800 --> 00:13:47,600 set of principles. 209 00:13:47,700 --> 00:13:51,900 Goals and philosophies, for approaching work, in their 210 00:13:51,900 --> 00:13:53,200 case, it was software design. 211 00:13:54,300 --> 00:13:57,700 And it boils down to these core. Four principles. 212 00:13:59,700 --> 00:14:03,500 And what these guys were saying is that we value the things on the left, 213 00:14:04,000 --> 00:14:08,500 more than we value, the things on the right. It doesn't mean that there's zero value 214 00:14:08,800 --> 00:14:12,900 over here on the right, it just means there's more value on the things on the left and 215 00:14:12,900 --> 00:14:14,400 that's where we should focus. Our efforts. 216 00:14:15,500 --> 00:14:18,900 The first of this is individuals and interactions over processes and tools. 217 00:14:19,800 --> 00:14:23,500 We all use processes and we all use specific tools to get our jobs done. 218 00:14:23,700 --> 00:14:27,800 Inevitably those processes and tools boxes into a point where we can't make any 219 00:14:27,800 --> 00:14:28,700 more progress. 220 00:14:30,200 --> 00:14:34,800 There's more value in standing up going to talk to your colleagues and interacting with 221 00:14:34,800 --> 00:14:38,800 them in real time to get you unblocked and moving forward 222 00:14:39,500 --> 00:14:43,800 and not to get blocked and say well, the process doesn't allow me to take the next step until we unblock the 223 00:14:43,800 --> 00:14:44,800 previous step. 224 00:14:45,900 --> 00:14:49,600 There's more value and standing up and having an interaction with an individual. 225 00:14:50,800 --> 00:14:54,800 There's more value in working software than there isn't comprehensive documentation. 226 00:14:55,200 --> 00:14:59,400 Our customers use working software, they don't use comprehensive 227 00:14:59,400 --> 00:15:03,800 documentation. How can we get to working software faster? 228 00:15:05,200 --> 00:15:09,800 Or how can we least get to an approximation of working software faster, 229 00:15:10,300 --> 00:15:14,600 as opposed to building a set of comprehensive documents that describe an 230 00:15:14,600 --> 00:15:18,900 experience that may or may not work for our customers and our business in the future. There's 231 00:15:18,900 --> 00:15:22,200 more value in working software than there is in documentation. 232 00:15:23,600 --> 00:15:27,400 There's more value and customer collaboration than there is in contract negotiation 233 00:15:28,000 --> 00:15:32,700 at the beginning of every engagement, where they work in house, where they work in an agency, you're going to 234 00:15:32,700 --> 00:15:36,800 make a series of commitments to your customers, whether external 235 00:15:36,800 --> 00:15:39,000 customers or internal customers. 236 00:15:40,200 --> 00:15:44,400 and if you negotiate every bit of a contract and a commitment level up front, 237 00:15:46,100 --> 00:15:50,900 you're going to find out as you start to build the product. That things are not going to line up. Exactly how you 238 00:15:50,900 --> 00:15:52,000 imagine them to be. 239 00:15:53,700 --> 00:15:56,800 And so you're going to renegotiate that contract on an ongoing basis. 240 00:15:57,200 --> 00:16:01,900 Instead, there's greater value and collaborating with our customers throughout the software development process, 241 00:16:01,900 --> 00:16:05,900 to let them know what we're learning, what we need to adjust and 242 00:16:05,900 --> 00:16:09,800 allow them to make the priorities and the decisions that need to be made 243 00:16:09,800 --> 00:16:11,400 as new information is revealed. 244 00:16:12,900 --> 00:16:16,900 Finally responding to change is more valuable than following 245 00:16:16,900 --> 00:16:20,900 a plan. It doesn't matter what process you use 246 00:16:20,900 --> 00:16:24,600 to develop your products today. It doesn't matter whether using lean 247 00:16:24,600 --> 00:16:28,400 or agile, or Six Sigma or whatever it is you're going to have 248 00:16:28,400 --> 00:16:32,900 a plan. You're going to make a plan that says, we're starting at Point a and we're going to end 249 00:16:32,900 --> 00:16:33,400 at point B. 250 00:16:34,900 --> 00:16:38,800 Now along the way things are going to change, you're going to 251 00:16:38,800 --> 00:16:42,500 learn new things. The features that you thought were 252 00:16:42,500 --> 00:16:46,900 simple may turn out to be complex. The complex features may turn out to be simple. 253 00:16:47,800 --> 00:16:51,900 Your competitor May launch the exact same thing that you're working on and do 254 00:16:51,900 --> 00:16:54,500 it better than you while you're still in development. 255 00:16:56,000 --> 00:16:59,700 The market you're building for Macy a fundamental change. 256 00:17:00,800 --> 00:17:04,800 In the way that it's configured. It may crash. I'll give you an example. I used to work at a 257 00:17:04,800 --> 00:17:08,600 company called the ladders. The latter's was a job board that cater to people who made 258 00:17:08,600 --> 00:17:12,500 $100,000 or more. I started working there in October of 259 00:17:12,500 --> 00:17:13,700 2008 260 00:17:14,800 --> 00:17:18,700 and we had a clear plan for the future, focusing heavily on our financial 261 00:17:18,700 --> 00:17:22,800 services and our sales job Seekers and jobs 262 00:17:22,800 --> 00:17:23,700 in that system. 263 00:17:24,900 --> 00:17:28,900 Lehman Brothers collapsed a few weeks after I started at 264 00:17:28,900 --> 00:17:32,900 that job. All of a sudden our ecosystem, which was fairly 265 00:17:32,900 --> 00:17:36,700 well, balanced between job Seekers, and employers and recruiters 266 00:17:36,900 --> 00:17:38,200 all of a sudden, looks like this. 267 00:17:39,300 --> 00:17:42,000 Tons and tons of job Seekers and no jobs. 268 00:17:43,200 --> 00:17:47,600 We have the option to heads down. Follow our plan. We had a plan, 18 269 00:17:47,600 --> 00:17:51,700 months roadmap the whole thing. But instead, you have to 270 00:17:51,700 --> 00:17:55,500 look up periodically and regularly, and respond to that 271 00:17:55,500 --> 00:17:59,800 change, and adjust your plans, to make sure that you're building the best 272 00:17:59,800 --> 00:18:03,600 product for your Market as it exists today. 273 00:18:06,100 --> 00:18:10,600 And that's the key to being agile, right? We're not focusing on a 274 00:18:10,600 --> 00:18:14,900 process of doing an agile process. We're focusing on agility on 275 00:18:14,900 --> 00:18:18,400 being agile and that is responding to change over following a plan. 276 00:18:18,800 --> 00:18:22,400 Now, what's interesting is that user experience 277 00:18:22,400 --> 00:18:26,900 design, product management, content strategy, all 278 00:18:26,900 --> 00:18:30,700 of the disciplines that today make up the difference between a successful 279 00:18:30,700 --> 00:18:34,300 product and an unsuccessful product. We're never factored in 280 00:18:34,300 --> 00:18:35,500 during agile. 281 00:18:36,100 --> 00:18:38,000 Agile was conceived by a bunch of Engineers. 282 00:18:40,000 --> 00:18:42,400 So then how do we bring these disciplines together? 283 00:18:43,800 --> 00:18:47,800 In a way that values, all of the things that the agile Manifesto talks about. 284 00:18:48,200 --> 00:18:49,500 And that's we're going to talk about 285 00:18:50,800 --> 00:18:53,000 The next thing I want to talk about is lean. 286 00:18:55,800 --> 00:18:59,600 Lean has two fundamental principles. That underlie the entire way 287 00:18:59,600 --> 00:19:00,500 that it's built. 288 00:19:03,100 --> 00:19:07,600 The first is that you're always moving from doubt to certainty. 289 00:19:07,800 --> 00:19:11,900 It's an inherent and humble admission by 290 00:19:12,400 --> 00:19:15,000 you, your team, your manager. 291 00:19:16,000 --> 00:19:20,500 That we don't have all the answers upfront to the way that we need to solve this 292 00:19:20,500 --> 00:19:24,700 particular business problem, and so we're always moving from doubt to 293 00:19:24,700 --> 00:19:25,500 certainty. 294 00:19:26,800 --> 00:19:30,800 And the way that we move from doubt, two, certainties the second principle and that's in working in 295 00:19:30,800 --> 00:19:34,200 small batches. So we're always taking small steps 296 00:19:34,900 --> 00:19:38,700 towards certainty, moving out of doubt. 297 00:19:39,900 --> 00:19:43,700 This is that Amazon model, they take their small steps every eleven 298 00:19:43,700 --> 00:19:46,900 point, six seconds. In other words they're baking the cupcake 299 00:19:46,900 --> 00:19:50,900 before they're making the cake right. Is this a good cupcake? 300 00:19:50,900 --> 00:19:54,800 Is this a good recipe? Let's find out. And if not let's refine it 301 00:19:54,800 --> 00:19:58,900 and then scale it out. This was the foundation for lean. 302 00:20:00,500 --> 00:20:04,900 When it was developed in the 1950s, at Toyota by taiichi Ohno and 303 00:20:04,900 --> 00:20:08,900 the rest of the folks at that organization and post-war Japan was struggling to keep up with 304 00:20:08,900 --> 00:20:11,000 the American car manufacturers. 305 00:20:12,400 --> 00:20:14,900 And they realized that they couldn't compete on scale. 306 00:20:16,000 --> 00:20:20,900 And so they decided to compete on variety and efficiency and 307 00:20:20,900 --> 00:20:24,900 they built the idea of the lean model, the Toyota production system, 308 00:20:24,900 --> 00:20:28,800 which essentially Works to remove waste 309 00:20:28,800 --> 00:20:32,900 from the process. Anything that doesn't add value to the 310 00:20:32,900 --> 00:20:36,700 business and to the customer is waste. And as we take 311 00:20:36,700 --> 00:20:40,400 those small steps from doubt to certainty, we're 312 00:20:40,400 --> 00:20:44,900 removing waste from the process because we're not building things that people 313 00:20:44,900 --> 00:20:45,600 don't want. 314 00:20:46,700 --> 00:20:50,800 Now and what is possibly the ugliest infographic ever made? 315 00:20:52,400 --> 00:20:56,700 This is the Toyota production system. The lean system as they imagined it 316 00:20:57,000 --> 00:21:01,800 in the 50s and essentially what Toyota was saying is this we have a goal of 317 00:21:01,800 --> 00:21:05,900 creating the highest quality product at the lowest cost and that's great. Every company has 318 00:21:05,900 --> 00:21:09,900 that same goal. The interesting part here is that they want to build it in the 319 00:21:09,900 --> 00:21:11,600 shortest lead time. 320 00:21:12,500 --> 00:21:16,900 And what they mean by that is that we're only going to manufacture 321 00:21:17,300 --> 00:21:21,800 the things that we know we need to manufacture right, think about it. We're always 322 00:21:21,800 --> 00:21:25,700 moving from doubt to certainty. So if we know today that we need to 323 00:21:25,700 --> 00:21:29,900 build a hundred cars, we are only going to manufacture the components 324 00:21:30,500 --> 00:21:34,900 to assemble a hundred cars because we don't know if we're 325 00:21:34,900 --> 00:21:38,300 going to build a hundred and first hundred, second, hundred and third car. 326 00:21:39,300 --> 00:21:43,800 And producing the materials to create those cars. Beyond a 327 00:21:43,800 --> 00:21:47,900 hundred storing that material transporting. It is 328 00:21:47,900 --> 00:21:51,900 all waste, there's cost there and it's wasteful and we don't know if 329 00:21:51,900 --> 00:21:55,700 we're ever going to recoup that cost. So let's only do what we 330 00:21:55,700 --> 00:21:59,900 need to do, when we need to do it, where we need to 331 00:21:59,900 --> 00:22:03,800 do it in the quantities that it needs to get done. 332 00:22:05,300 --> 00:22:09,200 Now at the same time, we're ensuring that our process is as 333 00:22:09,200 --> 00:22:13,400 efficient as it could be. And if it isn't, we stop the 334 00:22:13,400 --> 00:22:14,200 process. 335 00:22:15,300 --> 00:22:19,500 We re harmonize the process and we start again because it's 336 00:22:19,600 --> 00:22:23,800 easier and cheaper to fix problems in production than it is 337 00:22:23,800 --> 00:22:27,800 once the product has rolled off in their case the assembly line. Now, in the case 338 00:22:27,800 --> 00:22:31,700 of Toyota, every Toyota assembly line employee to 339 00:22:31,700 --> 00:22:35,800 this day has access to a cord, the andon cord where they 340 00:22:35,800 --> 00:22:39,800 can pull that cord and stop the production line. If they see something 341 00:22:39,900 --> 00:22:42,600 wrong, something's happening that they don't like 342 00:22:43,600 --> 00:22:45,100 they stop the process. 343 00:22:46,200 --> 00:22:50,900 In software engineering, this is akin to us saying this process is not 344 00:22:50,900 --> 00:22:54,300 working. We're not communicating well or not getting good 345 00:22:54,300 --> 00:22:58,900 feedback, we're not building the right product. Let's stop this process. Let's figure out what's 346 00:22:58,900 --> 00:23:02,800 wrong and then let's re harmonize and start it again. And 347 00:23:02,800 --> 00:23:06,400 as we do, let's only create the artifacts, the 348 00:23:06,400 --> 00:23:10,800 assets, the meetings, the bureaucracy that 349 00:23:10,800 --> 00:23:12,700 we need to ensure. 350 00:23:14,400 --> 00:23:16,300 What we know we have to build today. 351 00:23:18,000 --> 00:23:22,500 Because anything else is potentially wasteful and we don't want to spend that time doing it. 352 00:23:24,600 --> 00:23:28,900 More recently, gentleman by the name of Eric Ries wrote a book called, The Lean Startup, where he takes 353 00:23:28,900 --> 00:23:32,100 this approach and he and he applies it to the startup economy. 354 00:23:33,500 --> 00:23:37,900 Eric says, the Lean Startup has a premise that every startup is a grand experiment. 355 00:23:38,000 --> 00:23:42,900 Now, take that word startup and replace it with whatever it is that you're working on product feature 356 00:23:42,900 --> 00:23:46,500 service, widget, whatever it is, you're working on 357 00:23:46,500 --> 00:23:47,700 Startup as well. 358 00:23:49,000 --> 00:23:53,900 And that it's a grand experiment and that experiment attempts to answer a question and the 359 00:23:53,900 --> 00:23:56,800 question is not, can we build this? 360 00:23:57,800 --> 00:24:00,800 Because you throw enough time money and people that are problem. You can build anything. 361 00:24:01,600 --> 00:24:05,400 Instead, the question is, should we actually be building? This 362 00:24:06,100 --> 00:24:10,500 is this something we should be doing, right? We're moving from doubt to certainty. We don't know 363 00:24:11,400 --> 00:24:15,600 if the Trap is going to catch the raccoon. It may catch the dog. Should we be 364 00:24:15,600 --> 00:24:16,300 building this? 365 00:24:17,300 --> 00:24:21,600 And if we should be building this, can we build a business around this? 366 00:24:23,400 --> 00:24:27,700 And what's interesting is that the experiments that you're running to learn the answers to these 367 00:24:27,700 --> 00:24:31,500 questions are not hypothetical, they're not theoretical, they're the first 368 00:24:31,500 --> 00:24:33,200 versions of the product. 369 00:24:35,100 --> 00:24:38,400 They're the early the minimally viable versions of these products. 370 00:24:39,500 --> 00:24:43,900 Now, all of this is in service of again, reducing waste and 371 00:24:43,900 --> 00:24:47,600 more importantly. And perhaps, most importantly, not building things that 372 00:24:47,600 --> 00:24:49,000 people don't want. 373 00:24:50,700 --> 00:24:54,500 In my opinion, that's the greatest waste. That's a waste of your 374 00:24:54,500 --> 00:24:58,700 personal time at work to waste of your team's time your 375 00:24:58,700 --> 00:25:01,500 company's time and certainly of your customers time. 376 00:25:02,400 --> 00:25:06,900 And so, you take these ideas of agile, lean Lean 377 00:25:06,900 --> 00:25:10,300 Startup together, and you combine them with design, thinking 378 00:25:10,300 --> 00:25:14,500 and design, principles, and user experience. And you get the idea 379 00:25:14,500 --> 00:25:16,400 behind lean ux, 380 00:25:18,600 --> 00:25:22,400 Lean ux is inspired by these ideas, Lean Startup and Agile, development theories, 381 00:25:22,400 --> 00:25:26,800 and it's the practice of bringing the true nature of a product to 382 00:25:26,800 --> 00:25:30,500 light faster. Remember, working software, over, comprehensive 383 00:25:30,500 --> 00:25:34,100 documentation, show me how it works. How do we get there first 384 00:25:34,100 --> 00:25:38,700 and do that in a collaborative? Cross-functional way working 385 00:25:38,700 --> 00:25:42,800 together with design, product management, engineering QA, 386 00:25:42,800 --> 00:25:46,100 marketing content, editorial, 387 00:25:46,100 --> 00:25:47,900 focusing less 388 00:25:48,700 --> 00:25:52,300 on creating documentation that describes, this experience 389 00:25:52,800 --> 00:25:56,800 and focusing more on building a shared understanding amongst that cross 390 00:25:56,800 --> 00:25:57,800 functional team, 391 00:25:59,400 --> 00:26:03,800 Of the actual experience being designed. So as a team, we 392 00:26:03,800 --> 00:26:07,700 can collectively understand what we're building. Why we're 393 00:26:07,700 --> 00:26:11,600 building it how our customers are reacting to it and then we can 394 00:26:11,800 --> 00:26:15,300 make more informed decisions as a team. Now look 395 00:26:16,000 --> 00:26:20,300 most software projects start like this a team has gathered. 396 00:26:20,900 --> 00:26:24,900 They're given a problem to solve or project to work on and everybody thinks they know the 397 00:26:24,900 --> 00:26:28,900 answer, right off the bat and they make an assumption that their colleagues all have 398 00:26:28,900 --> 00:26:29,100 the same 399 00:26:29,200 --> 00:26:30,900 Same idea in their head. 400 00:26:32,500 --> 00:26:36,700 When in reality, everyone has a slightly different world view about how to solve this 401 00:26:36,700 --> 00:26:37,700 particular problem. 402 00:26:39,600 --> 00:26:43,700 And so when we work on these collaborative, cross-functional teams and we employ the ideas behind lean 403 00:26:43,700 --> 00:26:47,600 ux, we start to extract these ideas out of people's 404 00:26:47,600 --> 00:26:51,800 heads very, very quickly in the lightest way possible in the 405 00:26:51,800 --> 00:26:55,900 most efficient way possible, because anything else would be wasteful, right? This is the 406 00:26:55,900 --> 00:26:59,500 lean principles are in here. And as soon as we can get these ideas out of people's heads, on a 407 00:26:59,500 --> 00:27:03,200 Blackboard on a whiteboard and sketches on Post-it notes, 408 00:27:03,900 --> 00:27:07,900 whatever works for that particular team, we start to see that we're not on the same page. 409 00:27:09,000 --> 00:27:13,800 Not approaching the solution. The same way. We all have a slightly different idea of how to do this, but 410 00:27:13,800 --> 00:27:17,500 there's value in those different opinions because you can start to 411 00:27:17,500 --> 00:27:21,600 combine them and to collaborate and to build off of each other. 412 00:27:23,700 --> 00:27:25,400 And as you start to do that, 413 00:27:27,500 --> 00:27:31,900 everyone is weighing in on the solution, the approach, the challenges 414 00:27:31,900 --> 00:27:35,900 product design engineering, and you're getting a broader buy-in for the 415 00:27:35,900 --> 00:27:39,600 team's Direction and the solution that they're working towards, 416 00:27:39,900 --> 00:27:42,900 and it starts to build this shared, understanding 417 00:27:42,900 --> 00:27:44,400 shared Focus. 418 00:27:45,800 --> 00:27:49,900 And then ultimately team alignment where everybody is on the same page. 419 00:27:50,900 --> 00:27:54,700 They have a clear sense of the problem that were solving how we think we're going to 420 00:27:54,700 --> 00:27:58,800 approach it. And what will determine success now? Yes, along the way 421 00:27:58,800 --> 00:28:01,200 moving forward. There will be new learnings 422 00:28:03,000 --> 00:28:07,600 But this is an opportunity to get that alignment up front at the 423 00:28:07,600 --> 00:28:11,100 beginning and it's that shared understanding. That's the 424 00:28:11,100 --> 00:28:15,500 currency of lean ux. That's what you're trading 425 00:28:15,700 --> 00:28:19,700 for fix specification documents and long design review 426 00:28:19,700 --> 00:28:23,800 meetings and and lengthy conversations about whether the button should be red or 427 00:28:23,800 --> 00:28:27,800 should be blue or have rounded corners, or if we should use this API or that 428 00:28:27,800 --> 00:28:31,700 API, it's that shared understanding that allows you to move 429 00:28:31,800 --> 00:28:32,700 faster and more. 430 00:28:32,900 --> 00:28:36,900 Efficiently. Now, I want to dig in a little bit of the concept of shared understanding 431 00:28:36,900 --> 00:28:40,400 because it's critical to the success of any collaborative. 432 00:28:40,400 --> 00:28:44,700 Cross-functional process with this. This is my 433 00:28:44,700 --> 00:28:48,500 neighbor, I live next door to this gentleman 434 00:28:49,100 --> 00:28:52,000 and I live on a main street in Suburban America. 435 00:28:53,300 --> 00:28:55,300 and if you were to drive past my house, 436 00:28:56,800 --> 00:28:58,100 And see this scene. 437 00:28:59,400 --> 00:29:03,100 This would be a fairly typical scene in Suburban America, 438 00:29:03,100 --> 00:29:07,300 a man and his dog in their yard, 439 00:29:07,300 --> 00:29:11,100 with a leaf blower on his back, as he cleans the leaves off. 440 00:29:12,700 --> 00:29:16,900 Of his grass. He probably wouldn't think twice about it because you have a 441 00:29:16,900 --> 00:29:20,800 surface level understanding of this situation and it looks 442 00:29:20,800 --> 00:29:24,700 pretty typical. Now, if you were to start building a shared, 443 00:29:24,700 --> 00:29:28,400 understanding of the situation, and come live in my 444 00:29:28,400 --> 00:29:31,300 house, next door to this gentleman, 445 00:29:32,800 --> 00:29:36,300 You would learn a few things, you would learn that 446 00:29:37,400 --> 00:29:40,500 my neighbor loves that leaf blower. 447 00:29:42,000 --> 00:29:46,000 He loves that leaf blower, I think as much as he loves his children 448 00:29:46,000 --> 00:29:50,800 and it starts to make you feel about him like this. There are there certain 449 00:29:50,800 --> 00:29:54,400 days where you start to understand that he's out there 450 00:29:54,400 --> 00:29:58,500 on a very regular basis, let's say daily, perhaps 451 00:29:58,500 --> 00:30:02,100 hourly at times cleaning every blade of grass 452 00:30:02,100 --> 00:30:06,800 and acorn and Twig off of his grass. And if you try to work from home, on a 453 00:30:06,800 --> 00:30:10,900 particular day, it might inspire you to send some tweets out into 454 00:30:10,900 --> 00:30:11,300 the world. 455 00:30:12,000 --> 00:30:16,800 To share your frustration with the noise. That's coming from outside on an 456 00:30:16,800 --> 00:30:20,700 hourly and regular basis. And so if you lived in my 457 00:30:20,700 --> 00:30:24,900 house and experienced this with me, you would 458 00:30:24,900 --> 00:30:28,700 understand. You have a better shared understanding more context around this 459 00:30:28,700 --> 00:30:31,500 situation. Instead of that, surface-level drive-by, 460 00:30:33,200 --> 00:30:37,800 Now, if you take that experience and you take it one level further and you actually lived in 461 00:30:37,800 --> 00:30:41,800 his house with him, he would learn to 462 00:30:41,800 --> 00:30:45,300 two more interesting facts. That would give you a much better understanding of the 463 00:30:45,300 --> 00:30:49,800 situation. The first is that he's OCD. And that's, you know, that's his 464 00:30:49,800 --> 00:30:53,900 thing and he's working through that and the second is that he 465 00:30:53,900 --> 00:30:55,500 has an angled driveway. 466 00:30:56,700 --> 00:31:00,900 So, the driveway for to his house angles down. And at the end of that driveway, there's 467 00:31:00,900 --> 00:31:01,600 a great 468 00:31:03,700 --> 00:31:07,700 And if that great gets clogged with leaves and twigs and rocks and 469 00:31:07,700 --> 00:31:11,800 acorns, and excess grass clippings, then when it rains, or when the snow 470 00:31:11,800 --> 00:31:14,500 melts, he gets water in his basement. 471 00:31:15,500 --> 00:31:19,800 And he doesn't want water in his basement. And so he's obsessively out there every day. 472 00:31:19,800 --> 00:31:23,700 Making sure that there's not a straight piece of natural, organic material, anywhere, 473 00:31:23,700 --> 00:31:27,300 near that great. Now the point is that the 474 00:31:27,300 --> 00:31:31,800 more you experience these situations together, the greater 475 00:31:31,800 --> 00:31:35,300 understanding, you have of that situation, 476 00:31:37,600 --> 00:31:41,800 and the more you do that together as a team, the less you have to communicate that through documentation and 477 00:31:41,800 --> 00:31:42,300 writing 478 00:31:44,400 --> 00:31:48,600 and that allows us to move faster and more efficiently and this is our 479 00:31:48,600 --> 00:31:52,500 goal. Our goal is to move forward in a parallel path process where 480 00:31:52,500 --> 00:31:56,600 development and design are moving Full Speed Ahead on the same 481 00:31:56,600 --> 00:31:58,400 thing at the same time. 482 00:31:59,900 --> 00:32:03,900 And that's what shared understanding gets you. And so the question 483 00:32:04,100 --> 00:32:08,700 is always asked is how does this all fit in with the agile process, scrum, specifically with these 484 00:32:08,700 --> 00:32:11,200 Cadence processes and I want to make sure that that's clear. 485 00:32:12,500 --> 00:32:16,900 If we talk about hypothetical to week iterations and whether you work in one week or two week, three 486 00:32:16,900 --> 00:32:20,900 week, whatever it is that are tied together by some kind of a theme project and 487 00:32:20,900 --> 00:32:21,600 Epic. 488 00:32:23,100 --> 00:32:27,700 Product feature, whatever it is the focus of this Workshop 489 00:32:27,700 --> 00:32:31,900 is how to kick off this entire theme together 490 00:32:31,900 --> 00:32:35,900 as a cross-functional team to build that shared understanding and 491 00:32:35,900 --> 00:32:39,900 then how to maintain that momentum throughout the 492 00:32:39,900 --> 00:32:42,900 iteration. So, if you've got a larger upfront 493 00:32:42,900 --> 00:32:46,500 set of activities, how do you even pick 494 00:32:46,500 --> 00:32:50,700 specific activities, to ensure that the momentum continues 495 00:32:50,700 --> 00:32:53,000 through each iteration and 496 00:32:53,100 --> 00:32:57,500 Critical is that you have cross-functional participation at the beginning 497 00:32:58,400 --> 00:33:02,200 from day one and that development begins 498 00:33:02,900 --> 00:33:06,300 on day one of Sprint one. So you're building all the shared 499 00:33:06,300 --> 00:33:10,900 understanding and then together you're starting to build product on day. One of Sprint, 500 00:33:10,900 --> 00:33:11,200 one. 501 00:33:12,600 --> 00:33:15,100 And that's what this Workshop is teaching.