1 00:00:00,900 --> 00:00:04,400 So we talked about the discovery process, the lean approach to 2 00:00:05,200 --> 00:00:09,900 collaborative cross-functional building a shared understanding. How do we 3 00:00:09,900 --> 00:00:13,800 combine this with an agile Cadence with the Cadence of a scrum 4 00:00:13,800 --> 00:00:17,800 process? And that's what we're going to talk about next and I like to start this 5 00:00:17,800 --> 00:00:21,800 section with an anecdote. I used to run the 6 00:00:22,300 --> 00:00:26,800 user experience team at a company called the ladders and the latter's went through an agile transformation while I was there 7 00:00:26,800 --> 00:00:29,600 and I was building my design practice my user experience and Design. 8 00:00:30,000 --> 00:00:34,400 Practice through that transformation. And as we grew the team and as we evolve the 9 00:00:34,400 --> 00:00:38,300 process, we had to understand how to integrate user 10 00:00:38,300 --> 00:00:42,500 experience and design into the agile process. 11 00:00:42,500 --> 00:00:46,000 And we struggled with it a lot, especially at the time there was not a lot of material 12 00:00:46,000 --> 00:00:50,800 available with successful Integrations of agile, and user experience. And so we 13 00:00:50,800 --> 00:00:54,900 tried a lot of different things and over the course of about six or seven months, it 14 00:00:54,900 --> 00:00:58,800 felt like we'd stumbled a lot. Finally, hit a Groove where it felt like 15 00:00:58,800 --> 00:00:59,800 things were working really well. 16 00:01:00,000 --> 00:01:03,700 The complaints seem to have died down, productivity seem to have gone up. 17 00:01:04,800 --> 00:01:08,700 And so one day, I was feeling pretty good about how things were going. I came into 18 00:01:08,700 --> 00:01:12,800 work, it was a Monday morning and I get to my desk and there's a printout 19 00:01:13,000 --> 00:01:17,800 on my desk, that's a diagram printout and this was the diagram that was left on 20 00:01:17,800 --> 00:01:18,700 my desk. 21 00:01:19,800 --> 00:01:23,800 Now, it turns out that my team had gone 22 00:01:23,800 --> 00:01:27,800 off on their own and was very, very frustrated, as evidenced by this 23 00:01:27,800 --> 00:01:31,900 diagram about how things were currently proceeding with the integration of 24 00:01:31,900 --> 00:01:35,700 agile and user experience at the ladders at the 25 00:01:35,700 --> 00:01:39,200 time. And if you notice all the, all the roads in this diagram, 26 00:01:39,200 --> 00:01:43,900 lead to the center of a, where it says that agile, and 27 00:01:43,900 --> 00:01:47,700 ux at theladders currently creates a negative environment that Fosters 28 00:01:47,700 --> 00:01:49,600 failure and generates low, 29 00:01:49,900 --> 00:01:53,600 Wow, it's clearly things we're not going as well as I'd hoped coming in. 30 00:01:53,600 --> 00:01:57,900 Obviously the title of the diagram alone diagramming a negative environment, 31 00:01:57,900 --> 00:02:01,300 will give you a sense that this we were not as far along, as I had 32 00:02:01,300 --> 00:02:05,700 hoped in the process and all of those little boxes were 33 00:02:05,800 --> 00:02:09,900 specific pain points that the team was feeling about what was not 34 00:02:09,900 --> 00:02:13,700 working. Well, in the integration of our agile, 35 00:02:13,700 --> 00:02:17,500 engineering practice, and the user experience and design 36 00:02:17,500 --> 00:02:19,600 practice. And I want to highlight a couple of these because 37 00:02:19,800 --> 00:02:23,600 The learnings from the once all of these have value but from the ones that I 38 00:02:23,600 --> 00:02:27,900 highlight, the learnings speak directly into this lean ux approach. 39 00:02:28,500 --> 00:02:32,500 And so, the first one is this one. The best experience never ever gets 40 00:02:32,500 --> 00:02:36,600 built. We came from a waterfall World in a waterfall 41 00:02:36,600 --> 00:02:40,900 world. You get one shot to get it right. Whatever the length of the project 42 00:02:40,900 --> 00:02:44,000 is 9 months. 12 months 18 months, you build it 43 00:02:44,800 --> 00:02:45,800 and you launch it. 44 00:02:46,800 --> 00:02:50,800 And that's it. You get one shot to get it right now. We just took that 45 00:02:50,800 --> 00:02:54,500 same mentality and applied it to two week iterations. 46 00:02:55,900 --> 00:02:59,800 And so all of a sudden, the teams had two weeks to 47 00:02:59,800 --> 00:03:03,700 build the best product that they could now. Of course, you're not going to build the best possible 48 00:03:03,700 --> 00:03:07,100 product in two weeks, but we never went back 49 00:03:07,900 --> 00:03:11,000 to iterate on that process. The agile philosophy 50 00:03:11,000 --> 00:03:15,700 is an, iterative one. It's one of building something learning 51 00:03:15,700 --> 00:03:19,400 and then improving it. And optimizing. It's not an incremental approach 52 00:03:19,400 --> 00:03:23,700 to software development, but we had that waterfall mindset. 53 00:03:25,300 --> 00:03:29,800 Where we would build something and then never look back. And so the team is struggling to keep Pace to launch a 54 00:03:29,800 --> 00:03:33,900 product every two weeks to design something and launch it, every two weeks 55 00:03:34,000 --> 00:03:38,300 and of course the best experience never gets built in a situation like that. 56 00:03:40,100 --> 00:03:44,900 The next point was this, the ux team didn't feel business critical because we didn't 57 00:03:44,900 --> 00:03:48,900 build the best experiences and so because they only gave the team, two weeks 58 00:03:48,900 --> 00:03:52,600 to do their work total from design to development, attesting to 59 00:03:52,600 --> 00:03:53,500 deployment. 60 00:03:54,700 --> 00:03:58,900 Whatever design they could get done in that time, frame was launched and of course it wasn't the best 61 00:03:58,900 --> 00:03:59,400 design. 62 00:04:00,900 --> 00:04:04,900 And the team started to feel like they were just pixel pushers people who 63 00:04:04,900 --> 00:04:08,700 just did the best that they could in the time that they had and the experience would just go out 64 00:04:08,700 --> 00:04:12,600 regardless of how it affected customer experience or the brand. And so 65 00:04:12,600 --> 00:04:16,400 that the, the engagement of the team suffered significantly 66 00:04:17,100 --> 00:04:21,800 because they weren't given the opportunity to go back and to iterate on their 67 00:04:21,800 --> 00:04:25,800 ideas and to move forward, simply let's build it and let's just move on and get whatever you 68 00:04:25,800 --> 00:04:26,500 can done. 69 00:04:28,400 --> 00:04:32,900 Agile, projects are never complete. That was a big complaint. 70 00:04:32,900 --> 00:04:36,800 They never seem to be any kind of an end point to these iterations. 71 00:04:36,800 --> 00:04:40,600 We just built two weeks, two weeks, two weeks, and just kept going 72 00:04:40,600 --> 00:04:44,800 indefinitely. Now, coming from a waterfall world, that was a 73 00:04:44,800 --> 00:04:48,900 drastically different in a waterfall world. You start a project, you work on it for an extended 74 00:04:48,900 --> 00:04:52,900 period of time, 9 months, or 12 months. At the end of at the end of the time. Period, you 75 00:04:52,900 --> 00:04:56,600 launch, you have a party, you get a T-shirt and you get to move on 76 00:04:56,600 --> 00:04:57,900 to the next project. 77 00:04:58,400 --> 00:05:02,600 In this world, in our new agile world, we didn't have 78 00:05:02,600 --> 00:05:06,700 any success criteria. It was simply launched a feature launched a feature launched a feature 79 00:05:06,700 --> 00:05:10,700 and this is when we really started talking about focusing on 80 00:05:10,700 --> 00:05:14,600 outcomes, how do we know when we're done the 81 00:05:14,600 --> 00:05:18,400 agile? Definition of done means that you've launched a feature, that's past its 82 00:05:18,400 --> 00:05:21,100 testing requirements, and that is usable. 83 00:05:22,100 --> 00:05:26,900 But in reality, but we're looking for our business outcomes in this is 84 00:05:26,900 --> 00:05:30,900 what we started to have that conversation, we know we're done when 85 00:05:30,900 --> 00:05:34,800 we see this outcome, this change in behavior in our 86 00:05:34,800 --> 00:05:38,900 customers and that fundamentally changed the way that we 87 00:05:38,900 --> 00:05:42,600 started thinking about our projects. Because all of a sudden, it wasn't 88 00:05:42,600 --> 00:05:44,300 about launching features. 89 00:05:45,600 --> 00:05:49,900 It was about determining outcomes by cheating business outcomes and 90 00:05:49,900 --> 00:05:53,700 that's how we knew when we were done when we hit those kpis those metrics, 91 00:05:54,200 --> 00:05:58,200 that's how we knew we were done. That completely changed the conversation. That was a big one. 92 00:06:00,400 --> 00:06:04,600 The next one is no ideation time because of that rapid, iterative 93 00:06:04,600 --> 00:06:08,500 cycle. The ux team had no time to work on their ideas 94 00:06:08,900 --> 00:06:12,800 and to refine them and to make them better. And 95 00:06:12,800 --> 00:06:16,400 this was partially because there was no integration that was no cross-functional 96 00:06:16,400 --> 00:06:20,900 collaboration between the design team and the engineering team. 97 00:06:21,100 --> 00:06:25,800 We still working essentially in very small waterfalls with a design team with design 98 00:06:25,800 --> 00:06:29,200 up front for a day or two and then show it to the engine. 99 00:06:29,400 --> 00:06:33,100 Is within start, developing it and then we q a by the end of the week. 100 00:06:34,500 --> 00:06:38,900 And so the design team wasn't attending agile stand-ups. 101 00:06:38,900 --> 00:06:42,700 They would do working independently and they were functioning almost as a standalone 102 00:06:42,700 --> 00:06:46,500 operation separate from the rest of the engineering team, 103 00:06:46,600 --> 00:06:50,500 this was a breakthrough moment for us because what we realized is that by integrating 104 00:06:50,500 --> 00:06:54,300 the teams building, this cross-functional teams, 105 00:06:54,300 --> 00:06:58,700 having everyone attend, all the meetings, all of a sudden you're having 106 00:06:58,700 --> 00:07:02,900 conversations that are relevant to all the disciplines involved in the 107 00:07:02,900 --> 00:07:04,500 success of that project designers, 108 00:07:04,600 --> 00:07:08,000 Have a conversation to say, it's going to take me more time, to design. This feature 109 00:07:08,700 --> 00:07:12,700 Engineers can have a chance to say when we could start working on something else while you're 110 00:07:12,700 --> 00:07:13,600 designing that 111 00:07:14,600 --> 00:07:18,400 But those conversations were not happening until we started to build 112 00:07:18,400 --> 00:07:22,700 cross-functional team. That was also open to 113 00:07:22,700 --> 00:07:25,900 democratizing the creativity in the design process by opening up. 114 00:07:25,900 --> 00:07:29,900 Those processes for input from Engineers from 115 00:07:29,900 --> 00:07:32,900 product. Managers to say we're thinking about heading this way. What do you think? 116 00:07:34,200 --> 00:07:36,500 and by building those conversations in real-time, 117 00:07:37,800 --> 00:07:41,900 And having those negotiations around, what I need to do my job, what you need to do your job, 118 00:07:42,300 --> 00:07:46,100 we increased, the amount of ideation time that each team had. 119 00:07:48,600 --> 00:07:52,900 The last point, I want to highlight in this diagram is the concept of minimum viable product. We really struggled 120 00:07:52,900 --> 00:07:56,100 with this, this is such a a 121 00:07:56,500 --> 00:08:00,600 nebulous phrase. When it's first introduced into an organization, what is 122 00:08:00,600 --> 00:08:04,800 viable really mean? You know for engineer's it's functional for 123 00:08:04,800 --> 00:08:06,700 designers it's it's 124 00:08:08,700 --> 00:08:12,800 minimally. Beautiful product for marketers, it's the minimally marketable product, is 125 00:08:12,800 --> 00:08:16,800 it? You know Is it feasible? What is that? What is the definition here? We 126 00:08:16,800 --> 00:08:18,100 really struggled. We had a 127 00:08:18,400 --> 00:08:22,000 Of War about what was good enough to go live. 128 00:08:23,000 --> 00:08:27,800 And this was something that we had to come to agreement and consensus on as an organization 129 00:08:27,800 --> 00:08:31,900 about what was good enough to go live for our organization, and as you 130 00:08:31,900 --> 00:08:35,600 think about the MVPs for your organization, you have to ask yourself. 131 00:08:35,600 --> 00:08:39,300 What's good enough for our organization? What are the 132 00:08:39,500 --> 00:08:43,600 promises of our brand? What is our current customer experience? What are our 133 00:08:43,600 --> 00:08:47,900 design thresholds? What are we comfortable putting in front of 134 00:08:47,900 --> 00:08:48,100 customers? 135 00:08:49,400 --> 00:08:53,400 Based on that context, and that's a conversation that you have to have 136 00:08:53,400 --> 00:08:54,300 internally. 137 00:08:55,600 --> 00:08:58,400 Before you can start releasing MVPs to your customers. 138 00:09:01,400 --> 00:09:05,700 And so as we talk about agile, I want to talk about the mechanics of scrum specifically because 139 00:09:05,700 --> 00:09:09,900 scrum is the process of agile and I think it's worth it to do 140 00:09:09,900 --> 00:09:13,800 some level setting. When we talk about how lean ux fits into agile 141 00:09:13,800 --> 00:09:17,600 by defining, some of the agile terminology, these are my 142 00:09:17,600 --> 00:09:21,900 definitions. And I want to make sure that I set some levels about what I mean when I say 143 00:09:21,900 --> 00:09:25,500 these specific phrases. So we'll go through them. The first is Scrum 144 00:09:25,500 --> 00:09:29,600 and scrum is an agile. Methodology, that promotes time-boxed Cycles. 145 00:09:29,600 --> 00:09:31,300 We work in a 146 00:09:31,900 --> 00:09:35,900 We work in two week, iterations team self-organization. So, the Team figures 147 00:09:35,900 --> 00:09:39,600 out how to work and high team accountability. The team is accountable 148 00:09:39,800 --> 00:09:40,800 to itself. 149 00:09:43,400 --> 00:09:47,400 User stories are the smallest unit of work and they're typically 150 00:09:47,400 --> 00:09:51,500 expressed as a benefit, to the end user. So we're always thinking about the customer 151 00:09:51,500 --> 00:09:55,300 as we're working through our requirements, user stories, essentially being our 152 00:09:55,300 --> 00:09:59,400 requirements, right? As a, as an online 153 00:09:59,400 --> 00:10:03,900 Shopper, I would like to buy a sweater so that I can be warm in the winter. 154 00:10:04,000 --> 00:10:08,900 For example, the benefit to the customer is always in the user story and it's the smallest unit of 155 00:10:08,900 --> 00:10:12,700 work. This is what actually ends up going on the on the cards that we prioritize 156 00:10:12,700 --> 00:10:13,300 on. 157 00:10:13,400 --> 00:10:14,700 Our scrum boards. 158 00:10:16,900 --> 00:10:20,700 Now, the backlog is by far the simplest and in my 159 00:10:20,700 --> 00:10:24,900 opinion, by far, the most powerful tool in any kind of project management. Including 160 00:10:24,900 --> 00:10:28,700 agile project management, a backlog, simply a prioritized 161 00:10:28,700 --> 00:10:31,100 list of user stories. 162 00:10:32,300 --> 00:10:36,800 And when used properly you never have to say, no 163 00:10:37,300 --> 00:10:41,500 to any requirement ever, again in the future, because there's a prioritized 164 00:10:41,500 --> 00:10:45,900 list of estimated effort and when someone comes 165 00:10:45,900 --> 00:10:49,800 in and says, we have a bug that needs to get fixed or the CEO is requested 166 00:10:49,800 --> 00:10:52,500 that we round all the corners and make everything pink. 167 00:10:54,400 --> 00:10:58,900 You can say that's terrific, we can do that. What are we not going to do in this 168 00:10:58,900 --> 00:11:02,700 iteration? In order to accommodate that we're in? Are 169 00:11:02,700 --> 00:11:05,900 prioritized list does this story fit? 170 00:11:06,800 --> 00:11:10,900 And what's the cost of inserting it? Because you can't just stuff 171 00:11:10,900 --> 00:11:14,900 stories into a backlog with a Time. Boxed cycle. It's a finite amount 172 00:11:14,900 --> 00:11:18,800 of time. You can only do so much work and so if you if you if you're 173 00:11:18,800 --> 00:11:22,900 going to insert stories into the backlog, whatever comes after those 174 00:11:22,900 --> 00:11:24,000 stories may not. 175 00:11:24,200 --> 00:11:25,400 Get into this iteration. 176 00:11:28,000 --> 00:11:32,200 So if you groom your backlog honestly, and transparently, 177 00:11:33,000 --> 00:11:37,600 it's a terrific way to manage projects and you never have to say, no, again, you just have to 178 00:11:37,600 --> 00:11:40,100 prioritize against other work. 179 00:11:41,800 --> 00:11:45,400 An iteration is a single team cycle. And the goal of most iterations is to 180 00:11:45,400 --> 00:11:49,700 reach working software at the end. Especially and the in the traditional 181 00:11:49,700 --> 00:11:53,800 actual world, the goal of each iteration is to deliver working software at the end of 182 00:11:53,800 --> 00:11:54,500 that cycle. 183 00:11:55,900 --> 00:11:59,200 Now we talked about high team accountability. The stand-up meeting 184 00:11:59,800 --> 00:12:03,500 is the main tool of hi team, accountability 185 00:12:03,700 --> 00:12:07,900 on in scrum and it's a daily short team meeting or each 186 00:12:07,900 --> 00:12:11,900 member addresses. The days challenges, you literally stand up and you 187 00:12:11,900 --> 00:12:15,900 talk about what I did yesterday, what I'm doing today and 188 00:12:15,900 --> 00:12:19,800 What's blocking me? What's keeping me from doing my work effectively today. 189 00:12:21,000 --> 00:12:25,300 Now, the reason this is such a powerful tool is because when you stand up with your team every day, 190 00:12:26,200 --> 00:12:28,400 And you have to tell your team. This is what I did yesterday. 191 00:12:30,000 --> 00:12:34,900 And this is what I'm doing today and this is why I'm not getting my work done. All of a sudden. If you were to stand up 192 00:12:34,900 --> 00:12:38,900 there and say, well yesterday, I surfed Facebook all day long. And today I'm going to buy 193 00:12:38,900 --> 00:12:42,800 some shoes online and tomorrow and what's getting in my way is all 194 00:12:42,800 --> 00:12:46,700 this work because I can't buy shoes, right? You can't, you can't have that 195 00:12:46,700 --> 00:12:50,900 conversation on a regular basis with your team. They're going to 196 00:12:50,900 --> 00:12:54,000 get fairly frustrated with you fairly quickly. 197 00:12:55,000 --> 00:12:59,400 And so, what you're doing is you're introducing a layer of transparency, a level of transparency, 198 00:13:00,000 --> 00:13:04,900 into your team, Dynamic on a daily basis. And if you can't get your work done, if 199 00:13:04,900 --> 00:13:08,500 people see that a card is story is stuck and it's not moving 200 00:13:08,500 --> 00:13:12,800 forward, they could say Jeff, why is that card stuck, here's What's blocking me 201 00:13:13,000 --> 00:13:17,900 and then someone will help you get that unblocked so that you can move forward with your task. This 202 00:13:17,900 --> 00:13:21,900 is a terrific team accountability tool and it keeps everybody aware of where 203 00:13:21,900 --> 00:13:24,600 the team is today and where they're going tomorrow. And how the 204 00:13:24,800 --> 00:13:26,400 Chris is coming along. 205 00:13:28,000 --> 00:13:32,800 There are two meetings that bookend and iteration at the end of the iteration, there's a 206 00:13:32,800 --> 00:13:36,900 retrospective now. Retrospective is a meeting at the end of each of 207 00:13:36,900 --> 00:13:40,500 these iterations that takes an honest look at what went 208 00:13:40,500 --> 00:13:44,700 well and what didn't go so well during that last iteration during that 209 00:13:44,700 --> 00:13:48,700 last time box. So as a team you reflect back and say 210 00:13:49,000 --> 00:13:53,800 this is what went? Well let's keep doing that. This is what didn't go. Well, let's 211 00:13:53,800 --> 00:13:56,200 fix that and you assign an owner. 212 00:13:56,900 --> 00:14:00,700 To fix. What didn't go? Well, someone has to personally be responsible 213 00:14:00,900 --> 00:14:04,800 for improving the handoff from design to engineering or two 214 00:14:04,800 --> 00:14:08,800 for fixing the login problems for the wiki or whatever it is that kept your 215 00:14:08,800 --> 00:14:12,500 team from being productive that week. So we're not just doing iterative 216 00:14:12,500 --> 00:14:16,600 product development. We're also doing iterative process 217 00:14:16,600 --> 00:14:17,600 Improvement 218 00:14:18,500 --> 00:14:22,800 So, we're making our product better in the short time Cycles, but we're also working 219 00:14:22,800 --> 00:14:26,200 better. We're learning how to work more effectively as a team by having these 220 00:14:26,200 --> 00:14:30,300 introspective. Retrospectives, at the end of every iteration, 221 00:14:32,600 --> 00:14:35,300 Now, the other end of the meeting is the iteration planning meeting. 222 00:14:36,400 --> 00:14:40,300 And that's where you plan, what you're going to do for the next 223 00:14:40,300 --> 00:14:44,300 iteration, the entire team needs to be at that meeting design product, engineering 224 00:14:44,300 --> 00:14:48,800 content, editorial. Whoever needs to be there. Discuss what we're going to 225 00:14:48,800 --> 00:14:49,400 work on. 226 00:14:50,400 --> 00:14:54,700 Prioritized the stories and make a plan for the next week or for the next 227 00:14:54,700 --> 00:14:58,700 two weeks. Now, my experience the most successful teams 228 00:14:58,700 --> 00:15:02,300 also, do story Gathering or story writing, and estimation, 229 00:15:02,300 --> 00:15:06,600 during the iteration planning meeting some teams like to separate those out into separate 230 00:15:06,600 --> 00:15:10,700 meetings and that's fine. In my experience, the successful teams I've 231 00:15:10,700 --> 00:15:14,000 worked with have done all of that together. In this meeting, they write their stories together, 232 00:15:14,000 --> 00:15:18,100 they estimate them together, they prioritize them together 233 00:15:18,100 --> 00:15:20,100 and they discuss them so they 234 00:15:20,400 --> 00:15:24,600 Plan for how to move forward for the next two weeks over the next 235 00:15:24,600 --> 00:15:25,100 week. 236 00:15:27,200 --> 00:15:31,900 Now, one of the interesting things that's come up that came up early in the days of trying to integrate agile user experience as the 237 00:15:31,900 --> 00:15:35,000 concept of staggered, Sprint's or Sprint zero. 238 00:15:36,300 --> 00:15:40,900 And this was popularized by Lynn Miller and Desiree. See in a paper that 239 00:15:40,900 --> 00:15:44,900 they wrote about think in 2007 where they discussed the concept of a 240 00:15:44,900 --> 00:15:48,600 Sprint 0, where design Works, a Sprint 241 00:15:48,600 --> 00:15:50,700 ahead of engineering 242 00:15:53,100 --> 00:15:57,200 To Define and design what will get built in the next iteration? 243 00:15:59,100 --> 00:16:03,100 Now, what's interesting is that this works really well as a 244 00:16:03,100 --> 00:16:07,900 transition between waterfall and true agile, 245 00:16:07,900 --> 00:16:11,900 ux and lean ux integration, but it's not where you want to stop along 246 00:16:11,900 --> 00:16:15,800 the way. Because what happens here, is that you've created a 247 00:16:15,800 --> 00:16:19,600 set of many waterfalls, actually, you can see it in the diagram. You can see this little 248 00:16:19,600 --> 00:16:23,900 waterfalls coming through. There you, the designers are designing up front. And, in the first time that 249 00:16:23,900 --> 00:16:27,900 the engineer, see, it is on day, one of the next Sprint. So 250 00:16:27,900 --> 00:16:28,900 then they have to estimate 251 00:16:29,100 --> 00:16:33,600 It at that point and decide what? They can, and can't get 252 00:16:33,600 --> 00:16:37,200 done from that design in the next. Iteration 253 00:16:38,000 --> 00:16:42,700 anything that can't get done in the next iteration is waste. That's a waste of the 254 00:16:42,700 --> 00:16:46,700 designers time. It's a waste of conversation, it's a waste of time and so that 255 00:16:46,700 --> 00:16:50,800 cross functional integration doesn't happen. Meanwhile, the designers are 256 00:16:50,800 --> 00:16:54,900 designing for the next iteration and supporting the current iteration splitting 257 00:16:54,900 --> 00:16:58,900 their attention. And costing them, a lot of times through costs, the context switching, 258 00:17:00,000 --> 00:17:04,700 And at no given point is the entire team. Working on the same thing. At the same 259 00:17:04,700 --> 00:17:06,600 time and building that shared understanding, 260 00:17:08,500 --> 00:17:12,600 So, as a transition, this is a great step because it introduces teams to short of time, 261 00:17:12,600 --> 00:17:16,900 Cycles, greater conversation and greater transparency between teams, 262 00:17:17,000 --> 00:17:21,800 engineering and user experience and product, and so forth. But this is not where you want to 263 00:17:21,800 --> 00:17:25,100 end up and so the question is, how do we integrate 264 00:17:25,900 --> 00:17:29,400 lean ux cross-functional collaboration into a 265 00:17:29,400 --> 00:17:33,800 scrum process and what's nice is that scrum is rhythmic. There's a 266 00:17:33,800 --> 00:17:37,800 rhythm to it. There's a meeting Cadence that happens through there and we can use those as 267 00:17:37,800 --> 00:17:38,200 mild. 268 00:17:38,500 --> 00:17:42,500 It's to build in these lean ux activities. So again, we'll take two-week 269 00:17:42,500 --> 00:17:46,800 Sprints as the model for this that are tied together by some kind of a theme. 270 00:17:47,700 --> 00:17:51,100 A project, a feature, an effort that the team is doing. 271 00:17:52,800 --> 00:17:56,800 The sketching, the ideation, the prototyping, the concept eating 272 00:17:56,900 --> 00:18:00,900 the early validation, the, the lean 273 00:18:00,900 --> 00:18:04,800 ux work happens before 274 00:18:04,800 --> 00:18:08,900 the theme starts before the project starts with the entire team for 275 00:18:08,900 --> 00:18:12,900 a day, a half a day, two days. Well, however long it 276 00:18:12,900 --> 00:18:16,400 takes for that team to build a shared understanding of what they're building. 277 00:18:16,700 --> 00:18:20,800 What direction, they like to take the solution in and how they'll measure 278 00:18:20,800 --> 00:18:21,300 success. 279 00:18:22,500 --> 00:18:26,700 But do so together as a cross-functional team, now I've done these 280 00:18:26,700 --> 00:18:30,700 Inception workshops with a last half a day and I've done them when they've last five days. 281 00:18:31,800 --> 00:18:35,900 But at the end of that, we have a significantly clear goal of what 282 00:18:35,900 --> 00:18:39,900 we're building and how we're approaching it and what everybody needs to do to 283 00:18:39,900 --> 00:18:43,800 move forward. Now we take the output 284 00:18:44,900 --> 00:18:47,100 of those efforts 285 00:18:48,600 --> 00:18:52,700 and we bring them into the iteration planning meetings, we bring the sketches, we bring 286 00:18:52,700 --> 00:18:56,900 the, the Proto personas, we bring the research notes from 287 00:18:57,100 --> 00:19:01,900 from the research from the collaborative, Discovery efforts that we've done as a team and and we and we 288 00:19:01,900 --> 00:19:05,800 build our prioritized backlog based on that. 289 00:19:05,800 --> 00:19:07,000 Shared in sight. 290 00:19:09,900 --> 00:19:13,900 But we don't rest on The Laurels of that particular effort. 291 00:19:13,900 --> 00:19:17,900 We build in a testing regimen 292 00:19:18,100 --> 00:19:22,600 that has a speaking to customers on a weekly basis. So through every two weeks 293 00:19:22,600 --> 00:19:26,800 Sprint there is at least one two or three conversations with 294 00:19:26,800 --> 00:19:30,800 customers that are continuing to validate our approach 295 00:19:31,300 --> 00:19:35,900 and the evolution of our thinking, as we move forward. And so what we're doing again, 296 00:19:36,100 --> 00:19:38,400 is that there's a significant effort up front 297 00:19:39,200 --> 00:19:42,600 to build that shared understanding as a team and then to motivate 298 00:19:43,900 --> 00:19:47,900 Continued momentum throughout the development process. 299 00:19:47,900 --> 00:19:51,400 We take bits and pieces of those activities. Maybe we'll do a 300 00:19:51,400 --> 00:19:55,900 brainstorm to kick-off iteration to maybe, we'll do a design studio 301 00:19:56,000 --> 00:20:00,900 to kick off iteration 3 because we're not sure exactly how to how to design something as a team. 302 00:20:01,200 --> 00:20:05,800 And then we bring the assets. Those transient artifacts that we create in 303 00:20:05,800 --> 00:20:09,300 these lightweight sessions, whether they're again, sketches, 304 00:20:09,300 --> 00:20:13,500 prototypes notes conversations and we plan 305 00:20:13,700 --> 00:20:17,500 Iterations together. And then we continue to validate our 306 00:20:17,500 --> 00:20:21,700 thinking with a steady stream of qualitative Insight through 307 00:20:21,700 --> 00:20:25,900 customer conversation. Now what's interesting, is that as you start to build, you 308 00:20:25,900 --> 00:20:29,800 start to launch product, you're also going to gain quantitative Insight 309 00:20:30,000 --> 00:20:33,500 because you're going to start launching software at the end of each. One of these iterations. 310 00:20:35,400 --> 00:20:39,500 And so the testing and the learning comes in with a 360 degree view of your 311 00:20:39,500 --> 00:20:43,700 customer. You're going to the qualitative Insight because you're talking to customers every week 312 00:20:43,900 --> 00:20:47,900 and you're getting quantitative Insight usage metrics based on the software that you're actually 313 00:20:47,900 --> 00:20:49,700 launching every two weeks. 314 00:20:51,800 --> 00:20:55,700 and what's interesting is that you'll start from sketches and as you work together as a 315 00:20:55,700 --> 00:20:56,400 team, 316 00:20:57,700 --> 00:21:01,900 you'll begin to understand the requirements. For your colleagues, you'll build 317 00:21:01,900 --> 00:21:04,200 a level of trust and camaraderie. 318 00:21:05,500 --> 00:21:09,700 And understanding of what each engineer on your team needs to move forward or what each 319 00:21:09,700 --> 00:21:13,700 designer needs for them to do their job. And so, you'll understand you'll get a sense of whether 320 00:21:13,900 --> 00:21:17,900 this level of fidelity is enough. With the, we need to do visual design mock-ups or 321 00:21:17,900 --> 00:21:21,500 maybe just some whiteboard sketches will get the conversation moving forward 322 00:21:22,200 --> 00:21:26,400 and the further that you work, the longer that you work with your team's, the more trust is 323 00:21:26,400 --> 00:21:30,900 built. The faster you can move forward and have conversations based on artifacts 324 00:21:30,900 --> 00:21:32,200 at this level of fidelity. 325 00:21:35,500 --> 00:21:39,600 now, what's interesting is that the integration of 326 00:21:39,600 --> 00:21:42,700 of lean ux and agile, 327 00:21:44,000 --> 00:21:48,800 Forces, another level of responsibility onto the team because you 328 00:21:48,800 --> 00:21:52,800 don't have a clear roadmap for say and that you're 329 00:21:52,800 --> 00:21:56,600 working towards specific business outcomes. The people who have a 330 00:21:56,600 --> 00:22:00,800 stake in the success of your project, your managers business line 331 00:22:00,800 --> 00:22:02,100 owners executives 332 00:22:03,100 --> 00:22:07,900 We'll want to know what you're doing and how you're doing and how you're progressing. 333 00:22:08,200 --> 00:22:12,600 So the onus is on the team to continually communicate, 334 00:22:12,600 --> 00:22:16,700 both up and out to your colleagues, about your progress, 335 00:22:16,900 --> 00:22:20,600 you have to insert a level of transparency that may not be 336 00:22:20,600 --> 00:22:24,500 common to the way you're currently building products. And when you build that level of 337 00:22:24,500 --> 00:22:28,900 transparency everyone on your team understands, what the team is doing because 338 00:22:28,900 --> 00:22:32,400 you're having these daily stand-ups. And these iteration planning meetings and retrospectives 339 00:22:33,000 --> 00:22:34,000 Your stakeholders. 340 00:22:35,400 --> 00:22:36,900 Have a sense of what's Happening. 341 00:22:38,200 --> 00:22:42,800 How you're progressing towards your success, your metrics and what you're working on. 342 00:22:44,000 --> 00:22:48,300 Your product owners and your business line leaders begin gain a level of 343 00:22:48,300 --> 00:22:52,800 comfort that you're progressing towards a solution that solves their needs. The 344 00:22:52,800 --> 00:22:56,800 thing to keep in mind is that Executives will always want to see what you're up to. 345 00:22:56,900 --> 00:23:00,200 So the more public that you can make your 346 00:23:01,200 --> 00:23:05,500 progress, the better if you can post your success 347 00:23:05,500 --> 00:23:09,900 metrics on a screen at work or in a print out every day that 348 00:23:09,900 --> 00:23:13,700 says here's how we're progressing towards our conversion rate goals. Here's how we're progressing. 349 00:23:13,800 --> 00:23:17,700 Towards our sign up goals that will drive things forward 350 00:23:17,700 --> 00:23:18,500 significantly. 351 00:23:19,700 --> 00:23:23,800 One thing to keep in mind is that you have to keep you 352 00:23:23,800 --> 00:23:26,700 other departments aware of what you're doing. 353 00:23:27,800 --> 00:23:31,800 It's who really easy to get caught up in these fast, iterative Cycles. 354 00:23:33,500 --> 00:23:37,700 And forget that there are other people dependent on the software that you're 355 00:23:37,700 --> 00:23:41,100 launching within your company. Specifically, I'm thinking about marketing, 356 00:23:42,400 --> 00:23:43,700 And customer support. 357 00:23:45,600 --> 00:23:49,900 If you are launching new software into production and it changes the way that the product 358 00:23:49,900 --> 00:23:53,700 workflow behaves. There are people in a call 359 00:23:53,700 --> 00:23:57,500 center somewhere who have a script that is based on the old 360 00:23:57,500 --> 00:24:01,900 workflow. If you break that script, you're going to get a very angry 361 00:24:01,900 --> 00:24:05,300 phone call or an email from the manager of that call center very, very quickly. 362 00:24:07,300 --> 00:24:11,800 If you're launching features that are succeeding and you don't tell the marketing department, they're going to be frustrated 363 00:24:11,800 --> 00:24:15,900 because that's what they like to do. They like to advertise and promote but there are new features 364 00:24:15,900 --> 00:24:19,700 for the product to use, maybe we can change our pricing scheme, maybe we can do something different 365 00:24:19,700 --> 00:24:23,900 retain, new customers, the onus on you, as a team is to be as 366 00:24:23,900 --> 00:24:27,900 transparent as possible, not only with your stakeholders, but with other 367 00:24:27,900 --> 00:24:31,700 dependent disciplines out from you and ensure that they're aware of what you're doing, 368 00:24:32,100 --> 00:24:36,600 reach out to the call center and say, next Thursday, we're pushing out this new 369 00:24:36,600 --> 00:24:37,000 workflow. 370 00:24:37,400 --> 00:24:41,300 Here's what it's going to look like. Here's how you the scripts should change. 371 00:24:42,100 --> 00:24:46,800 Let the marketing folks know that you've been iterating on a feature for a month and it looks like it's going to stick. 372 00:24:47,800 --> 00:24:51,500 And they have an opportunity to promote it to a certain segment that's been asking for it for a 373 00:24:51,500 --> 00:24:52,000 while. 374 00:24:53,700 --> 00:24:57,700 The onus is on you as a team to ensure that your organization allows you to 375 00:24:57,700 --> 00:25:01,600 continue to move at this pace, because if they can't see into what you're 376 00:25:01,600 --> 00:25:05,700 doing, they're going to start asking questions and asking you to stop and write reports and have 377 00:25:05,700 --> 00:25:09,700 meetings. And that's going to be the road block and making it in stopping this, 378 00:25:09,700 --> 00:25:11,900 iterative Learning and Development process. 379 00:25:14,400 --> 00:25:18,600 One more note on story Gathering and prioritization. It's 380 00:25:18,600 --> 00:25:22,800 as I mentioned before, agile is an exercise. In prioritization 381 00:25:22,800 --> 00:25:26,900 we have to choose what work we do in each 382 00:25:26,900 --> 00:25:30,700 iteration. We have to decide. We're going to work on this 383 00:25:30,700 --> 00:25:33,900 but not on that. And by building a shared understanding, 384 00:25:33,900 --> 00:25:37,700 as a team, we have a much clearer sense of 385 00:25:37,700 --> 00:25:41,200 what we'd like to work on, but as far as the prioritization 386 00:25:41,200 --> 00:25:44,300 exercise is concerned, everyone has to be involved. 387 00:25:44,900 --> 00:25:48,900 In the prioritization exercise. This is by far the most inclusive slide. I could 388 00:25:48,900 --> 00:25:52,500 find on the internet but everyone has to be 389 00:25:52,500 --> 00:25:55,000 involved in the prioritization. 390 00:25:56,200 --> 00:26:00,900 Designers have to be part of the conversation to say. This is I can't the story can't be 391 00:26:00,900 --> 00:26:04,800 first because it's going to take me three days to design. It Engineers could say, well, this story 392 00:26:04,800 --> 00:26:08,600 can't be first because I have to do some research about the technology by having those conversations. 393 00:26:08,600 --> 00:26:12,800 You can build a backlog that buys time for everybody 394 00:26:12,800 --> 00:26:16,600 on the team to do their particular job and the same goes for 395 00:26:16,600 --> 00:26:17,200 estimation 396 00:26:18,800 --> 00:26:22,900 Sometimes a heavily designed story. May 397 00:26:22,900 --> 00:26:24,700 take very little time to implement. 398 00:26:26,000 --> 00:26:30,700 Other times the implications of adding a checkbox to the UI, 399 00:26:30,700 --> 00:26:33,100 something that probably take 30 seconds for a designer. 400 00:26:34,100 --> 00:26:38,800 Could trigger six months worth of development work, simply by checking that box you 401 00:26:38,800 --> 00:26:42,900 have to have these collaborative conversations, these cross-functional conversations about 402 00:26:42,900 --> 00:26:46,800 the estimation process so that gets baked in and then you can 403 00:26:46,800 --> 00:26:50,700 prioritize properly and if you're not getting the time that you 404 00:26:50,700 --> 00:26:54,400 need, you have to negotiate for it. You have to have those 405 00:26:54,400 --> 00:26:57,200 conversations even Midstream to say 406 00:26:58,600 --> 00:27:02,800 I'm not going to be ready like I thought for this particular car that's coming up, is there anything that we can prioritize 407 00:27:02,800 --> 00:27:06,600 above that? You have to have those conversations and the only way to have those, 408 00:27:06,800 --> 00:27:10,900 if you're actually participating in the process itself, whether 409 00:27:10,900 --> 00:27:14,200 designer engineer product managers that are everyone has to be involved.