1 00:00:01,760 --> 00:00:04,120 Hey there. Welcome to the Better Business 2 00:00:04,120 --> 00:00:07,760 Analysis podcast. While Ben's gearing up for the 3 00:00:07,760 --> 00:00:11,440 show, I've got an exciting offer just for you right now. 4 00:00:11,440 --> 00:00:14,400 When you enroll in our Certified Better Business Analysis Level 5 00:00:14,400 --> 00:00:18,560 One course, use the Code Podcast at checkout to score a whopping 6 00:00:18,560 --> 00:00:22,160 50% off. Don't miss out on this fantastic 7 00:00:22,160 --> 00:00:25,640 opportunity to elevate your skills and advance your career. 8 00:00:26,080 --> 00:00:28,120 Head over to our website and enroll today. 9 00:00:28,880 --> 00:00:32,439 The Better Business Analysis Institute presence. 10 00:00:32,439 --> 00:00:36,200 The Better Business Analysis Podcast with Benjamin Walsh. 11 00:00:41,040 --> 00:00:43,680 Hi everybody, it's Benjamin Walsh from the Better Business 12 00:00:43,680 --> 00:00:47,920 Analysis Institute. Check out our website at BBA dot 13 00:00:47,920 --> 00:00:51,440 Institute. Now this week we are going to be 14 00:00:51,440 --> 00:00:55,680 delving into a topic that I kind of found by accident and I'm 15 00:00:55,680 --> 00:00:58,040 going to give you back story as I always do before we get dive 16 00:00:58,040 --> 00:01:00,520 into the topic. So I was working at an 17 00:01:00,520 --> 00:01:05,200 organization, a consultancy. We had a large intake of 18 00:01:05,200 --> 00:01:11,160 graduate testers, and one of my responsibilities was to give 19 00:01:11,160 --> 00:01:15,280 these testers an idea about what business analysis was all about 20 00:01:15,720 --> 00:01:20,080 and explain the benefits to testers when it came to business 21 00:01:20,080 --> 00:01:23,640 analysis. Now, one of the traditional 22 00:01:23,640 --> 00:01:28,600 models of testing, if you're not from that world, one of the 23 00:01:28,600 --> 00:01:32,560 fundamental models back in the day is something called the V 24 00:01:32,560 --> 00:01:35,760 model. Now, these testers were new. 25 00:01:36,080 --> 00:01:39,000 They were being trained in testing, They didn't really know 26 00:01:39,000 --> 00:01:42,080 what the V model was, but a lot of BAS don't know what AV model 27 00:01:42,080 --> 00:01:46,640 is, and a lot of testers will look at the terminology V model 28 00:01:46,640 --> 00:01:48,840 and maybe go, Oh yeah, that's really old. 29 00:01:49,360 --> 00:01:50,800 How? How's that applicable in an 30 00:01:50,800 --> 00:01:56,320 agile world? Now we just pause there for a 31 00:01:56,320 --> 00:02:00,440 second and just rewind and say look, if you're a tester, what 32 00:02:00,440 --> 00:02:04,080 is your job? So your job is to test that the 33 00:02:04,080 --> 00:02:07,960 product is working effectively, that the process can be 34 00:02:08,240 --> 00:02:11,960 completed, and ideally, if you're, you know, doing proper 35 00:02:11,960 --> 00:02:14,800 functional testing, you're looking at can the job to be 36 00:02:14,800 --> 00:02:19,440 done be completed successfully? You raise defects and bugs and 37 00:02:19,440 --> 00:02:23,560 whatnot, and some of the artifacts or outputs that you 38 00:02:23,560 --> 00:02:28,200 are trying to produce actually align very nicely with some of 39 00:02:28,200 --> 00:02:30,960 the artifacts that we produce in the wood of BA and also in the 40 00:02:30,960 --> 00:02:33,760 architecture space. So if you like the 41 00:02:34,920 --> 00:02:39,240 specifications that we write, the high level requirements, 42 00:02:39,240 --> 00:02:43,000 detail requirements, then the architects or devs might put 43 00:02:43,000 --> 00:02:47,000 together a solution design and then you know write code if you 44 00:02:47,000 --> 00:02:50,720 like, which go into a product map, two different testing 45 00:02:50,720 --> 00:02:55,280 artifacts that need to be done throughout testing and there's 46 00:02:55,280 --> 00:02:57,040 something called shift left and testing. 47 00:02:57,040 --> 00:02:59,760 It's really around getting testing up done up front. 48 00:03:00,200 --> 00:03:04,600 And so things like a test plan done by maybe a test manager or 49 00:03:04,600 --> 00:03:06,480 a test lead should be done quite early. 50 00:03:06,720 --> 00:03:09,720 And so the idea of the V model is that you say, well, when the 51 00:03:09,720 --> 00:03:12,480 high level requirements are put together, you know you should 52 00:03:12,480 --> 00:03:14,680 start on your test plan. And when the detail requirements 53 00:03:14,680 --> 00:03:16,600 are done, you should start to go into more detail. 54 00:03:16,600 --> 00:03:19,400 And when the specification's done, you could start getting 55 00:03:19,400 --> 00:03:22,240 into your test cases and and and so forth. 56 00:03:22,240 --> 00:03:26,640 So there's a map between kind of things like unit tests which 57 00:03:27,160 --> 00:03:31,160 connect to packets of code, and there's different levels of 58 00:03:31,160 --> 00:03:34,680 abstraction and testing, much like there is in the world of 59 00:03:34,680 --> 00:03:38,080 business analysis and also solution design, architecture 60 00:03:38,080 --> 00:03:40,480 and development being subcategories of that. 61 00:03:41,120 --> 00:03:43,400 So the V model is about mapping those two, right? 62 00:03:43,400 --> 00:03:47,360 And it and it and it existed to say we should start these things 63 00:03:47,480 --> 00:03:50,640 early as testers. And this is actually the input. 64 00:03:51,000 --> 00:03:52,840 So you can take two things away from that. 65 00:03:52,840 --> 00:03:57,080 One is that testing should start early, as I've just said, but 66 00:03:57,080 --> 00:04:00,880 also that testers aren't making up test cases or test plans from 67 00:04:00,880 --> 00:04:03,360 nothing. They are using the artifacts 68 00:04:03,480 --> 00:04:07,000 created by the BA for the first half and then the solution 69 00:04:07,000 --> 00:04:09,280 designer, the reply to the requirements and then the 70 00:04:09,280 --> 00:04:13,840 developer, if you like to create their materials, right. 71 00:04:14,320 --> 00:04:18,920 So you know and if we just look at the middle segment there, you 72 00:04:18,920 --> 00:04:22,400 know test cases come from the requirements. 73 00:04:22,400 --> 00:04:25,120 They should the user stories have acceptance criteria which 74 00:04:25,120 --> 00:04:28,120 link to test cases. So I think it's important in 75 00:04:28,120 --> 00:04:31,160 this episode to understand who's using your requirements. 76 00:04:31,640 --> 00:04:35,040 And I would say a large audience was there's there's two 77 00:04:35,120 --> 00:04:38,200 audiences. If we take a kind of a parallel 78 00:04:38,200 --> 00:04:43,720 path here, one is the tester is using your user stories to 79 00:04:43,720 --> 00:04:46,320 correct test cases. Because ultimately they're 80 00:04:46,320 --> 00:04:50,480 testing whether or not the user story is acceptable and it has 81 00:04:50,480 --> 00:04:53,040 the acceptance criteria being completed. 82 00:04:53,720 --> 00:05:00,040 And at the same time and generally, first, the program is 83 00:05:00,040 --> 00:05:04,520 writing code, producing the product, adding to the product, 84 00:05:04,720 --> 00:05:08,800 you know, improving the product based on the user story. 85 00:05:09,040 --> 00:05:11,600 So the user story is critical to both the developer knowing what 86 00:05:11,600 --> 00:05:13,920 to do and also the tester to know what to test. 87 00:05:13,920 --> 00:05:16,920 And then the words come together when you go through the testing 88 00:05:16,920 --> 00:05:20,520 process. So this is, this is true. 89 00:05:21,120 --> 00:05:26,320 You know, this is really true proper development and 90 00:05:26,320 --> 00:05:30,720 regardless of methodology, regardless of waterfall or agile 91 00:05:30,720 --> 00:05:32,000 if you like. And I'm just going to use those 92 00:05:32,000 --> 00:05:33,760 two examples. There are many others. 93 00:05:34,560 --> 00:05:37,360 They're the most, you know, the ones that we talked about. 94 00:05:37,360 --> 00:05:41,600 They're the most. This is true regardless of of of 95 00:05:41,600 --> 00:05:44,040 what kind of methodology you're using. 96 00:05:44,360 --> 00:05:46,400 This is what happens. This is the whole point, OK. 97 00:05:46,400 --> 00:05:49,240 So it doesn't matter if you do it rapidly and slices like Agile 98 00:05:49,560 --> 00:05:51,600 or you're doing it as a Big Bang. 99 00:05:52,000 --> 00:05:54,120 This is, you know, you're testing everything at the same 100 00:05:54,120 --> 00:05:56,080 time, you're, you know, writing requirements and you're 101 00:05:56,080 --> 00:05:57,240 delivering well at the same time. 102 00:05:57,240 --> 00:06:00,240 Which is more waterful approach, approach, which is one end of 103 00:06:00,240 --> 00:06:02,720 the spectrum. This is true. 104 00:06:02,840 --> 00:06:05,840 So anywhere on that spectrum, this model is true. 105 00:06:05,960 --> 00:06:10,880 OK, so the V model is true. It is not something that is old 106 00:06:11,600 --> 00:06:14,440 and may have been developed a while ago, but it is true. 107 00:06:14,520 --> 00:06:18,760 It is a fact that this happens regardless of methodology, OK? 108 00:06:19,000 --> 00:06:21,640 And it's really important to know that this exists for 109 00:06:21,640 --> 00:06:25,160 testers and us, but also it shows who's using our 110 00:06:25,160 --> 00:06:27,760 requirement. We are writing our requirements 111 00:06:27,760 --> 00:06:30,800 for the developer. We are writing it for the 112 00:06:30,800 --> 00:06:33,440 tester, right? They need it to complete their 113 00:06:33,440 --> 00:06:35,920 process. So by understanding this world, 114 00:06:35,920 --> 00:06:40,120 you as ABA can write better user stories, OK? 115 00:06:40,120 --> 00:06:43,800 You can provide more clarity, you can be more concise, you can 116 00:06:43,800 --> 00:06:48,200 be more accurate and transparent and help these two audiences 117 00:06:48,200 --> 00:06:52,440 which are your prime audience of your output to to really 118 00:06:52,440 --> 00:06:55,000 understand what your customer wants. 119 00:06:55,520 --> 00:06:57,840 And of course your first job is to make sure that the 120 00:06:57,840 --> 00:07:04,920 requirement reflects, you know, adds to the epic if you like or 121 00:07:04,920 --> 00:07:08,120 the and then the themes, the objective of the project and 122 00:07:08,120 --> 00:07:11,320 that your product owner and whatever shape or form they 123 00:07:12,360 --> 00:07:15,920 exist in either the end customer business owner or a proper true 124 00:07:16,200 --> 00:07:18,080 product owner that you have captured. 125 00:07:18,120 --> 00:07:22,080 You know what they want in true detail after you've translated 126 00:07:22,080 --> 00:07:25,280 that, which is the process of business analysis, elicitation 127 00:07:25,280 --> 00:07:28,280 and analysis and then translation into your user 128 00:07:28,280 --> 00:07:30,960 stories, right? So if you like, that first half 129 00:07:30,960 --> 00:07:34,280 is the input and the process you go through and then the output 130 00:07:34,280 --> 00:07:38,040 is testers and developers okay and probably designers as well. 131 00:07:38,520 --> 00:07:41,040 So during the design phase you may have designers who have to 132 00:07:41,040 --> 00:07:43,520 read your requirements and to be honest, I find them the most 133 00:07:43,520 --> 00:07:47,200 tricky because they can be the most creative and move quite far 134 00:07:47,200 --> 00:07:49,640 away from some of the functions you're just trying to get in 135 00:07:49,640 --> 00:07:51,120 there. So you need to, you know, use 136 00:07:51,120 --> 00:07:53,880 this process to to also map to them. 137 00:07:54,480 --> 00:07:57,000 OK, so this is who uses your requirements. 138 00:07:57,000 --> 00:07:59,000 It's really important. I think that's the number one 139 00:07:59,240 --> 00:08:02,320 lesson from this whole topic today. 140 00:08:02,560 --> 00:08:06,080 But so if you've taken that away, then this all the rest of 141 00:08:06,080 --> 00:08:09,360 this is going to be bonus. And the true purpose of this 142 00:08:09,360 --> 00:08:13,920 episode today is to talk about something called Agile V Model. 143 00:08:15,240 --> 00:08:19,920 OK, And this was something I actually stumbled across. 144 00:08:20,360 --> 00:08:24,280 Obviously, conceptually it existed in my head, but I hadn't 145 00:08:24,280 --> 00:08:28,400 found a body of knowledge or really one institution or 146 00:08:28,760 --> 00:08:34,919 Wikipedia article or whatever it was that fully captured exactly 147 00:08:35,640 --> 00:08:40,799 my view of the world, which was just if the VML exists, if the 148 00:08:40,799 --> 00:08:43,679 VML is true, if that's the premise we're going with here, 149 00:08:43,960 --> 00:08:48,640 if requirements you know map to test cases, if you know it feeds 150 00:08:48,640 --> 00:08:50,880 into development and there's a relationship there, and it 151 00:08:50,880 --> 00:08:54,560 should happen ideally all at the same time, what would Agile look 152 00:08:54,560 --> 00:08:57,640 like? And for me, if you're following 153 00:08:57,640 --> 00:09:01,520 this process, so imagine AV, imagine driving down a hill and 154 00:09:01,520 --> 00:09:05,280 then right up a hill again. So this is it's AV and have you 155 00:09:05,400 --> 00:09:10,920 there's maps going down the V at the same time the testers doing 156 00:09:10,920 --> 00:09:14,200 their work as we head down the bottom of the V to the product. 157 00:09:14,200 --> 00:09:19,040 So the products down the bottom, what is it that what what would 158 00:09:19,040 --> 00:09:20,960 that look like in an agile world. 159 00:09:21,080 --> 00:09:26,920 So conceptually, I knew that if simply if as we start our V 160 00:09:27,160 --> 00:09:30,560 journey, so the test plan's done, maybe we're in a bit more 161 00:09:30,560 --> 00:09:35,200 of a structured approach once we get down to the design and kind 162 00:09:35,200 --> 00:09:40,360 of doing the release of product increments, which is agile, 163 00:09:40,920 --> 00:09:43,640 aren't we just doing the V model again and again and again and 164 00:09:43,640 --> 00:09:47,120 again, again rapidly? Aren't we just saying, well, OK, 165 00:09:47,120 --> 00:09:49,000 well then the requirement's done, It's released in the 166 00:09:49,000 --> 00:09:50,880 product, but the test and then test it. 167 00:09:52,120 --> 00:09:55,600 So with a with a waterfall project, all the requirements 168 00:09:55,600 --> 00:09:59,360 would be done into the product, the tester would test all the do 169 00:09:59,360 --> 00:10:02,320 all the tests, right? So that's the traditional V 170 00:10:02,320 --> 00:10:04,640 model. So in an agile model, wouldn't 171 00:10:04,640 --> 00:10:06,880 we just be going, well, one requirement's added to the 172 00:10:06,880 --> 00:10:10,040 product to the bucket. The tester then just takes that 173 00:10:10,040 --> 00:10:13,280 thing and tests that thing and then we know that that they 174 00:10:13,280 --> 00:10:15,840 might do other things called integration testing or 175 00:10:15,840 --> 00:10:18,960 regression testing to make sure that the product that that new 176 00:10:18,960 --> 00:10:20,720 feature of that it hasn't broken anything. 177 00:10:20,720 --> 00:10:24,560 So there's a little bit more to it, but in effect, isn't Agile 178 00:10:24,560 --> 00:10:28,280 just doing that again and again and again every, every Sprint? 179 00:10:29,240 --> 00:10:31,360 Aren't we just doing lots and lots of these? 180 00:10:32,640 --> 00:10:34,560 And So what I did is I searched it up. 181 00:10:34,560 --> 00:10:36,720 Agile remodel, there's got to be something like that. 182 00:10:36,920 --> 00:10:41,480 And I found a great place where this is articulated in in a 183 00:10:41,480 --> 00:10:46,240 fantastic manner and it's not actually from the world of all 184 00:10:47,920 --> 00:10:51,560 all projects. It is actually being talked 185 00:10:51,560 --> 00:10:54,640 about in the Internet of Things project. 186 00:10:55,200 --> 00:10:59,320 OK, so when if you don't know what Internet of Things are, 187 00:10:59,320 --> 00:11:02,800 they're all the devices, small devices, smart devices that 188 00:11:02,800 --> 00:11:07,760 exist everywhere. So it is probably was the really 189 00:11:07,760 --> 00:11:11,360 quiet revolution just before AI, but it was taken off massively. 190 00:11:11,360 --> 00:11:13,920 So these are the little smart devices that might be a sensor 191 00:11:14,360 --> 00:11:16,400 somewhere, little tiny things. You can buy them on the 192 00:11:16,400 --> 00:11:19,200 Internet, Internet, if you've got a smart home, all those 193 00:11:19,200 --> 00:11:23,480 things that connect to your phone, like the robot or the air 194 00:11:24,200 --> 00:11:27,720 conditioning unit or a sensor for the door. 195 00:11:27,720 --> 00:11:34,840 Or I've got a for example, we've taken out our our lock and we 196 00:11:34,840 --> 00:11:36,280 have a smart lock on our front door. 197 00:11:36,280 --> 00:11:39,320 That's an Internet of Things. So all those things, they're 198 00:11:39,320 --> 00:11:42,040 usually small devices. They usually last for a long 199 00:11:42,040 --> 00:11:43,800 time as in they don't draw much power. 200 00:11:43,800 --> 00:11:46,440 They only use power when they when they need to. 201 00:11:46,640 --> 00:11:49,120 The these things are all around us now. 202 00:11:49,120 --> 00:11:52,560 The sensors, the and they're built into things like drones 203 00:11:52,560 --> 00:11:55,280 and all the rest of it. So all these tiny devices now, 204 00:11:55,280 --> 00:12:00,240 not PCs, tiny devices are connected, OK, need to connect 205 00:12:00,240 --> 00:12:04,120 to wireless or the Internet and they're a piece of hardware 206 00:12:04,120 --> 00:12:07,400 generally. So all the things that were true 207 00:12:07,400 --> 00:12:13,240 of hardware programming, So what we would what we used to call 208 00:12:13,680 --> 00:12:18,360 kind of assembly code or lower level programming needs to be 209 00:12:18,360 --> 00:12:20,080 true. They need to have rapid release, 210 00:12:20,080 --> 00:12:22,920 they need to work when you release, you need to release 211 00:12:23,240 --> 00:12:26,520 full and complete, they need to work or otherwise that device 212 00:12:26,520 --> 00:12:28,840 goes offline. So, so I guess one of the things 213 00:12:28,840 --> 00:12:31,320 that is true or a better way of articulating what I've just said 214 00:12:31,640 --> 00:12:36,960 is that these devices will update and need to be updatable 215 00:12:37,040 --> 00:12:42,240 quite rapidly, right, for the software and those things need 216 00:12:42,240 --> 00:12:47,120 to continue working, as in you can't do a huge massive bunk 217 00:12:47,120 --> 00:12:50,080 release. So in order for Internet of 218 00:12:50,080 --> 00:12:54,320 Things to work effectively, there had to be some thought 219 00:12:54,320 --> 00:12:57,600 about continuous releasing, continuous testing, and all 220 00:12:57,600 --> 00:13:00,440 these things that if you're involved in a programming firm 221 00:13:00,440 --> 00:13:02,240 you understand about. We talk about continuous 222 00:13:02,240 --> 00:13:06,440 testing, continuous integration and all these things are great 223 00:13:06,440 --> 00:13:10,320 for large pieces of software, but they have to be true in the 224 00:13:10,320 --> 00:13:13,200 world of Internet of Things because if they don't then those 225 00:13:13,360 --> 00:13:16,840 those devices go offline and then you know they stop working, 226 00:13:16,840 --> 00:13:20,640 those sensors stop working. So some of the so that this area 227 00:13:20,640 --> 00:13:25,120 was forced to think about about what methodology would work if 228 00:13:25,120 --> 00:13:29,200 we naturally needed to continuously improve the 229 00:13:29,200 --> 00:13:32,520 workings of these devices. OK And what is the method that 230 00:13:32,520 --> 00:13:34,760 we use to continually improve these devices? 231 00:13:35,160 --> 00:13:37,400 It's agile, right? We need to release rapidly. 232 00:13:37,400 --> 00:13:43,040 We need to release iterations. We need to do changes rapidly on 233 00:13:43,040 --> 00:13:44,880 the fly. So we knew that was true, but 234 00:13:44,880 --> 00:13:48,440 how do we do that? So we am sure, we are sure that 235 00:13:48,680 --> 00:13:52,920 the release we've got out there is true and proper and not just 236 00:13:52,920 --> 00:13:56,080 like cowboy programming. So we need Rigger and what 237 00:13:56,080 --> 00:13:59,680 brings us Rigger, the V model having a map through. 238 00:14:00,360 --> 00:14:03,800 So they've combined and they've combined those two methodologies 239 00:14:04,120 --> 00:14:07,680 in a kind of an academic way, but in a conceptual way and now 240 00:14:07,680 --> 00:14:09,840 a real way. And they call it the Agile V 241 00:14:09,840 --> 00:14:13,960 model. So I've actually most of what 242 00:14:13,960 --> 00:14:17,320 I'm going to talk about next, I've stolen from the what's 243 00:14:17,320 --> 00:14:20,600 called the Digital Playbook. It is available if you look it 244 00:14:20,600 --> 00:14:24,040 up Digital Playbook and it's talking about what is the 245 00:14:24,040 --> 00:14:27,120 difference between Agile and kind of the Agile incident of 246 00:14:27,120 --> 00:14:30,240 things and what is the Agile V model. 247 00:14:31,320 --> 00:14:34,520 We know the benefits of Agile. We know the fact that it has 248 00:14:34,520 --> 00:14:38,480 some massive shortcomings when it comes to certain types of 249 00:14:38,480 --> 00:14:41,280 projects which are generally mission critical projects or 250 00:14:41,280 --> 00:14:45,680 complex projects. They it's really easy to think 251 00:14:45,680 --> 00:14:49,400 of when you've got your startup hat on and you're releasing a 252 00:14:49,640 --> 00:14:54,240 web app, that's fine. But if you're say dealing like I 253 00:14:54,240 --> 00:14:57,000 said with these mission critical devices that are out there that 254 00:14:57,000 --> 00:14:59,920 could be sensors on nuclear power stations, you know, these 255 00:14:59,920 --> 00:15:06,720 are things that more aligned with what I would call, yeah, 256 00:15:06,720 --> 00:15:09,280 more critical kind of pieces of infrastructure. 257 00:15:09,520 --> 00:15:12,200 It's the same kind of mindset, it's more hardware related with 258 00:15:12,200 --> 00:15:17,000 things can't go wrong, OK. If your web app has a bug, you 259 00:15:17,200 --> 00:15:20,440 you might accept that and go live with it because you're 260 00:15:20,440 --> 00:15:22,800 getting customer feedback and it's it's not going to kill 261 00:15:22,800 --> 00:15:28,120 anyone, whereas this other side could literally result in harm. 262 00:15:28,360 --> 00:15:31,800 So we need to have some structure and that involves 263 00:15:31,800 --> 00:15:33,840 complexity. So how do you do that rapidly 264 00:15:33,840 --> 00:15:38,360 without going fully, you know, waterfall and just baking in. 265 00:15:38,920 --> 00:15:41,600 Too much process and too much governance. 266 00:15:42,280 --> 00:15:46,920 And this is the answer. So when we talked about the V 267 00:15:46,920 --> 00:15:51,600 model earlier, some of the disadvantages of the V model was 268 00:15:51,600 --> 00:15:54,000 that it was inherently waterfall based. 269 00:15:54,240 --> 00:15:57,160 As in it didn't think about there was just one V, right? 270 00:15:57,160 --> 00:16:01,400 It didn't have the VVVVVV on forever, It was rigid and it was 271 00:16:01,400 --> 00:16:05,280 inflexible. It didn't support iteration or 272 00:16:06,160 --> 00:16:09,440 implemental development. It didn't really talk about MVP 273 00:16:09,440 --> 00:16:11,400 or prototypes or continuous improvement. 274 00:16:12,400 --> 00:16:16,640 And ideally because it was just one V, it wasn't possible to 275 00:16:16,640 --> 00:16:18,960 adapt to changes midway through development. 276 00:16:18,960 --> 00:16:22,080 You had already committed upfront which was you know I 277 00:16:22,080 --> 00:16:25,600 guess some of the disadvantages of waterfall and so therefore 278 00:16:25,880 --> 00:16:29,040 you know you can make small changes if you needed to and do 279 00:16:29,040 --> 00:16:31,080 it like a hybrid waterfall model. 280 00:16:31,400 --> 00:16:34,160 But it was kind of seen as having a bit of a bad 281 00:16:34,160 --> 00:16:36,480 reputation. A lot of people didn't actually 282 00:16:36,480 --> 00:16:39,440 look to the V model and it and and they literally will turn 283 00:16:39,440 --> 00:16:40,080 their heads. Have you. 284 00:16:40,720 --> 00:16:43,080 I had people turn my heads when I started talking about it and I 285 00:16:43,080 --> 00:16:45,600 was like, I don't, I don't understand why you got the bad 286 00:16:45,600 --> 00:16:48,880 thing. Some of the advantages though it 287 00:16:48,880 --> 00:16:52,560 was suited for stability when it came to complex requirements 288 00:16:54,680 --> 00:16:58,160 which was required really when you had multi company 289 00:16:58,160 --> 00:17:01,160 development projects. So that's the other lens when 290 00:17:01,160 --> 00:17:04,440 you look at here is that actually if you've working with 291 00:17:04,440 --> 00:17:06,920 lots and lots of teams you need rigger in terms of making sure 292 00:17:06,920 --> 00:17:08,400 they all come together. It's not a mess. 293 00:17:08,960 --> 00:17:12,280 So with incentive things there might be people looking after 294 00:17:12,280 --> 00:17:15,960 the hardware, the software, the you know, the location, the 295 00:17:16,040 --> 00:17:19,920 logistics of these things. And so it it could be it can be 296 00:17:19,920 --> 00:17:22,359 quite difficult in that environment, which is why the 297 00:17:22,359 --> 00:17:26,240 again why this methodologies probably come from their 298 00:17:26,240 --> 00:17:31,200 environment and their landscape. There was the built in with the 299 00:17:31,200 --> 00:17:34,200 V model originally there was the built in verification and 300 00:17:34,200 --> 00:17:38,240 validation and that was really, really important for what I said 301 00:17:38,240 --> 00:17:44,200 before, highly regulated mission critical applications where you 302 00:17:44,240 --> 00:17:47,040 have to have that like that was that's critical. 303 00:17:47,040 --> 00:17:51,320 If there was a, if there's a bug, you know in the unit 304 00:17:51,320 --> 00:17:54,800 testing or integration testing which is the verification tests 305 00:17:55,200 --> 00:17:57,960 or there was even validation testing in terms of user 306 00:17:57,960 --> 00:18:02,640 acceptance or usability tests, if those things went wrong, 307 00:18:03,520 --> 00:18:05,840 there was a bug, it could result in harm. 308 00:18:06,120 --> 00:18:11,440 So we needed to kind of they needed to this company which is 309 00:18:11,440 --> 00:18:14,320 called the, you know the Digital Playbook and it's there's a 310 00:18:14,320 --> 00:18:16,400 company behind it. I'll let you Google that 311 00:18:16,400 --> 00:18:19,360 yourself. They were looking at these 312 00:18:19,360 --> 00:18:21,880 problems. OK, so the so the and this is 313 00:18:21,960 --> 00:18:25,840 they, They've again only applied this to the Agile Internet of 314 00:18:25,840 --> 00:18:28,840 Things framework. But for me, I think we just we 315 00:18:28,840 --> 00:18:32,600 can apply it to any project that's in this kind of landscape 316 00:18:32,600 --> 00:18:36,040 of mission critical. And I strongly believe that any 317 00:18:36,040 --> 00:18:40,360 project still goes through this general method. 318 00:18:41,320 --> 00:18:46,360 If you go to the the Agile Internet of Things playbook.org, 319 00:18:46,360 --> 00:18:49,280 you can Google it. You'll see visual pictures which 320 00:18:49,280 --> 00:18:53,440 will help outline what I'm saying here. 321 00:18:53,440 --> 00:18:56,400 So it'd probably be useful to load that up and have a look, 322 00:18:56,800 --> 00:18:59,280 even pause the podcast, look at it and then come back to it. 323 00:19:00,960 --> 00:19:04,320 But what we can so but I'm going to give the outline in words 324 00:19:04,320 --> 00:19:06,640 since you've got it in your head and then you can see the 325 00:19:06,640 --> 00:19:09,000 pictures. So the idea of the Agile 326 00:19:09,000 --> 00:19:13,040 framework and I'll quote here and it it aims to strike a good 327 00:19:13,040 --> 00:19:18,280 balance between agile software world and the least agile world 328 00:19:18,280 --> 00:19:22,560 of often safety critical, complex and large scale 329 00:19:22,560 --> 00:19:25,240 projects. OK with hardware and 330 00:19:25,240 --> 00:19:32,000 manufacturing elements. So the idea of the Agile V model 331 00:19:32,000 --> 00:19:35,040 is to combine agile development with the V model, right? 332 00:19:35,040 --> 00:19:37,600 You can do this. And so like I said, it's kind of 333 00:19:37,600 --> 00:19:40,640 a series of these that just keep going. 334 00:19:41,200 --> 00:19:43,680 But on the left hand side, you've kind of got the more 335 00:19:43,680 --> 00:19:47,480 structured system design, decomposition and the 336 00:19:47,480 --> 00:19:49,400 requirements which they don't talk about here. 337 00:19:49,400 --> 00:19:51,960 So I'm saying that BA fits into this. 338 00:19:52,720 --> 00:19:56,080 You've got the increment planning and that happens for 339 00:19:56,080 --> 00:19:59,120 your like your Sprint and then of course you're doing your 340 00:19:59,120 --> 00:20:02,000 validation, verification, continuous integration, 341 00:20:02,000 --> 00:20:04,160 continuous test and continuous delivery. 342 00:20:04,280 --> 00:20:07,960 So as you release, you're doing that again and then that's for 343 00:20:07,960 --> 00:20:10,960 one Sprint. And then you do it again and 344 00:20:10,960 --> 00:20:13,640 again for every other Sprint. So each Sprint becomes a 345 00:20:13,640 --> 00:20:17,880 complete V that includes the development and the integration 346 00:20:17,880 --> 00:20:22,840 and test. The edge off schedule introduced 347 00:20:22,840 --> 00:20:26,240 the concepts of dedicated integration sprints. 348 00:20:26,520 --> 00:20:28,800 So we've talked about this before. 349 00:20:28,800 --> 00:20:37,240 Not all sprints have to end in a functional change per SE. 350 00:20:37,840 --> 00:20:42,200 It could be Sprint to do requirements upfront, It could 351 00:20:42,200 --> 00:20:46,840 be a Sprint to do some design only tasks. 352 00:20:47,320 --> 00:20:50,920 So in this methodology, we introduced the concept of 353 00:20:50,920 --> 00:20:58,080 dedicated integration Sprint. And what we're actually doing is 354 00:20:58,080 --> 00:21:01,880 that you're benefiting both the agile way of working and also of 355 00:21:01,880 --> 00:21:04,360 course the more rigid way of working. 356 00:21:04,680 --> 00:21:08,880 So it allows us to skid do a kind of like if it's Sprint in, 357 00:21:08,880 --> 00:21:13,120 it allows us to do Sprint in plus one and so forth again and 358 00:21:13,120 --> 00:21:19,960 again and again until we have released in a true proper way 359 00:21:20,560 --> 00:21:26,320 the way we want to do it. So if you look at the BA world, 360 00:21:26,600 --> 00:21:30,480 the starting point before you even start getting into this 361 00:21:30,480 --> 00:21:33,600 kind of idea and they do talk about Sprint 0, which I don't 362 00:21:33,600 --> 00:21:36,120 particularly like, which is a preparation Sprint. 363 00:21:37,000 --> 00:21:40,400 But look, you can do this in an agile while or not. 364 00:21:40,400 --> 00:21:44,760 I would suggest as I talk about quite a lot is that there's work 365 00:21:44,760 --> 00:21:47,280 to be done before you even get into the development phase and 366 00:21:47,280 --> 00:21:50,360 that's the whole framework of the Better Business analysis 367 00:21:50,360 --> 00:21:52,920 delivery journey. So if you think there's some 368 00:21:52,920 --> 00:21:55,720 upfront strategic product planning that needs to happen. 369 00:21:56,080 --> 00:21:58,960 So that's the kind of first cut, what I would call the high level 370 00:21:58,960 --> 00:22:02,400 business requirements phase and all the work before that you 371 00:22:02,400 --> 00:22:06,000 would already start, you wouldn't start this process, OK, 372 00:22:06,000 --> 00:22:09,640 the development process until you've already got a story map 373 00:22:09,640 --> 00:22:12,200 and the definition of done complete. 374 00:22:12,520 --> 00:22:14,240 You've already got the component architecture. 375 00:22:14,240 --> 00:22:18,240 So you know basically what the architecture is going to be. 376 00:22:18,400 --> 00:22:21,080 You've got the team, you've got the environment and then once 377 00:22:21,080 --> 00:22:23,360 that's set up, you could call that Sprint zero. 378 00:22:24,240 --> 00:22:27,040 I would call it kind of the upfront analysis, strategic and 379 00:22:27,040 --> 00:22:30,000 enterprise analysis phases in the VA world. 380 00:22:30,280 --> 00:22:32,920 You do all that, and once that's set up, you then kick into these 381 00:22:32,920 --> 00:22:36,440 VS OK? And of course, if you're using 382 00:22:36,440 --> 00:22:38,920 the story maps, you've got your high level. 383 00:22:38,920 --> 00:22:40,600 I don't know in this method, don't. 384 00:22:40,960 --> 00:22:42,200 There's something I don't like about it. 385 00:22:42,600 --> 00:22:45,920 They group their story maps into functions, whereas we would 386 00:22:46,560 --> 00:22:49,480 group those into epics and then of course all the different 387 00:22:49,640 --> 00:22:53,320 posts under that. They are your user stories. 388 00:22:53,320 --> 00:22:58,400 So the story maps should outline the epics required to get the 389 00:22:58,400 --> 00:23:04,000 job done. OK, So what I again, I'm taking 390 00:23:04,040 --> 00:23:08,360 the best bits of this methodology and trying to make 391 00:23:08,360 --> 00:23:12,160 it generic to business analysis. So if you like, I'm taking the 392 00:23:12,160 --> 00:23:15,040 edge of the model developed for the incident of things and I'm 393 00:23:15,160 --> 00:23:21,320 saying that you can apply this to your work regardless of 394 00:23:22,360 --> 00:23:24,760 whether or not you're working on Internet things or any type of 395 00:23:24,760 --> 00:23:28,240 project because it's still true. And I'll talk about how the 396 00:23:28,240 --> 00:23:31,080 testing element comes in here. You've got your user story, 397 00:23:31,400 --> 00:23:34,880 you've got your acceptance criteria right, which are which 398 00:23:34,880 --> 00:23:38,600 are ideally you know the detail behind what you've got on your 399 00:23:38,600 --> 00:23:40,680 stereo board. You've got your definition of 400 00:23:40,680 --> 00:23:44,120 done from the agile world which is kind of cross use case 401 00:23:44,120 --> 00:23:47,800 criteria which need to be true. And then you've got your generic 402 00:23:48,240 --> 00:23:51,320 criteria that come off it. So it's kind of your unit test, 403 00:23:51,320 --> 00:23:54,240 your code review, your non functional requirements and that 404 00:23:54,240 --> 00:23:56,760 forms the basis for the testing world. 405 00:23:57,560 --> 00:24:02,600 So you're using not just you know if you like just the 406 00:24:02,600 --> 00:24:07,480 requirements, you're actually able to check that we are our 407 00:24:07,480 --> 00:24:09,760 Sprint goal and the definition of done at the front of our 408 00:24:09,760 --> 00:24:12,840 Sprint is done as well. So you're combining the both 409 00:24:12,920 --> 00:24:18,160 traditional V model aspects of just requirements to making sure 410 00:24:18,160 --> 00:24:22,520 that you're actual definition of done for your Sprint is is true 411 00:24:22,520 --> 00:24:23,960 and of annual definition of done. 412 00:24:24,360 --> 00:24:28,760 You would outline things like all tests need to have been 413 00:24:28,760 --> 00:24:32,120 passed, the code need to have been reviewed and that these non 414 00:24:32,120 --> 00:24:33,360 functional requirements were met. 415 00:24:35,640 --> 00:24:38,760 OK, so there's a lot that you can take in by reading that. 416 00:24:38,760 --> 00:24:42,920 There's a whole lot of visual pictures that will be helpful 417 00:24:42,920 --> 00:24:46,160 for you to kind of understand this a little bit more. 418 00:24:48,520 --> 00:24:52,560 But I want to talk about the kind of high level phases for 419 00:24:52,560 --> 00:24:56,760 the V model making the connection and then talking 420 00:24:56,760 --> 00:24:59,560 about really some real real world examples here. 421 00:24:59,560 --> 00:25:04,880 So the phases really of the Agile V model in summary are 422 00:25:04,880 --> 00:25:06,640 planning. So you're emphasizing upfront 423 00:25:06,640 --> 00:25:10,200 planning of with flexibility and adaptation. 424 00:25:10,200 --> 00:25:12,800 So that's doing the strategic planning, doing your storyboard. 425 00:25:12,800 --> 00:25:16,520 So that's kind of from product management leading into agile 426 00:25:16,520 --> 00:25:20,720 there. So that's all pretty modern day 427 00:25:20,720 --> 00:25:23,160 techniques, that's not old school, that's not little for 428 00:25:23,720 --> 00:25:27,200 then in the development phase you're using the iteration 429 00:25:27,200 --> 00:25:31,480 sprints, you've got integrated kind of V on V activities. 430 00:25:31,480 --> 00:25:34,960 So as the VS dip and go into the next V, there are integration 431 00:25:34,960 --> 00:25:38,080 activities at the end of that which are happening, which is 432 00:25:38,080 --> 00:25:40,840 more of the continuous integration and testing. 433 00:25:40,840 --> 00:25:43,760 And I'm not going to go into that, but that's the new way of 434 00:25:43,760 --> 00:25:46,640 DevOps world. That's what DevOps is all about. 435 00:25:47,840 --> 00:25:50,160 Then you've got the verification, which is 436 00:25:50,160 --> 00:25:53,800 highlighted through testing within each Sprint, within each 437 00:25:53,800 --> 00:25:57,480 Sprint, not at the end which is the old way validation. 438 00:25:57,480 --> 00:26:00,920 So you're on, I guess that's ensuring that the solution meets 439 00:26:00,920 --> 00:26:04,000 the overall goals. So you know it's not just the 440 00:26:04,000 --> 00:26:08,720 product is fit for what you have just developed in that Sprint. 441 00:26:08,720 --> 00:26:12,680 But overall the product as a whole is still meeting the user 442 00:26:12,680 --> 00:26:14,360 requirements. That's what we talked about by 443 00:26:14,360 --> 00:26:16,760 validation. The job to be done is still 444 00:26:16,760 --> 00:26:18,800 working. We haven't broken anything and 445 00:26:18,800 --> 00:26:21,880 the user is able to complete their complete journey end to 446 00:26:21,880 --> 00:26:24,800 end. We call regression testing as 447 00:26:24,800 --> 00:26:26,840 the testing team that helps with that. 448 00:26:27,400 --> 00:26:29,960 There's around deployment, so there's carefully planned and 449 00:26:29,960 --> 00:26:36,200 monitored deployment at the end of these structured these which 450 00:26:36,200 --> 00:26:40,440 is really important as we said because you deploy once ideally 451 00:26:41,120 --> 00:26:44,360 to these Internet thing devices or mission critical. 452 00:26:44,800 --> 00:26:47,720 I would say that if you are applying this to a project like 453 00:26:47,720 --> 00:26:50,920 a web project which isn't mission critical, the deployment 454 00:26:50,920 --> 00:26:53,160 side is probably you still need to do it. 455 00:26:53,160 --> 00:26:55,680 Probably it's good best practice to do it this way, but less 456 00:26:55,680 --> 00:26:58,960 important in terms of the disruption that would happen if 457 00:26:58,960 --> 00:27:00,800 you release something that had a bug in it. 458 00:27:02,000 --> 00:27:05,560 It talks about the fact that we we're incorporating in here 459 00:27:05,720 --> 00:27:08,760 feedback as well. So the importance of continuous 460 00:27:08,760 --> 00:27:11,640 improvement and adapting what we know. 461 00:27:11,960 --> 00:27:15,680 So because you're doing these, these, these these releasing 462 00:27:15,680 --> 00:27:20,120 these features, functions, requirements and testing 463 00:27:20,120 --> 00:27:23,400 straight away, you're getting feedback straight away from each 464 00:27:23,400 --> 00:27:26,080 test, right? So you can feed that back into 465 00:27:27,000 --> 00:27:31,320 the process, not just the what we get from developing a feature 466 00:27:31,320 --> 00:27:33,640 or requirement and getting feedback, We can also get 467 00:27:33,640 --> 00:27:36,680 testing, validation and feedback and incorporate that into our 468 00:27:36,680 --> 00:27:41,800 agile kind of retrospectives. And we know, OK, well, you know, 469 00:27:41,800 --> 00:27:44,160 maybe we could do a better way of testing this. 470 00:27:44,800 --> 00:27:47,920 And I'm not just right now, I'm talking about technical tests 471 00:27:47,920 --> 00:27:51,840 because I'm reading what how the V model has been applied to 472 00:27:51,840 --> 00:27:56,280 Internet of Things. But these can be, these can be 473 00:27:56,280 --> 00:27:58,800 usability tests, right? These can be customer tests. 474 00:27:59,160 --> 00:28:01,800 So it could be the fact that you're getting rapid test 475 00:28:01,800 --> 00:28:05,080 feedback from a customer directly through customer 476 00:28:05,080 --> 00:28:06,840 insights. So you've just released 477 00:28:06,840 --> 00:28:09,840 something that's mission critical or let's let's say 478 00:28:09,840 --> 00:28:13,240 we've applied this to a non mission critical environment. 479 00:28:13,240 --> 00:28:16,760 So a website you've gone live with a website, maybe it's an 480 00:28:16,760 --> 00:28:21,280 ecommerce website, you're using the Edge LV model because you 481 00:28:21,280 --> 00:28:24,680 it's got you. The reason why you're using this 482 00:28:24,800 --> 00:28:28,760 approach is because you it's you cannot afford for there to be a 483 00:28:28,760 --> 00:28:31,960 bug on this website because you may be a big brand. 484 00:28:32,240 --> 00:28:37,440 So maybe Coca-Cola or McDonald's for example, where a bug would 485 00:28:37,920 --> 00:28:40,640 damage your reputation and may cost you if you had a bug. 486 00:28:40,640 --> 00:28:44,720 In terms of the fact there's so many users who use go to 487 00:28:44,720 --> 00:28:48,640 McDonald's or or purchase Coke that if there was a bug and it 488 00:28:48,640 --> 00:28:52,320 involved, I don't know, people getting a discount, it could be 489 00:28:52,320 --> 00:28:56,520 financially crippling And just the fact that you've got you 490 00:28:56,520 --> 00:28:59,640 need this whole lot of non functional requirements because 491 00:28:59,640 --> 00:29:02,000 so many people are going to be using this app. 492 00:29:02,000 --> 00:29:04,960 So I would say that for McDonald's releasing the new 493 00:29:04,960 --> 00:29:07,840 McDonald's app, this would be a really good approach to use. 494 00:29:08,240 --> 00:29:11,920 OK, so we've got our, let's say app, let's say it's a web app, 495 00:29:11,920 --> 00:29:16,160 but it runs on your phone. So an app, and you've released 496 00:29:16,160 --> 00:29:19,800 it on your phone. It's a new McDonald's app, and 497 00:29:19,920 --> 00:29:23,520 you get feedback straight away that maybe it's through someone 498 00:29:23,520 --> 00:29:25,760 like a hot jar or something that people just can't. 499 00:29:25,920 --> 00:29:28,320 You've just released a new feature around coupons, using 500 00:29:28,320 --> 00:29:32,080 coupons, and you're finding that people just can't figure out 501 00:29:32,080 --> 00:29:34,400 what their coupon code is and add it to check out 502 00:29:34,400 --> 00:29:36,320 appropriately, right? And you're like, this is a 503 00:29:36,320 --> 00:29:40,120 disaster, starting to get social media feedback that it sucks, 504 00:29:40,120 --> 00:29:42,600 the new app release sucks. That no one can use the coupons. 505 00:29:42,600 --> 00:29:45,120 Is it a scam? And so you're getting that 506 00:29:45,120 --> 00:29:46,720 feedback. So next iteration you're like 507 00:29:46,720 --> 00:29:51,680 OK, well we released the feature like functionally everything was 508 00:29:51,680 --> 00:29:54,600 done like job to be done, tick like everything passed. 509 00:29:54,880 --> 00:29:57,720 Everything passed from a functional point of view or even 510 00:29:57,720 --> 00:30:00,520 a non functional point of view. If you look at it in a pure 511 00:30:00,520 --> 00:30:02,640 software way, coupons were added. 512 00:30:02,640 --> 00:30:05,280 I could add coupons. I didn't find it hard because I 513 00:30:05,280 --> 00:30:07,240 tested it. But if you actually incorporate 514 00:30:07,240 --> 00:30:10,560 end user testing, and I'm not talking about like the people at 515 00:30:10,560 --> 00:30:12,800 McDonald's who said, yeah, that's fine because I've used 516 00:30:12,800 --> 00:30:15,880 the app again and again, I'm talking about we've now had you 517 00:30:15,880 --> 00:30:19,320 know, the 1st 1000 users or a test group hopefully released 518 00:30:19,320 --> 00:30:23,880 this just to a test group of all app users, which is how things 519 00:30:23,880 --> 00:30:27,120 happen these days generally. So you have like AB testing. 520 00:30:27,120 --> 00:30:30,760 So most people are using the old version of the app, but you know 521 00:30:30,760 --> 00:30:34,840 maybe the people in New Zealand are using the newer version of 522 00:30:34,840 --> 00:30:37,640 the app or Auckland, you can do that kind of stuff. 523 00:30:38,840 --> 00:30:40,840 So they're using it. So our test group is using it 524 00:30:40,840 --> 00:30:43,000 and then they can't use the coupon feature, it's just 525 00:30:43,000 --> 00:30:45,400 ineffective and they're starting to get some social media 526 00:30:45,400 --> 00:30:47,480 feedback. That's called customer insights. 527 00:30:47,680 --> 00:30:52,520 We can take that in and go hey the functionally this tip we we 528 00:30:52,520 --> 00:30:55,480 didn't have a test case about, we didn't have the customer 529 00:30:55,480 --> 00:31:00,320 insights because we didn't release to the to our customers. 530 00:31:00,320 --> 00:31:01,480 So there was no way we knew this. 531 00:31:01,720 --> 00:31:03,120 We've just released that feature. 532 00:31:03,360 --> 00:31:07,040 We've now had feedback far out. We need to make some changes to 533 00:31:07,040 --> 00:31:10,200 the design to make it easier to use these this coupon feature. 534 00:31:10,880 --> 00:31:12,640 OK, so that's perfect, right. That's perfect. 535 00:31:12,640 --> 00:31:14,960 We've it's it's kind of a critical lab. 536 00:31:14,960 --> 00:31:17,200 People can't use it. It's causing us reputational 537 00:31:17,200 --> 00:31:19,040 damage. It gets added to the next Sprint 538 00:31:19,040 --> 00:31:21,960 as a high priority item and we work along the way. 539 00:31:22,480 --> 00:31:25,280 And now then, maybe in our testing, testing, feedback, 540 00:31:25,280 --> 00:31:28,120 continuous improvement is OK. We're going to release this to a 541 00:31:28,120 --> 00:31:32,920 much smaller community to get feedback before releasing it to 542 00:31:32,920 --> 00:31:35,640 a larger group and before releasing it ideally to 543 00:31:35,640 --> 00:31:37,080 everyone, which could have happened. 544 00:31:38,040 --> 00:31:41,240 So do you see how this method, just having a bit of rigor in 545 00:31:41,240 --> 00:31:44,640 there can actually help? So you're again getting testing 546 00:31:44,640 --> 00:31:48,320 involved earlier and those requirements are tested, but 547 00:31:48,360 --> 00:31:53,200 we're not just talking about testing for technology changes, 548 00:31:53,200 --> 00:31:55,680 we're also checking for customer insights. 549 00:31:57,840 --> 00:32:02,160 Now I guess some of the comparisons that we talked about 550 00:32:02,160 --> 00:32:07,000 before is that you know you are getting this kind of certainty 551 00:32:07,520 --> 00:32:11,200 planning, validation structure and predictability that you got 552 00:32:11,200 --> 00:32:17,480 from the traditional V model and I guess you're addressing some 553 00:32:17,480 --> 00:32:19,840 regulation, regulatory compliance needs. 554 00:32:19,840 --> 00:32:23,320 So sometimes it's it's you actually have to test in this 555 00:32:23,320 --> 00:32:25,040 way. So the signing off the test 556 00:32:25,040 --> 00:32:29,280 before you go to the next V, if you like, might actually require 557 00:32:29,280 --> 00:32:33,720 some governance and important governance, independent testing, 558 00:32:33,720 --> 00:32:36,560 all the rest of it. So this works in that manner as 559 00:32:36,560 --> 00:32:40,760 well, allows for that, but it enables this. 560 00:32:41,440 --> 00:32:44,680 So it allows that to cover that complexity and the compliance 561 00:32:44,680 --> 00:32:47,760 needs, but allows us to still work in an agile team and 562 00:32:47,760 --> 00:32:52,960 environment. Now if you go to the kind of 563 00:32:53,200 --> 00:32:56,480 Agile Incident of things project and framework, you'll see some 564 00:32:56,480 --> 00:33:01,800 examples on which they have applied this to instant things. 565 00:33:02,600 --> 00:33:07,680 Examples which will help you understand what what I mean by 566 00:33:07,720 --> 00:33:10,760 this. But I do think that I want you 567 00:33:10,760 --> 00:33:13,400 to take this at a very high level. 568 00:33:13,400 --> 00:33:17,200 I want you to not get too obsessed with the method, that 569 00:33:17,200 --> 00:33:20,320 they have the detail of the method and take it away as more 570 00:33:20,320 --> 00:33:24,840 of a framework you hopefully you you have you. 571 00:33:25,000 --> 00:33:29,000 By listening to me today, you know that there is a good way of 572 00:33:29,840 --> 00:33:35,920 incorporating structure into a project delivery framework that 573 00:33:35,920 --> 00:33:39,720 allows for agile to do things which you know are adaptable, 574 00:33:39,720 --> 00:33:45,000 responsive and change. But you're able to integrate the 575 00:33:45,000 --> 00:33:48,320 V model which allows us to catch early issues in the development 576 00:33:48,320 --> 00:33:52,040 process and allows us to get feedback in a really structured 577 00:33:52,040 --> 00:33:54,360 way. And so therefore instead of just 578 00:33:54,360 --> 00:33:57,640 going fully waterfall which will be the alternative and do things 579 00:33:57,640 --> 00:34:01,040 very structurally and signed off, you can actually do both 580 00:34:01,920 --> 00:34:05,440 using the V model and allow the Agile V model and allows us to 581 00:34:05,440 --> 00:34:09,760 incorporate agile and the V model which will allow us to you 582 00:34:09,760 --> 00:34:17,040 know really have a collaborative way of detecting early defects, 583 00:34:17,040 --> 00:34:19,480 customer satisfaction. You know, increasing 584 00:34:19,480 --> 00:34:25,600 collaboration, still allowing us to have adaptability and I guess 585 00:34:26,120 --> 00:34:30,520 release in increments, but also allow us to have some structure 586 00:34:31,400 --> 00:34:36,679 which allows us to make sure that projects are released right 587 00:34:36,679 --> 00:34:40,920 the first time and especially in mission critical situations like 588 00:34:40,920 --> 00:34:43,520 in the world of Internets of Things. 589 00:34:44,360 --> 00:34:45,840 I hope you have learned something today. 590 00:34:46,719 --> 00:34:49,159 If you don't know the V model, your action is to look up the V 591 00:34:49,159 --> 00:34:51,600 model so you understand what I'm talking about and you understand 592 00:34:51,600 --> 00:34:55,280 how requirements are used. It's true it it exists in some 593 00:34:55,280 --> 00:34:59,240 form and you look up the Agile V model and understand both how 594 00:34:59,240 --> 00:35:02,600 Agile and the V model can be used in those environments I 595 00:35:02,600 --> 00:35:04,080 talked about. Cool. 596 00:35:04,160 --> 00:35:04,960 I'll see you next week.