1 00:00:00,400 --> 00:00:04,400 The Better Business Analysis Institute presence, the Better 2 00:00:04,400 --> 00:00:07,760 Business Analysis podcast with Kenjan Walsh. 3 00:00:12,400 --> 00:00:14,520 Hi, everybody. It's Benjamin Walsh from the 4 00:00:14,520 --> 00:00:16,560 Better Business Analysis Institute. 5 00:00:16,760 --> 00:00:19,880 And this is the Better Business Analysis Podcast. 6 00:00:20,000 --> 00:00:22,880 Thanks for joining. This week we're going to talk 7 00:00:22,880 --> 00:00:25,760 about Agile. We talk about Agile quite a bit, 8 00:00:26,120 --> 00:00:31,280 but specifically the topic I want to talk to you about is the 9 00:00:31,280 --> 00:00:33,960 pitfalls and optimizing workflow. 10 00:00:34,600 --> 00:00:39,120 OK, so I've called this topic in this episode Agile Done right, 11 00:00:39,440 --> 00:00:42,600 Avoiding common Pitfalls and Optimizing Workflow. 12 00:00:43,000 --> 00:00:45,440 When I save the workflow, I'm talking about the processes 13 00:00:45,680 --> 00:00:49,560 within the agile environment and what you need to have set up in 14 00:00:49,560 --> 00:00:53,760 order to run a tight ship. And I am really talking about 15 00:00:53,760 --> 00:00:57,360 agile delivery here. So the delivery side, not other 16 00:00:57,360 --> 00:01:00,480 flavors of agile for transformation, you know 17 00:01:00,480 --> 00:01:04,800 organizational transformation or or culture shift, this is really 18 00:01:04,800 --> 00:01:07,280 around delivery and if you've got a development team and 19 00:01:07,280 --> 00:01:09,880 you're in that environment, then you could think of your agile 20 00:01:10,360 --> 00:01:13,840 development in this context. So we're going to go straight 21 00:01:13,840 --> 00:01:15,600 into it. We're going to start with 22 00:01:15,960 --> 00:01:18,840 avoiding common pitfalls. And so I'm going to talk about 23 00:01:20,120 --> 00:01:25,560 why they're pitfalls and some acknowledgments that you need to 24 00:01:25,960 --> 00:01:29,800 be very clear about so you don't fall into these holes. 25 00:01:30,320 --> 00:01:31,840 I don't have all the answers here. 26 00:01:32,120 --> 00:01:35,560 I'm sure there are good techniques for digging your way 27 00:01:35,560 --> 00:01:37,760 out of those pitfalls. If you fool them, just avoid 28 00:01:37,760 --> 00:01:40,320 them to start off with. And I'm sure you have some 29 00:01:40,320 --> 00:01:42,600 feedback. So if you've got feedback, tag 30 00:01:42,600 --> 00:01:46,880 me in, tag the institute in, and we can talk about your feedback 31 00:01:46,880 --> 00:01:50,920 around pitfalls that you've found when using Agile. 32 00:01:51,920 --> 00:01:56,480 So I've got 5 here, 5 pitfalls. I didn't want to boil the ocean 33 00:01:56,480 --> 00:02:01,560 and come up with 20s. So 5 common pitfalls that I 34 00:02:01,560 --> 00:02:03,800 think you need to avoid in Agile. 35 00:02:04,000 --> 00:02:05,200 We're going to start with number one. 36 00:02:05,200 --> 00:02:10,120 Number one is so important and it is. 37 00:02:10,199 --> 00:02:14,600 Do not treat Agile as a silver bullet, OK? 38 00:02:14,600 --> 00:02:17,520 The pitfall is treating it as a silver bullet. 39 00:02:18,080 --> 00:02:21,040 Agile is a wonderful framework, powerful. 40 00:02:21,800 --> 00:02:25,920 You know, if you think of Scrum, it's so good in terms of an 41 00:02:25,920 --> 00:02:28,400 evolution of how we were doing things beforehand. 42 00:02:29,640 --> 00:02:32,840 You know, people can get overwhelmed with it from a 43 00:02:32,840 --> 00:02:39,440 cultural point of view, from a, you know, anti SDLC, waterfall 44 00:02:39,480 --> 00:02:43,000 approach. But Agile didn't fix all the pro 45 00:02:43,000 --> 00:02:46,360 program or project delivery challenges we have. 46 00:02:46,480 --> 00:02:48,240 It wasn't a magic fact. Fact. 47 00:02:49,280 --> 00:02:54,840 OK, it it doesn't come into the organization and fix everything, 48 00:02:55,680 --> 00:02:58,560 so don't treat it like it is. Or, you know, I've got a 49 00:02:58,560 --> 00:03:00,240 solution for that. Let's go agile. 50 00:03:00,560 --> 00:03:03,480 No, that is not what. What problem are you trying to 51 00:03:03,480 --> 00:03:05,760 solve now? There was a common problem with 52 00:03:06,160 --> 00:03:09,000 the fact that requirements changed throughout the life 53 00:03:09,000 --> 00:03:11,000 cycle of our project or a piece of work. 54 00:03:11,480 --> 00:03:15,000 There was common problems around the fact that we weren't 55 00:03:15,280 --> 00:03:20,240 engaging stakeholders enough, We weren't demoing enough, We 56 00:03:20,240 --> 00:03:23,480 didn't, you know, work on the most valuable stuff up front. 57 00:03:23,880 --> 00:03:27,000 We didn't time box how we did things. 58 00:03:27,000 --> 00:03:30,640 There were lots of good reasons for Agile, and that was the 59 00:03:30,640 --> 00:03:33,520 reason we implemented it. But it isn't going to solve 60 00:03:33,840 --> 00:03:39,480 things like project risk necessarily as much as other 61 00:03:39,480 --> 00:03:42,000 methods. It isn't necessarily going to 62 00:03:43,480 --> 00:03:46,440 outline exactly how to write a user story with enough 63 00:03:46,440 --> 00:03:49,920 information for your designers and your developers. 64 00:03:49,960 --> 00:03:54,640 It isn't going to define the role of the BA, OK? 65 00:03:54,640 --> 00:03:57,640 So it's not going to solve all those challenges and especially 66 00:03:57,640 --> 00:04:03,280 if you're adopting very complex, maybe you've got a complex 67 00:04:03,280 --> 00:04:06,400 organization. So I'm not saying complex in a 68 00:04:06,600 --> 00:04:10,600 derogatory term, but if you're using for example Scaled Agile 69 00:04:11,040 --> 00:04:14,880 for Enterprises safe framework, which is the type of agile 70 00:04:14,880 --> 00:04:18,440 methodology, you know that that is multi layered. 71 00:04:18,440 --> 00:04:19,959 It's got all sorts of things going on. 72 00:04:19,959 --> 00:04:23,200 It talks about a whole lot of different methodologies now, 73 00:04:23,800 --> 00:04:27,360 again because it's even bigger and more complete or robust if 74 00:04:27,360 --> 00:04:29,560 you like. For an organization, people are 75 00:04:29,560 --> 00:04:31,720 going to also go well. This is even better because it's 76 00:04:31,720 --> 00:04:35,000 got all the processes and procedures we need and the same 77 00:04:35,000 --> 00:04:38,520 way Prince Two didn't solve all the delivery problems with the 78 00:04:38,520 --> 00:04:43,800 project. Agile or Safe or flavor of Agile 79 00:04:43,800 --> 00:04:45,800 framework is not going to solve all your problems. 80 00:04:45,800 --> 00:04:49,520 It is not the silver bullet. So don't treat it as such. 81 00:04:49,560 --> 00:04:52,640 Just treat it as the way in which software which is 82 00:04:52,640 --> 00:04:56,000 primarily, is delivered through a delivery team. 83 00:04:58,320 --> 00:05:02,000 The other thing that happens. So flipping back to looking at 84 00:05:02,000 --> 00:05:04,600 Sprint. So the if you don't know what a 85 00:05:04,600 --> 00:05:07,840 Sprint is then they are the you know time box periods where 86 00:05:07,840 --> 00:05:09,920 you're pulling things off the backlog which is all the 87 00:05:09,920 --> 00:05:13,480 requirements and you're pulling in what we should do next in a 88 00:05:13,480 --> 00:05:17,120 time box period of time which has a Sprint, has a goal and a 89 00:05:17,120 --> 00:05:24,200 definition. There is a major pitfall here 90 00:05:24,680 --> 00:05:28,040 and it's called waterfalling in Sprint, OK. 91 00:05:28,040 --> 00:05:31,120 And it's a little bit of a nod or a bit of A to say that you 92 00:05:31,120 --> 00:05:36,280 know we've we're our waterfall mindset of doing everything to 93 00:05:36,360 --> 00:05:40,160 the you know from one our requirements one to 100 all on 94 00:05:40,160 --> 00:05:41,800 go and kind of sneaky in waterfall. 95 00:05:43,200 --> 00:05:48,200 There what happens is that people are trying to cram 96 00:05:49,840 --> 00:05:53,240 traditional kind of sequential fight fight phases into short 97 00:05:53,240 --> 00:05:57,000 sprints. So they're saying well and for 98 00:05:57,000 --> 00:06:00,800 example for Sprint one doesn't matter if it's two weeks we'll 99 00:06:00,800 --> 00:06:04,520 go over 2 weeks it needs to be 4 weeks and we need to do at least 100 00:06:04,520 --> 00:06:07,360 the infrastructure set up in the first Sprint. 101 00:06:07,760 --> 00:06:10,240 That is actually a wonderful project. 102 00:06:11,240 --> 00:06:15,120 It is, and I'm I have nothing against for projects by the way. 103 00:06:15,480 --> 00:06:18,400 But if you're deciding you're going to do Agile, you don't do 104 00:06:18,400 --> 00:06:20,360 that. So what you do is you do a slice 105 00:06:20,360 --> 00:06:23,960 of the solution from beginning to end for the job to be done 106 00:06:24,520 --> 00:06:29,120 regardless of the the layer of infrastructure you need. 107 00:06:29,400 --> 00:06:34,200 And you try and do those the most vital steps, the most 108 00:06:34,200 --> 00:06:36,440 valuable steps at that point in time in the Sprint. 109 00:06:36,720 --> 00:06:40,600 So another way of saying that is you're not doing HDLC where 110 00:06:40,600 --> 00:06:42,360 you're going. OK, we'll do the infrastructure 111 00:06:42,360 --> 00:06:44,880 1st and we'll do the design. You're not carving it that way, 112 00:06:45,120 --> 00:06:47,200 you're carving it on customer value. 113 00:06:47,800 --> 00:06:51,680 So if you are doing a Sprint 0, setting up infrastructure 1st 114 00:06:51,680 --> 00:06:53,280 and all the rest of it, don't kid yourself. 115 00:06:53,280 --> 00:06:55,720 You're not doing agile and there's no reason. 116 00:06:55,720 --> 00:06:57,760 Sorry. Just be clear here, it's not an 117 00:06:57,760 --> 00:07:02,640 and or there's no reason why you couldn't do an infrastructure 118 00:07:02,640 --> 00:07:06,120 project if that's necessary for the product you're doing as a 119 00:07:06,480 --> 00:07:09,000 for project. Separate to this and then do an 120 00:07:09,000 --> 00:07:11,160 agile project to use that infrastructure to make product. 121 00:07:11,720 --> 00:07:15,080 There's no there's I'm not saying you know you have to do 122 00:07:15,080 --> 00:07:18,480 infrastructure in an agile way. If you know that this box needs 123 00:07:18,480 --> 00:07:22,280 to be done, don't try and cram it into an agile methodology. 124 00:07:22,400 --> 00:07:26,320 Just get that done and then you know in sequence or for in 125 00:07:26,320 --> 00:07:31,040 parallel or after the fact. Start using delivery agile for 126 00:07:31,040 --> 00:07:34,120 deliver, delivering customer facing products. 127 00:07:34,160 --> 00:07:37,280 You know on top of the infrastructure you need to, you 128 00:07:37,280 --> 00:07:41,680 know, emphasize the idea that you're doing iterations here 129 00:07:41,680 --> 00:07:46,520 you're doing, you're not trying to implement a full solution 130 00:07:47,040 --> 00:07:51,080 when you do agile. So let's talk about more of a 131 00:07:51,080 --> 00:07:54,600 product, not an infrastructure mindset and say we're building a 132 00:07:54,600 --> 00:07:57,360 product, a web app. Your job isn't to go, OK, well, 133 00:07:57,360 --> 00:08:00,160 I need to have a login Screener, you know, a front end, the 134 00:08:00,160 --> 00:08:03,280 database done and you know a landing page before we actually 135 00:08:03,280 --> 00:08:05,120 do the next pieces of functionality. 136 00:08:05,120 --> 00:08:06,680 And I need to do that all straight away. 137 00:08:07,120 --> 00:08:08,800 It could be what that stuff's not important. 138 00:08:08,800 --> 00:08:10,600 It's not important to do login straight away. 139 00:08:10,600 --> 00:08:14,720 It's not important to necessarily have all those 140 00:08:14,720 --> 00:08:18,000 account features or even have a database to be honest. 141 00:08:18,320 --> 00:08:22,320 Sprint Zero could simply be doing some designs for Sprint 142 00:08:22,320 --> 00:08:26,280 one, so there is no Sprint 0. Just to be clear, Sprint One is 143 00:08:26,280 --> 00:08:30,800 showing designs to customers. It's simply a business facing 144 00:08:30,800 --> 00:08:32,919 Sprint. So again, when we do our agile 145 00:08:32,919 --> 00:08:38,880 delivery, in the same way that we could split out prerequisites 146 00:08:38,880 --> 00:08:42,039 in a different type of project, set up methodology like 147 00:08:42,039 --> 00:08:46,720 waterfall, we could equally include inside an agile project 148 00:08:46,960 --> 00:08:50,200 the first Sprint or first couple of sprints may not be technology 149 00:08:50,200 --> 00:08:53,760 driven, they could simply be sprints around focusing on 150 00:08:53,760 --> 00:08:57,360 customer feedback and design. In case you might, your delivery 151 00:08:57,360 --> 00:09:00,800 sprints might only happen at Sprint six or something. 152 00:09:01,800 --> 00:09:05,680 OK so that happens commonly and sometimes those sprints are done 153 00:09:05,680 --> 00:09:09,880 through rapid prototyping. They're done in big room 154 00:09:09,880 --> 00:09:13,520 planning and and that for me, I actually support that it's it 155 00:09:13,520 --> 00:09:16,240 gets developers involved early and tested but it's actually got 156 00:09:16,240 --> 00:09:20,440 nothing to do with producing any code it's all about producing 157 00:09:20,440 --> 00:09:22,320 designs and feedback from customers. 158 00:09:22,320 --> 00:09:25,760 So definitely keen on that but again don't try and do all your 159 00:09:25,760 --> 00:09:30,440 analysis in Sprint one, that's not the BA phase and and be 160 00:09:30,440 --> 00:09:32,880 honest with yourself if you need to do so. 161 00:09:33,120 --> 00:09:34,680 Sorry. Here's here's a here's a bit of 162 00:09:34,680 --> 00:09:36,920 a giveaway and we talk about this at the institute. 163 00:09:37,600 --> 00:09:39,960 I have a really strong belief that enterprise analysis, 164 00:09:39,960 --> 00:09:45,440 strategic analysis in detailed sorry high level requirements 165 00:09:45,440 --> 00:09:48,920 capture should all be done before should be done in a in a 166 00:09:48,920 --> 00:09:51,880 very you know project. You could say waterfall manner 167 00:09:51,880 --> 00:09:56,280 but a a series manner manner until you get funding to then 168 00:09:56,320 --> 00:10:00,480 get into delivery and deliver some stuff be that mock ups or 169 00:10:00,480 --> 00:10:04,200 code and then start using agile proper at that point. 170 00:10:04,200 --> 00:10:07,920 So I have a that's my belief. You might work in a different 171 00:10:07,920 --> 00:10:10,760 way. However, I would say that 172 00:10:11,120 --> 00:10:13,680 regardless of the fact know which methodology you're using. 173 00:10:15,240 --> 00:10:21,040 The other one of course, which was one of the purposes of 174 00:10:21,040 --> 00:10:26,160 moving to a job but really hasn't been at all helped 175 00:10:26,640 --> 00:10:30,880 through using these methodologies is scope creep. 176 00:10:31,520 --> 00:10:34,440 So this can happen for lots of reasons. 177 00:10:35,760 --> 00:10:41,480 One of them is the fact that the backlog just keeps getting added 178 00:10:41,480 --> 00:10:47,040 to it's it becomes the project becomes a request manage, not a 179 00:10:47,040 --> 00:10:49,600 request management of requirements that are on the 180 00:10:49,600 --> 00:10:51,280 fly. OK? 181 00:10:51,600 --> 00:10:54,400 And again that's why the method of doing some high level 182 00:10:54,400 --> 00:10:56,480 business requirements and objectives basically Epics 183 00:10:56,480 --> 00:11:00,360 upfront reduces that completely It it actually reduces the scope 184 00:11:00,360 --> 00:11:02,440 problem that I'm talking about right now. 185 00:11:03,600 --> 00:11:06,560 So you have that first layer of user stories all ready to find 186 00:11:06,560 --> 00:11:09,440 before you start that produces this problem. 187 00:11:09,880 --> 00:11:12,400 But if you literally say we're going to backlog, we add it to 188 00:11:12,400 --> 00:11:15,880 the backlog, which is a lot of agile projects happen, then you 189 00:11:15,880 --> 00:11:18,000 actually have an uncontrolled door there. 190 00:11:18,000 --> 00:11:22,640 So you have effectively uncontrolled scope and that will 191 00:11:22,640 --> 00:11:25,440 derail your agile project. I see it all the time. 192 00:11:26,920 --> 00:11:32,200 It's to do with having you know an inbox that continually grows. 193 00:11:32,800 --> 00:11:35,760 It has a problem with the value items that have been put in the 194 00:11:35,760 --> 00:11:39,760 Sprint up until you run out of money not being enough to 195 00:11:39,760 --> 00:11:41,760 deliver an end product that anyone wants. 196 00:11:42,840 --> 00:11:46,000 It's it's the problem with not really architecting the solution 197 00:11:46,000 --> 00:11:51,600 upfront in some shape or form. So to manage scope creep that is 198 00:11:51,600 --> 00:11:54,800 really a project manager's job or product manager. 199 00:11:54,800 --> 00:11:57,280 If you don't have a project manager working on it, they 200 00:11:57,280 --> 00:12:00,880 should be looking at this. You need to manage strategies 201 00:12:00,880 --> 00:12:03,800 for managing scope. There are things like backlog 202 00:12:03,800 --> 00:12:05,880 prioritization. There is no reason why you can't 203 00:12:05,880 --> 00:12:08,880 say, add things to the backlog with an understanding that they 204 00:12:08,880 --> 00:12:13,800 won't be done probably or they won't be prioritized throughout 205 00:12:13,960 --> 00:12:17,080 this process. Sprint planning can reduce 206 00:12:17,080 --> 00:12:19,000 those. But again, I don't think those 207 00:12:19,000 --> 00:12:25,160 two agile method or built in controls for agile completely 208 00:12:25,160 --> 00:12:29,360 solve the issue. I think it's being using user 209 00:12:29,360 --> 00:12:32,440 storyboards really helps here. Being clear about the jobs to be 210 00:12:32,440 --> 00:12:37,360 done helps here really understanding that not only do 211 00:12:37,360 --> 00:12:40,640 you need to deliver the most valuable stuff, not not chosen 212 00:12:40,640 --> 00:12:44,280 by the product owner, by chosen by your customer and then 213 00:12:44,280 --> 00:12:46,240 facilitated through a conversation with your product 214 00:12:46,240 --> 00:12:49,280 owner, but also the fact that you've got all the critical 215 00:12:49,280 --> 00:12:52,960 items that are needed to deliver at the end of your project. 216 00:12:53,520 --> 00:12:56,200 OK. And I want to just clarify that 217 00:12:56,200 --> 00:12:59,680 again or say that in a different way at the end of the Sprint. 218 00:12:59,840 --> 00:13:01,520 You're not. You're supposed to have a 219 00:13:01,520 --> 00:13:04,520 working prototype of a product that you can demo. 220 00:13:04,880 --> 00:13:08,080 OK, it could be a piece of paper, OK, it doesn't have to be 221 00:13:08,080 --> 00:13:11,320 a piece of software. And you should be able to demo 222 00:13:11,320 --> 00:13:14,120 the progress that you've made. That's the whole point of using 223 00:13:14,120 --> 00:13:17,480 Scrum. Now, that doesn't mean it's 224 00:13:17,520 --> 00:13:21,560 really full release to the, you know, to the public at this 225 00:13:21,560 --> 00:13:23,760 point. And just so you can demo to the 226 00:13:23,760 --> 00:13:26,640 stakeholders to show them it doesn't mean you're releasing 227 00:13:26,920 --> 00:13:31,560 necessarily on the final infrastructure or environment to 228 00:13:31,560 --> 00:13:33,160 go live. That might be another Sprint. 229 00:13:33,560 --> 00:13:37,840 So if that is the case, then you need to be careful that you've 230 00:13:37,840 --> 00:13:41,880 built in enough time to get it to, you know, public release 231 00:13:41,880 --> 00:13:44,920 ready if you're doing a public app and if you keep doing the 232 00:13:44,920 --> 00:13:46,840 functions, you're never going to get the chance. 233 00:13:47,320 --> 00:13:49,640 I'm working on a piece of work at the moment which is a startup 234 00:13:49,640 --> 00:13:53,760 company working on a mobile web app for businesses and 235 00:13:53,760 --> 00:13:57,000 consumers. And we're working on still 236 00:13:57,000 --> 00:14:00,560 working on functionality, base functionality before it gets 237 00:14:00,560 --> 00:14:04,640 demoed to some businesses. And you know it still needs some 238 00:14:04,640 --> 00:14:06,600 work and it's not polished at all. 239 00:14:06,600 --> 00:14:09,760 And you know, part of me wants to make it really sexy before we 240 00:14:09,760 --> 00:14:12,520 show anyone, which is the opposite of what you should do 241 00:14:12,520 --> 00:14:14,560 when you're building a new product that's new. 242 00:14:15,120 --> 00:14:19,760 However, what I'm well aware of is there's a whole bunch of work 243 00:14:19,760 --> 00:14:23,440 if we wanted to move a mobile app and a web app to scalable 244 00:14:24,080 --> 00:14:27,920 architecture once we've even gone through the agile 245 00:14:27,920 --> 00:14:30,800 deliveries side right? There will be a number of 246 00:14:30,800 --> 00:14:35,080 sprints so I can't just estimate the development time or the 247 00:14:35,080 --> 00:14:38,200 number of sprints will cap it. I know there needs to be this 248 00:14:38,680 --> 00:14:41,840 pretty water fully process of releasing apps to the App Store. 249 00:14:42,160 --> 00:14:45,640 You know, putting a website on scalable AWS architecture or 250 00:14:45,640 --> 00:14:48,400 whatever the architecture is. You know doing testing, doing 251 00:14:48,400 --> 00:14:52,120 pin testing, all the security side that is an additional piece 252 00:14:52,120 --> 00:14:53,560 of work. It's pretty common, it's pretty 253 00:14:53,560 --> 00:14:55,640 standardized, really needs to do it agile. 254 00:14:56,400 --> 00:14:59,880 I just need we just need to do that as part of the team and 255 00:14:59,880 --> 00:15:03,000 that's going to be over and above the development cycle, OK, 256 00:15:03,040 --> 00:15:05,760 before release. So just think about that. 257 00:15:05,760 --> 00:15:09,280 So in that case that isn't scope creep, that is stuff that you 258 00:15:09,280 --> 00:15:11,760 should have in scope and be really clear that you've got 259 00:15:11,760 --> 00:15:17,640 even less room for the backlog items, that the product 260 00:15:18,080 --> 00:15:24,240 functional backlog items. The next one that happens even 261 00:15:24,240 --> 00:15:27,080 though we the whole purpose of Agile is to try to stop the 262 00:15:27,080 --> 00:15:30,000 surrounding is communication silos. 263 00:15:30,000 --> 00:15:33,320 So that's still not broken down. So we used to have this big wall 264 00:15:33,320 --> 00:15:37,560 between the requirements phase and the delivery phase that was 265 00:15:37,560 --> 00:15:41,080 a big wall that almost like the Berlin Wall. 266 00:15:41,080 --> 00:15:44,640 We've broken that down and we can now communicate you know 267 00:15:44,640 --> 00:15:49,320 between West and East Germany. But we haven't solved other 268 00:15:49,320 --> 00:15:52,480 communication issues which might be which might just happen, what 269 00:15:52,480 --> 00:15:55,640 might happen when working on a project and then more individual 270 00:15:55,640 --> 00:15:58,760 silo. So you have communication 271 00:15:58,760 --> 00:16:01,360 breakdowns between barriers between teams, stakeholders, 272 00:16:01,360 --> 00:16:03,600 clients, product owners and clients. 273 00:16:04,200 --> 00:16:06,440 If you've got a project manager, you've got project manager 274 00:16:06,440 --> 00:16:09,800 versus product manager issues if you've got both of those. 275 00:16:10,600 --> 00:16:15,360 And so you really need to be more ultra transparent. 276 00:16:15,960 --> 00:16:19,560 And no, because you haven't run, because everything is fluid and 277 00:16:19,560 --> 00:16:21,960 agile. You need to be ultra transparent 278 00:16:21,960 --> 00:16:26,160 and ultra collaborative. You almost need to document your 279 00:16:26,240 --> 00:16:30,240 communication more than you would in a waterfall situation. 280 00:16:30,240 --> 00:16:31,600 And you need to communicate that you don't. 281 00:16:31,600 --> 00:16:34,480 When I say document more I don't mean 100 page spec. 282 00:16:34,760 --> 00:16:37,520 I mean using visual communication tools like 283 00:16:37,520 --> 00:16:40,080 whiteboarding online whiteboarding tools and post its 284 00:16:40,120 --> 00:16:43,360 and a room and you need to have all the stuff that people can 285 00:16:43,360 --> 00:16:46,000 come and look at down to ideas off because you're you're 286 00:16:46,000 --> 00:16:49,560 running quickly and so you need to be better at occasion with 287 00:16:49,560 --> 00:16:51,520 their job. The other thing of course is 288 00:16:51,520 --> 00:16:53,880 that the whole point is that you should have this development 289 00:16:53,880 --> 00:16:56,760 team that's working together and should have multifunctional 290 00:16:56,760 --> 00:16:59,280 teams and all the rest of it and one that never happens. 291 00:16:59,280 --> 00:17:02,800 People are on other projects. So when you you know, you've got 292 00:17:02,800 --> 00:17:05,560 to think that if you're product owners across three products, 293 00:17:05,560 --> 00:17:08,839 for example, you know they might not be on when you're doing the, 294 00:17:09,280 --> 00:17:11,960 they might not be thinking about your product every every 5 295 00:17:11,960 --> 00:17:13,760 minutes. So that's hard. 296 00:17:13,760 --> 00:17:16,119 And then also you might be bringing in an architect who now 297 00:17:16,119 --> 00:17:19,400 needs to, you know get up to speed about where you're at or 298 00:17:19,400 --> 00:17:22,920 ABA or a tester. So you generally find the core 299 00:17:22,920 --> 00:17:25,240 team is generally A scrum master and a couple of developers, 300 00:17:25,240 --> 00:17:28,119 maybe a tester and maybe ABA if you're lucky. 301 00:17:28,359 --> 00:17:32,480 Now that that means that all those other people are not up to 302 00:17:32,480 --> 00:17:34,560 speed with you. You might, you know he might be 303 00:17:34,880 --> 00:17:38,000 working really, really well. And then I've got two things to 304 00:17:38,000 --> 00:17:42,040 say about that. One is I didn't like this when I 305 00:17:42,040 --> 00:17:46,520 first saw it, but I now believe my current belief this week is 306 00:17:46,520 --> 00:17:49,320 that if you have a highly functioned delivery team like, 307 00:17:49,320 --> 00:17:52,680 you know, developers, testers, maybe you've got, maybe you 308 00:17:52,680 --> 00:17:55,720 could be a a scrum master and they're like cranking it. 309 00:17:56,440 --> 00:18:03,680 Don't break that model just so they're more collaborative or so 310 00:18:03,680 --> 00:18:06,000 you can insert APM and and rigor into it. 311 00:18:06,280 --> 00:18:10,120 Let them run fast and just understand and agree with them. 312 00:18:10,120 --> 00:18:11,960 You may decide on the inputs and outputs. 313 00:18:12,280 --> 00:18:14,520 They may decide they want requirements in this format. 314 00:18:14,640 --> 00:18:17,000 This is the audience. They work really well this way. 315 00:18:17,280 --> 00:18:19,680 Don't wreck their great working way. 316 00:18:19,680 --> 00:18:23,320 You may even be jealous of it by just getting involved in their 317 00:18:23,480 --> 00:18:26,080 in their jazz right and involved in their stuff. 318 00:18:26,600 --> 00:18:28,800 Feed it, feed the machine. They should be a highly 319 00:18:28,800 --> 00:18:31,160 functioning machine. And if you've got great inputs 320 00:18:31,160 --> 00:18:33,520 and outputs in their demoing, let them run that way. 321 00:18:33,520 --> 00:18:37,080 You don't need to wrap around unnecessary meetings to do that 322 00:18:37,400 --> 00:18:40,240 and that's where I've seen Agile being the most effective as in a 323 00:18:40,280 --> 00:18:42,800 development in that kind of environment. 324 00:18:44,000 --> 00:18:46,920 And if you're in a startup company and the largest startup 325 00:18:46,920 --> 00:18:49,560 company then you may and you're only working on one product, 326 00:18:49,560 --> 00:18:51,920 then of course the product owners should be involved in in 327 00:18:51,920 --> 00:18:55,240 everything as well. That isn't the case for most 328 00:18:55,240 --> 00:18:59,440 organizations we all work at. So we've we've just covered off 329 00:18:59,440 --> 00:19:01,040 treating Agile as a silver bullet. 330 00:19:01,040 --> 00:19:03,800 Don't do that. Water filling and Sprint scope 331 00:19:03,800 --> 00:19:06,120 creep communication silos and the NUM. 332 00:19:06,120 --> 00:19:11,360 The last one I'll give you their last pitfall is around metrics 333 00:19:11,360 --> 00:19:16,240 obsession. I I haven't seen this done that 334 00:19:16,240 --> 00:19:20,920 much in New Zealand. I have seen this done a lot 335 00:19:20,920 --> 00:19:25,040 overseas and that is using all the measurable chart charts 336 00:19:25,040 --> 00:19:28,080 around which will come with agile which kind of good like 337 00:19:28,080 --> 00:19:32,600 burn down charts and you know how much story points are we 338 00:19:32,600 --> 00:19:35,200 doing on average. And I think it's important 339 00:19:35,200 --> 00:19:39,000 insight to use. If they provide actionable 340 00:19:39,000 --> 00:19:43,200 insight but they need to be aligned with your project goals 341 00:19:43,280 --> 00:19:47,360 it look we're not going to we'll find room for improvement. 342 00:19:48,040 --> 00:19:51,360 If we have moving we've got three, you know 3 or 4 343 00:19:51,360 --> 00:19:54,160 developers then we might be able to work out some trends around 344 00:19:55,040 --> 00:19:59,000 quotation or this person's really bad at estimating stories 345 00:19:59,000 --> 00:20:01,800 and you should be doing that in a group setting anyway so you 346 00:20:01,800 --> 00:20:05,160 know they're the group is deciding on the on the points 347 00:20:05,160 --> 00:20:08,240 and not that new developer burn down has dropped. 348 00:20:08,240 --> 00:20:10,960 You know there's some indicators that you should look at if 349 00:20:10,960 --> 00:20:13,400 you're a great scrum master who's working in that team. 350 00:20:13,720 --> 00:20:16,680 Don't get obsessed with it, OK, do not get bogged down with 351 00:20:16,680 --> 00:20:19,960 measuring thing. The most important measure is, 352 00:20:19,960 --> 00:20:23,600 is the customer, either internal or external, using the product 353 00:20:23,680 --> 00:20:25,960 and are they liking what you're generating in the demos? 354 00:20:26,480 --> 00:20:28,160 You know do they feel like you're meeting their 355 00:20:28,160 --> 00:20:30,840 expectations and that you're heading in the right direction 356 00:20:30,840 --> 00:20:33,240 and and you're generating value for your time. 357 00:20:33,600 --> 00:20:35,520 They're the metrics that are the most important. 358 00:20:36,200 --> 00:20:40,400 There are five common pitfalls that I've seen in agile teams. 359 00:20:40,400 --> 00:20:44,280 I'm sure there are many more and I'd love you to ping me and tell 360 00:20:44,280 --> 00:20:47,960 me about your experiences and I might do a follow up podcast to 361 00:20:47,960 --> 00:20:51,360 talk about that. The next part, and again I've 362 00:20:51,360 --> 00:20:55,640 got five of these items, is around optimizing your agile 363 00:20:55,640 --> 00:21:00,280 workflow. So #1 is embracing cross 364 00:21:00,280 --> 00:21:03,880 functional teams. You need to have developers. 365 00:21:04,040 --> 00:21:06,840 Designers, I missed out before, sorry, should heavily be 366 00:21:06,840 --> 00:21:09,680 involved. Designers do fit between the 367 00:21:09,680 --> 00:21:11,600 BAS, you know, the designer and the tester. 368 00:21:11,600 --> 00:21:14,360 It's really important they are a missing solve sometimes or an 369 00:21:14,360 --> 00:21:17,080 external company. So developers, designers, 370 00:21:17,080 --> 00:21:19,760 testers, you know, BAS, other stakeholders. 371 00:21:19,760 --> 00:21:22,800 They work together OK. Especially if you're working on 372 00:21:22,800 --> 00:21:24,960 one product. You need those people to sit 373 00:21:24,960 --> 00:21:27,240 together, even if B as working on multiple things. 374 00:21:27,480 --> 00:21:30,000 They should sit around that team if that's their prime focus. 375 00:21:30,000 --> 00:21:33,200 They're an agile BA, for example, Then they should be 376 00:21:33,200 --> 00:21:35,920 working close to their team, at least understanding what's going 377 00:21:35,920 --> 00:21:39,040 on, checking in with them, coming to some of the stand ups, 378 00:21:39,040 --> 00:21:42,640 being being a chicken as opposed to a pig. 379 00:21:42,640 --> 00:21:44,560 And if you don't know what that is, then Google it. 380 00:21:44,880 --> 00:21:48,280 But it's around who's got skin in the game and who should talk 381 00:21:48,280 --> 00:21:52,400 more at stand up. So you need to embrace the cross 382 00:21:52,400 --> 00:21:55,840 functional team and and that includes SMEs who might work in 383 00:21:55,840 --> 00:21:59,160 the team to a point that SME I've generally found becomes a 384 00:21:59,160 --> 00:22:03,600 product owner in some in some settings good and bad thing 385 00:22:03,600 --> 00:22:07,080 because they need training. The next one is around refining 386 00:22:07,080 --> 00:22:09,280 your ceremonies. OK so like I said you have a 387 00:22:09,280 --> 00:22:12,000 highly functioning development team who's really great at doing 388 00:22:12,000 --> 00:22:14,240 agile. Got a great scrum master. 389 00:22:14,720 --> 00:22:18,520 Well, you should be assessing the effectiveness of those 390 00:22:18,520 --> 00:22:21,560 ceremonies. OK, the stand up, the retros, 391 00:22:22,120 --> 00:22:25,240 the even the demos and the way you demo, are people actually 392 00:22:25,240 --> 00:22:27,280 enjoying it. You know, maybe they got a a 393 00:22:27,640 --> 00:22:29,880 hiss and a bang out of the first one because I've never done one 394 00:22:29,880 --> 00:22:31,760 before. But actually maybe you need to 395 00:22:31,760 --> 00:22:34,480 be a bit more interactive. A PowerPoint presentation is not 396 00:22:34,480 --> 00:22:36,640 enough. Maybe there will be hands on, 397 00:22:36,640 --> 00:22:39,840 maybe you could bring in some customers that they could talk 398 00:22:39,840 --> 00:22:41,360 to. You need to adapt those. 399 00:22:41,360 --> 00:22:45,280 So in terms of measurement, it's more around the measurement of 400 00:22:45,280 --> 00:22:49,600 how your ceremonies are going, how effective they are of stand 401 00:22:49,600 --> 00:22:53,400 ups are always going over 15 minutes, then something's up. 402 00:22:53,560 --> 00:22:58,000 If you're doing Agile proper, if you know every morning, 15 403 00:22:58,000 --> 00:23:03,640 minutes Karen's telling you about her day, then maybe you 404 00:23:03,640 --> 00:23:07,040 know that's you need to manage that or have a personal kind of 405 00:23:07,240 --> 00:23:11,080 chinwag or before we do stand ups in the morning because 406 00:23:11,080 --> 00:23:13,600 that's not what it's about or someone's just going through so 407 00:23:13,600 --> 00:23:15,120 much detail about what they're doing. 408 00:23:15,120 --> 00:23:18,600 You know every single test case they tested, then maybe that 409 00:23:18,600 --> 00:23:21,800 isn't you know the right place for that and you need to manage 410 00:23:21,800 --> 00:23:24,760 that And if you don't have an effective scrum master then you 411 00:23:24,760 --> 00:23:29,440 need to do it as a team. The other one is automation. 412 00:23:29,480 --> 00:23:32,600 OK, so the whole point of Agile, and I do believe that when 413 00:23:32,600 --> 00:23:37,200 you're doing Agile and you Scrum, and I've looked at 414 00:23:37,200 --> 00:23:42,240 requirements packages for years, I do believe, and again in 2024 415 00:23:42,840 --> 00:23:45,720 using something like Jira and using something like Azure Dev 416 00:23:45,720 --> 00:23:47,760 OPS, I'm going to, I'm just going to give you those two 417 00:23:47,760 --> 00:23:49,200 examples because they're the most common. 418 00:23:50,400 --> 00:23:52,800 They're relatively cheap. You use them. 419 00:23:53,040 --> 00:23:58,520 I think Azure Dev OPS is actually even free automate the 420 00:23:58,520 --> 00:24:03,200 process of, you know, Kanban. You're bored of what you're 421 00:24:03,200 --> 00:24:04,880 what's in progress and what needs to be done. 422 00:24:05,000 --> 00:24:09,720 Blockers automate the ticketing, automate the backlog management, 423 00:24:09,720 --> 00:24:13,280 the notifications, and it will let you free up. 424 00:24:13,480 --> 00:24:16,880 Like I said, it's it's the mechanics and the engine that 425 00:24:16,880 --> 00:24:19,960 allows the people in the engine to to move quickly just to 426 00:24:19,960 --> 00:24:22,320 automate all that stuff. It should be common. 427 00:24:22,520 --> 00:24:26,440 It helps align yourself with the process so you're keeping some 428 00:24:26,440 --> 00:24:30,360 of those fundamental building blocks of Agile like in place, 429 00:24:30,360 --> 00:24:33,800 even if you're, you know, making them more aligned with your 430 00:24:33,800 --> 00:24:35,920 organization. As long as you're doing all 431 00:24:35,920 --> 00:24:39,200 those steps, maybe set that up. It doesn't take that long, half 432 00:24:39,200 --> 00:24:42,720 a day a day to set it up in Jira and then you're away laughing to 433 00:24:42,720 --> 00:24:45,080 a point of, you know, if someone wants to add things to the 434 00:24:45,080 --> 00:24:48,160 backlog then maybe you have a use the portal side and allow 435 00:24:48,160 --> 00:24:53,320 them to to send things through. It's something I do quite often 436 00:24:53,320 --> 00:24:56,560 I get asked to do for organizations and I think it's a 437 00:24:56,560 --> 00:24:59,360 really, really good point is to automate when you can. 438 00:25:00,640 --> 00:25:03,720 The other one a little bit more soft like I can. 439 00:25:03,720 --> 00:25:06,360 I'm not always a, you know, a hard ass. 440 00:25:07,080 --> 00:25:09,800 I can be nice too. And the next one is really 441 00:25:09,800 --> 00:25:13,840 important as AI. Don't know if this even happens 442 00:25:13,840 --> 00:25:16,160 waterfall projects. But I do know like if you are 443 00:25:16,160 --> 00:25:19,200 lucky enough to deliver a Big Bang project, you know, there's 444 00:25:19,200 --> 00:25:22,000 usually celebrations, there's usually pets on the back. 445 00:25:22,400 --> 00:25:25,680 You get mentioned it's actually it actually can be a very quiet, 446 00:25:25,960 --> 00:25:28,880 sad life. Writing on business cases I have 447 00:25:28,880 --> 00:25:31,840 for six months, you know with with no pets on the back. 448 00:25:32,080 --> 00:25:35,880 However, with Agile, you have an opportunity and you've got to be 449 00:25:35,880 --> 00:25:39,960 careful that you don't avoid any celebration because you're doing 450 00:25:39,960 --> 00:25:42,400 small relations. So you need to celebrate 451 00:25:42,400 --> 00:25:46,400 progress and win, OK? You need to reward and recognize 452 00:25:46,400 --> 00:25:50,000 individual and team achievements to motivate people. 453 00:25:50,200 --> 00:25:52,520 So instead of doing the maybe The Big Bang because you don't 454 00:25:52,560 --> 00:25:55,920 have that and you still do have an ultimate relation to a 455 00:25:55,920 --> 00:25:58,160 customer and you should celebrate that, you should 456 00:25:58,160 --> 00:26:00,640 celebrate every time. What did we do well, who did 457 00:26:00,640 --> 00:26:04,400 that really well this week? You know who did something extra 458 00:26:04,400 --> 00:26:07,840 special or had a great idea that they talked to the product owner 459 00:26:07,840 --> 00:26:09,360 about and now we've got a better product. 460 00:26:09,680 --> 00:26:13,320 Who's, you know, adding value, who's ultimately passionate, who 461 00:26:13,320 --> 00:26:17,120 stood, you know, stayed up all night testing the bug that we 462 00:26:17,120 --> 00:26:20,360 just couldn't get right so the engine could continue to pump 463 00:26:20,360 --> 00:26:23,240 out on Monday morning. Recognize that, you know, things 464 00:26:23,240 --> 00:26:26,520 like Prezi cards, head on the back, free coffee voucher. 465 00:26:27,000 --> 00:26:29,760 You know, just saying well done, Sam. 466 00:26:30,200 --> 00:26:34,960 You know, that is the kind of mindset you need to have. 467 00:26:34,960 --> 00:26:39,400 So that will help people feel better, motivate and and and 468 00:26:39,400 --> 00:26:41,280 uplift morale. So you should be doing that. 469 00:26:41,600 --> 00:26:44,640 And again if you don't have a scrum master jazz that or a team 470 00:26:44,640 --> 00:26:50,080 leader who's doing that, then do it as a team also, yeah, make 471 00:26:50,080 --> 00:26:52,280 it, make it substantial. Don't make it. 472 00:26:52,680 --> 00:26:54,240 When I say make it, make it an effort. 473 00:26:54,240 --> 00:26:58,720 It shouldn't be. I get a little bit vomity in my 474 00:26:58,720 --> 00:27:00,880 mouth when I see you know there's a button you can press 475 00:27:00,880 --> 00:27:04,920 and it's like celebrate Bob, celebrate Sam, celebrate Karen. 476 00:27:04,920 --> 00:27:07,520 It's like well you know that that's nice, but it's a little 477 00:27:07,520 --> 00:27:10,160 bit cheap. If you if, if I feel like always 478 00:27:10,160 --> 00:27:12,600 feel like you should put a bit of an effort into celebrating 479 00:27:12,600 --> 00:27:14,440 someone's success, not just pressing a button. 480 00:27:15,680 --> 00:27:18,320 The next one. The final part to have covered 481 00:27:18,360 --> 00:27:22,200 embracing cross functional teams, refining your ceremonies, 482 00:27:22,640 --> 00:27:25,680 automate where possible. Celebrate progress and wins. 483 00:27:26,320 --> 00:27:32,160 And the last one in optimizing workflow is continually learning 484 00:27:32,600 --> 00:27:36,360 and improving. OK, this is the mantra of agile. 485 00:27:36,360 --> 00:27:38,840 That's the whole point of it from a cultural point of view, 486 00:27:39,160 --> 00:27:41,520 that you should do the same for your own team. 487 00:27:41,760 --> 00:27:44,280 You need to embrace and encourage a culture of 488 00:27:44,280 --> 00:27:46,320 continuous learning and experimentation. 489 00:27:46,560 --> 00:27:50,160 Be open to trying new things. Adapt your approach based on 490 00:27:50,160 --> 00:27:51,680 feedback and results. OK. 491 00:27:52,000 --> 00:27:56,000 If you're the, you know, the hot development team who always, you 492 00:27:56,000 --> 00:28:01,160 know, pumps a product out on time, on budget, meets 493 00:28:01,160 --> 00:28:04,120 expectations, but someone comes through and goes, oh, actually, 494 00:28:04,120 --> 00:28:08,600 do you know that just from a design point of view, I've just 495 00:28:08,600 --> 00:28:10,720 noticed that one of our competitors is really using this 496 00:28:10,720 --> 00:28:16,240 new progressive disclosure way of designing, which is when you 497 00:28:16,240 --> 00:28:19,640 show information only when users need to see it, not not a whole 498 00:28:19,640 --> 00:28:23,560 page of questions, for example. How can we try that, You know, 499 00:28:23,560 --> 00:28:26,400 embrace that and take that feedback on board and take it as 500 00:28:26,400 --> 00:28:28,880 a challenge. We should be trying new things. 501 00:28:29,680 --> 00:28:32,320 If you want to have the best product on the shelf, if you've 502 00:28:32,320 --> 00:28:37,800 read Power of 1, thereby Peter Thiel, then you'll understand, 503 00:28:37,800 --> 00:28:39,680 you know, if you want to be the best, you need to produce the 504 00:28:39,680 --> 00:28:42,600 best, best products. And we should always be looking 505 00:28:42,600 --> 00:28:46,160 at improving. Now that doesn't mean that you 506 00:28:46,160 --> 00:28:49,360 have to always have a polished product, but once you're in the 507 00:28:49,360 --> 00:28:53,720 market and once you're just, you know, tweaking the product or 508 00:28:53,720 --> 00:28:56,240 you know, adding new features to your base product, go back and 509 00:28:56,240 --> 00:29:00,200 review what you've done. OK, so always learn and prove 510 00:29:00,200 --> 00:29:04,520 and I do think that our recommendation is if you have a 511 00:29:04,520 --> 00:29:07,640 Kanban board then you might have your blockers on there and what 512 00:29:07,640 --> 00:29:09,160 you've done and what you're doing in the future. 513 00:29:09,160 --> 00:29:13,200 For example, I would add suggestions for improvement 514 00:29:13,200 --> 00:29:16,080 column and then as your teams are doing the stand up, you can 515 00:29:16,080 --> 00:29:17,640 think of better ways of doing things. 516 00:29:17,960 --> 00:29:20,480 It's not an opportunity to give other people in your team a bit 517 00:29:20,480 --> 00:29:22,400 of grief. It isn't like Oh well I think 518 00:29:22,400 --> 00:29:25,160 you should be but if things come up we could go, we could do 519 00:29:25,160 --> 00:29:28,760 this. The opposite is true though too, 520 00:29:29,400 --> 00:29:34,000 and which is sometimes development teams take it upon 521 00:29:34,000 --> 00:29:38,040 themselves who inflate how long a story's going to take by using 522 00:29:38,040 --> 00:29:41,640 new kit because they want to. So an example being maybe 523 00:29:41,640 --> 00:29:45,360 there's a new HTMI, sorry HTML controller. 524 00:29:45,360 --> 00:29:48,120 That's really cool that everyone's using and I've 525 00:29:48,120 --> 00:29:50,320 decided the development team said I really want to do that. 526 00:29:50,600 --> 00:29:52,320 So for the next Sprint I'm going to try it. 527 00:29:52,680 --> 00:29:55,040 Now there's choices there, right? 528 00:29:55,040 --> 00:29:58,000 The choice is to use the standard way we did it or the 529 00:29:58,000 --> 00:30:00,640 choice is to use something that needs to be tested more because 530 00:30:00,640 --> 00:30:02,880 we've never done it before and it might have a different 531 00:30:02,880 --> 00:30:08,720 experience for our users. So that is a that is a question 532 00:30:09,040 --> 00:30:11,920 for the product owner to make a decision about whether or not 533 00:30:11,920 --> 00:30:14,760 they want to invest in that. There are some benefits using 534 00:30:14,760 --> 00:30:17,840 new kit making our product better, but it should really be 535 00:30:17,840 --> 00:30:20,440 their their decision. So just be aware that 536 00:30:20,440 --> 00:30:24,160 development teams have a tendency to want to use new foul 537 00:30:24,680 --> 00:30:29,200 fancy bells and whistle whistles and that can sneak in as well. 538 00:30:29,200 --> 00:30:32,920 So that's for me not really within alignment with what I'm 539 00:30:32,920 --> 00:30:34,760 talking about in terms of learn and improve. 540 00:30:34,760 --> 00:30:37,400 It doesn't mean you've got a free ticket just to try new 541 00:30:37,400 --> 00:30:40,800 stuff all the time without engaging with the team. 542 00:30:42,000 --> 00:30:45,960 So there is some other just hot topics you need to think about. 543 00:30:45,960 --> 00:30:49,120 How you can effectively manage stakeholders, expectations that 544 00:30:49,120 --> 00:30:52,920 they are hard to manage, not just keeping them aware, 545 00:30:53,520 --> 00:30:56,240 transparent and collaboration. Make sure you think of creative 546 00:30:56,240 --> 00:30:58,600 ways to do that. Measure success. 547 00:30:58,600 --> 00:31:01,520 How do you measure success of an agile implementation? 548 00:31:01,520 --> 00:31:04,160 What is the ultimate success measure, especially if your 549 00:31:04,160 --> 00:31:06,880 product's thrown away at the end of your releases? 550 00:31:06,880 --> 00:31:10,400 That is a positive thing because it means you're not wasting any 551 00:31:10,920 --> 00:31:13,720 money on that. How can you measure that is a 552 00:31:13,720 --> 00:31:15,360 success? Because that is success. 553 00:31:15,360 --> 00:31:17,480 But it's looked at in a different way. 554 00:31:20,040 --> 00:31:23,600 Just be really clear around the boundaries of Agile and some of 555 00:31:23,600 --> 00:31:25,960 the myths and misconception about what Agile is. 556 00:31:25,960 --> 00:31:29,440 I I believe it's agile delivery, which we're talking about today. 557 00:31:30,240 --> 00:31:34,520 And how do you ensure that those best practices are scalable and 558 00:31:34,520 --> 00:31:37,680 sustainable in the long term? And that's by, you know, being 559 00:31:37,680 --> 00:31:40,320 flexible, being adaptive, always open to learning. 560 00:31:40,720 --> 00:31:46,200 And so that's what you should be doing to really get Agile done 561 00:31:46,200 --> 00:31:49,760 right in your organization. I hope you've learned something 562 00:31:49,760 --> 00:31:51,360 today. So that's agile, done right, 563 00:31:51,360 --> 00:31:54,480 avoiding pitfalls and optimizing workflow. 564 00:31:54,480 --> 00:31:55,800 I hope you've learnt something today. 565 00:31:56,040 --> 00:31:58,200 I really want this to be a discussion. 566 00:31:58,200 --> 00:32:00,640 See if you've got any feedback, let me know. 567 00:32:00,640 --> 00:32:03,920 I want to hear about your Agile experiences and I'll see you 568 00:32:03,920 --> 00:32:04,440 next time.