The Better Business Analysis Institute presence, the Better Business Analysis podcast with Kenjan Walsh. Hi, everybody. It's Benjamin Walsh from the Better Business Analysis Institute. And this is the Better Business Analysis Podcast. Thanks for joining. This week we're going to talk about Agile. We talk about Agile quite a bit, but specifically the topic I want to talk to you about is the pitfalls and optimizing workflow.
OK, so I've called this topic in this episode Agile Done right, Avoiding common Pitfalls and Optimizing Workflow. When I save the workflow, I'm talking about the processes within the agile environment and what you need to have set up in order to run a tight ship. And I am really talking about
agile delivery here. So the delivery side, not other flavors of agile for transformation, you know organizational transformation or or culture shift, this is really around delivery and if you've got a development team and you're in that environment, then you could think of your agile development in this context. So we're going to go straight into it. We're going to start with
avoiding common pitfalls. And so I'm going to talk about why they're pitfalls and some acknowledgments that you need to be very clear about so you don't fall into these holes. I don't have all the answers here. I'm sure there are good techniques for digging your way out of those pitfalls. If you fool them, just avoid them to start off with. And I'm sure you have some
feedback. So if you've got feedback, tag me in, tag the institute in, and we can talk about your feedback around pitfalls that you've found when using Agile. So I've got 5 here, 5 pitfalls. I didn't want to boil the ocean and come up with 20s. So 5 common pitfalls that I think you need to avoid in Agile. We're going to start with number one. Number one is so important and it is. Do not treat Agile as a silver bullet, OK? The pitfall is treating it as a silver bullet.
Agile is a wonderful framework, powerful. You know, if you think of Scrum, it's so good in terms of an evolution of how we were doing things beforehand. You know, people can get overwhelmed with it from a cultural point of view, from a, you know, anti SDLC, waterfall approach. But Agile didn't fix all the pro program or project delivery challenges we have. It wasn't a magic fact. Fact.
OK, it it doesn't come into the organization and fix everything, so don't treat it like it is. Or, you know, I've got a solution for that. Let's go agile. No, that is not what. What problem are you trying to solve now? There was a common problem with the fact that requirements changed throughout the life cycle of our project or a piece of work.
There was common problems around the fact that we weren't engaging stakeholders enough, We weren't demoing enough, We didn't, you know, work on the most valuable stuff up front. We didn't time box how we did things. There were lots of good reasons for Agile, and that was the reason we implemented it. But it isn't going to solve things like project risk necessarily as much as other
methods. It isn't necessarily going to outline exactly how to write a user story with enough information for your designers and your developers. It isn't going to define the role of the BA, OK? So it's not going to solve all those challenges and especially if you're adopting very complex, maybe you've got a complex
organization. So I'm not saying complex in a derogatory term, but if you're using for example Scaled Agile for Enterprises safe framework, which is the type of agile methodology, you know that that is multi layered. It's got all sorts of things going on. It talks about a whole lot of different methodologies now, again because it's even bigger and more complete or robust if you like. For an organization, people are
going to also go well. This is even better because it's got all the processes and procedures we need and the same way Prince Two didn't solve all the delivery problems with the project. Agile or Safe or flavor of Agile framework is not going to solve all your problems. It is not the silver bullet. So don't treat it as such. Just treat it as the way in which software which is primarily, is delivered through a delivery team.
The other thing that happens. So flipping back to looking at Sprint. So the if you don't know what a Sprint is then they are the you know time box periods where you're pulling things off the backlog which is all the requirements and you're pulling in what we should do next in a time box period of time which has a Sprint, has a goal and a definition. There is a major pitfall here and it's called waterfalling in Sprint, OK.
And it's a little bit of a nod or a bit of A to say that you know we've we're our waterfall mindset of doing everything to the you know from one our requirements one to 100 all on go and kind of sneaky in waterfall. There what happens is that people are trying to cram traditional kind of sequential fight fight phases into short
sprints. So they're saying well and for example for Sprint one doesn't matter if it's two weeks we'll go over 2 weeks it needs to be 4 weeks and we need to do at least the infrastructure set up in the first Sprint. That is actually a wonderful project. It is, and I'm I have nothing against for projects by the way. But if you're deciding you're going to do Agile, you don't do
that. So what you do is you do a slice of the solution from beginning to end for the job to be done regardless of the the layer of infrastructure you need. And you try and do those the most vital steps, the most valuable steps at that point in time in the Sprint. So another way of saying that is you're not doing HDLC where you're going. OK, we'll do the infrastructure 1st and we'll do the design. You're not carving it that way, you're carving it on customer value.
So if you are doing a Sprint 0, setting up infrastructure 1st and all the rest of it, don't kid yourself. You're not doing agile and there's no reason. Sorry. Just be clear here, it's not an and or there's no reason why you couldn't do an infrastructure project if that's necessary for the product you're doing as a for project. Separate to this and then do an agile project to use that infrastructure to make product. There's no there's I'm not saying you know you have to do
infrastructure in an agile way. If you know that this box needs to be done, don't try and cram it into an agile methodology. Just get that done and then you know in sequence or for in parallel or after the fact. Start using delivery agile for deliver, delivering customer facing products. You know on top of the infrastructure you need to, you know, emphasize the idea that you're doing iterations here you're doing, you're not trying to implement a full solution
when you do agile. So let's talk about more of a product, not an infrastructure mindset and say we're building a product, a web app. Your job isn't to go, OK, well, I need to have a login Screener, you know, a front end, the database done and you know a landing page before we actually do the next pieces of functionality. And I need to do that all straight away. It could be what that stuff's not important. It's not important to do login straight away.
It's not important to necessarily have all those account features or even have a database to be honest. Sprint Zero could simply be doing some designs for Sprint one, so there is no Sprint 0. Just to be clear, Sprint One is
showing designs to customers. It's simply a business facing Sprint. So again, when we do our agile delivery, in the same way that we could split out prerequisites in a different type of project, set up methodology like waterfall, we could equally include inside an agile project the first Sprint or first couple of sprints may not be technology driven, they could simply be sprints around focusing on
customer feedback and design. In case you might, your delivery sprints might only happen at Sprint six or something. OK so that happens commonly and sometimes those sprints are done through rapid prototyping. They're done in big room planning and and that for me, I actually support that it's it gets developers involved early and tested but it's actually got nothing to do with producing any code it's all about producing designs and feedback from customers.
So definitely keen on that but again don't try and do all your analysis in Sprint one, that's not the BA phase and and be honest with yourself if you need to do so. Sorry. Here's here's a here's a bit of a giveaway and we talk about this at the institute. I have a really strong belief that enterprise analysis, strategic analysis in detailed sorry high level requirements capture should all be done before should be done in a in a
very you know project. You could say waterfall manner but a a series manner manner until you get funding to then get into delivery and deliver some stuff be that mock ups or code and then start using agile proper at that point. So I have a that's my belief. You might work in a different way. However, I would say that regardless of the fact know which methodology you're using.
The other one of course, which was one of the purposes of moving to a job but really hasn't been at all helped through using these methodologies is scope creep. So this can happen for lots of reasons. One of them is the fact that the backlog just keeps getting added to it's it becomes the project becomes a request manage, not a request management of requirements that are on the fly. OK?
And again that's why the method of doing some high level business requirements and objectives basically Epics upfront reduces that completely It it actually reduces the scope problem that I'm talking about right now. So you have that first layer of user stories all ready to find before you start that produces this problem. But if you literally say we're going to backlog, we add it to the backlog, which is a lot of agile projects happen, then you actually have an uncontrolled door there.
So you have effectively uncontrolled scope and that will derail your agile project. I see it all the time. It's to do with having you know an inbox that continually grows. It has a problem with the value items that have been put in the Sprint up until you run out of money not being enough to deliver an end product that anyone wants. It's it's the problem with not really architecting the solution
upfront in some shape or form. So to manage scope creep that is really a project manager's job or product manager. If you don't have a project manager working on it, they should be looking at this. You need to manage strategies for managing scope. There are things like backlog prioritization. There is no reason why you can't say, add things to the backlog with an understanding that they won't be done probably or they won't be prioritized throughout
this process. Sprint planning can reduce those. But again, I don't think those two agile method or built in controls for agile completely solve the issue. I think it's being using user
storyboards really helps here. Being clear about the jobs to be done helps here really understanding that not only do you need to deliver the most valuable stuff, not not chosen by the product owner, by chosen by your customer and then facilitated through a conversation with your product owner, but also the fact that you've got all the critical items that are needed to deliver at the end of your project.
OK. And I want to just clarify that again or say that in a different way at the end of the Sprint. You're not. You're supposed to have a working prototype of a product that you can demo. OK, it could be a piece of paper, OK, it doesn't have to be a piece of software. And you should be able to demo the progress that you've made. That's the whole point of using Scrum. Now, that doesn't mean it's really full release to the, you know, to the public at this
point. And just so you can demo to the stakeholders to show them it doesn't mean you're releasing necessarily on the final infrastructure or environment to go live. That might be another Sprint. So if that is the case, then you need to be careful that you've built in enough time to get it to, you know, public release ready if you're doing a public app and if you keep doing the functions, you're never going to get the chance.
I'm working on a piece of work at the moment which is a startup company working on a mobile web app for businesses and consumers. And we're working on still working on functionality, base functionality before it gets demoed to some businesses. And you know it still needs some work and it's not polished at all. And you know, part of me wants to make it really sexy before we show anyone, which is the opposite of what you should do when you're building a new product that's new.
However, what I'm well aware of is there's a whole bunch of work if we wanted to move a mobile app and a web app to scalable architecture once we've even gone through the agile deliveries side right? There will be a number of sprints so I can't just estimate the development time or the number of sprints will cap it. I know there needs to be this pretty water fully process of releasing apps to the App Store.
You know, putting a website on scalable AWS architecture or whatever the architecture is. You know doing testing, doing pin testing, all the security side that is an additional piece of work. It's pretty common, it's pretty standardized, really needs to do it agile. I just need we just need to do that as part of the team and that's going to be over and above the development cycle, OK, before release. So just think about that.
So in that case that isn't scope creep, that is stuff that you should have in scope and be really clear that you've got even less room for the backlog items, that the product functional backlog items. The next one that happens even though we the whole purpose of Agile is to try to stop the surrounding is communication silos.
So that's still not broken down. So we used to have this big wall between the requirements phase and the delivery phase that was a big wall that almost like the Berlin Wall. We've broken that down and we can now communicate you know between West and East Germany. But we haven't solved other communication issues which might be which might just happen, what might happen when working on a project and then more individual
silo. So you have communication breakdowns between barriers between teams, stakeholders, clients, product owners and clients. If you've got a project manager, you've got project manager versus product manager issues if you've got both of those. And so you really need to be more ultra transparent. And no, because you haven't run, because everything is fluid and agile. You need to be ultra transparent
and ultra collaborative. You almost need to document your communication more than you would in a waterfall situation. And you need to communicate that you don't. When I say document more I don't mean 100 page spec.
I mean using visual communication tools like whiteboarding online whiteboarding tools and post its and a room and you need to have all the stuff that people can come and look at down to ideas off because you're you're running quickly and so you need to be better at occasion with
their job. The other thing of course is that the whole point is that you should have this development team that's working together and should have multifunctional teams and all the rest of it and one that never happens. People are on other projects. So when you you know, you've got to think that if you're product owners across three products, for example, you know they might not be on when you're doing the, they might not be thinking about your product every every 5 minutes. So that's hard.
And then also you might be bringing in an architect who now needs to, you know get up to speed about where you're at or ABA or a tester. So you generally find the core team is generally A scrum master and a couple of developers, maybe a tester and maybe ABA if you're lucky. Now that that means that all those other people are not up to speed with you. You might, you know he might be working really, really well. And then I've got two things to
say about that. One is I didn't like this when I first saw it, but I now believe my current belief this week is that if you have a highly functioned delivery team like, you know, developers, testers, maybe you've got, maybe you could be a a scrum master and they're like cranking it. Don't break that model just so they're more collaborative or so you can insert APM and and rigor into it. Let them run fast and just understand and agree with them. You may decide on the inputs and outputs.
They may decide they want requirements in this format. This is the audience. They work really well this way. Don't wreck their great working way. You may even be jealous of it by just getting involved in their in their jazz right and involved in their stuff. Feed it, feed the machine. They should be a highly functioning machine. And if you've got great inputs and outputs in their demoing, let them run that way.
You don't need to wrap around unnecessary meetings to do that and that's where I've seen Agile being the most effective as in a development in that kind of environment. And if you're in a startup company and the largest startup company then you may and you're only working on one product, then of course the product owners should be involved in in
everything as well. That isn't the case for most organizations we all work at. So we've we've just covered off treating Agile as a silver bullet. Don't do that. Water filling and Sprint scope creep communication silos and the NUM. The last one I'll give you their last pitfall is around metrics
obsession. I I haven't seen this done that much in New Zealand. I have seen this done a lot overseas and that is using all the measurable chart charts around which will come with agile which kind of good like burn down charts and you know how much story points are we doing on average. And I think it's important insight to use. If they provide actionable insight but they need to be aligned with your project goals it look we're not going to we'll find room for improvement.
If we have moving we've got three, you know 3 or 4 developers then we might be able to work out some trends around quotation or this person's really bad at estimating stories and you should be doing that in a group setting anyway so you know they're the group is deciding on the on the points and not that new developer burn down has dropped. You know there's some indicators that you should look at if you're a great scrum master who's working in that team.
Don't get obsessed with it, OK, do not get bogged down with measuring thing. The most important measure is, is the customer, either internal or external, using the product and are they liking what you're generating in the demos? You know do they feel like you're meeting their expectations and that you're heading in the right direction and and you're generating value for your time. They're the metrics that are the most important.
There are five common pitfalls that I've seen in agile teams. I'm sure there are many more and I'd love you to ping me and tell me about your experiences and I might do a follow up podcast to talk about that. The next part, and again I've got five of these items, is around optimizing your agile workflow. So #1 is embracing cross functional teams. You need to have developers. Designers, I missed out before, sorry, should heavily be
involved. Designers do fit between the BAS, you know, the designer and the tester. It's really important they are a missing solve sometimes or an external company. So developers, designers, testers, you know, BAS, other stakeholders. They work together OK. Especially if you're working on one product. You need those people to sit together, even if B as working on multiple things. They should sit around that team if that's their prime focus.
They're an agile BA, for example, Then they should be working close to their team, at least understanding what's going on, checking in with them, coming to some of the stand ups, being being a chicken as opposed to a pig. And if you don't know what that is, then Google it.
But it's around who's got skin in the game and who should talk more at stand up. So you need to embrace the cross functional team and and that includes SMEs who might work in the team to a point that SME I've generally found becomes a product owner in some in some settings good and bad thing because they need training. The next one is around refining your ceremonies. OK so like I said you have a highly functioning development team who's really great at doing
agile. Got a great scrum master. Well, you should be assessing the effectiveness of those ceremonies. OK, the stand up, the retros, the even the demos and the way you demo, are people actually enjoying it. You know, maybe they got a a hiss and a bang out of the first one because I've never done one before. But actually maybe you need to be a bit more interactive. A PowerPoint presentation is not
enough. Maybe there will be hands on, maybe you could bring in some customers that they could talk to. You need to adapt those. So in terms of measurement, it's more around the measurement of how your ceremonies are going, how effective they are of stand ups are always going over 15 minutes, then something's up.
If you're doing Agile proper, if you know every morning, 15 minutes Karen's telling you about her day, then maybe you know that's you need to manage that or have a personal kind of chinwag or before we do stand ups in the morning because that's not what it's about or someone's just going through so much detail about what they're doing.
You know every single test case they tested, then maybe that isn't you know the right place for that and you need to manage that And if you don't have an effective scrum master then you need to do it as a team. The other one is automation.
OK, so the whole point of Agile, and I do believe that when you're doing Agile and you Scrum, and I've looked at requirements packages for years, I do believe, and again in 2024 using something like Jira and using something like Azure Dev OPS, I'm going to, I'm just going to give you those two examples because they're the most common. They're relatively cheap. You use them.
I think Azure Dev OPS is actually even free automate the process of, you know, Kanban. You're bored of what you're what's in progress and what needs to be done. Blockers automate the ticketing, automate the backlog management, the notifications, and it will let you free up. Like I said, it's it's the mechanics and the engine that allows the people in the engine to to move quickly just to automate all that stuff. It should be common.
It helps align yourself with the process so you're keeping some of those fundamental building blocks of Agile like in place, even if you're, you know, making them more aligned with your organization. As long as you're doing all those steps, maybe set that up. It doesn't take that long, half a day a day to set it up in Jira and then you're away laughing to a point of, you know, if someone wants to add things to the backlog then maybe you have a use the portal side and allow
them to to send things through. It's something I do quite often I get asked to do for organizations and I think it's a really, really good point is to automate when you can. The other one a little bit more soft like I can. I'm not always a, you know, a hard ass. I can be nice too. And the next one is really important as AI. Don't know if this even happens
waterfall projects. But I do know like if you are lucky enough to deliver a Big Bang project, you know, there's usually celebrations, there's usually pets on the back. You get mentioned it's actually it actually can be a very quiet, sad life. Writing on business cases I have for six months, you know with with no pets on the back. However, with Agile, you have an opportunity and you've got to be careful that you don't avoid any celebration because you're doing
small relations. So you need to celebrate progress and win, OK? You need to reward and recognize individual and team achievements to motivate people. So instead of doing the maybe The Big Bang because you don't have that and you still do have an ultimate relation to a customer and you should celebrate that, you should celebrate every time. What did we do well, who did
that really well this week? You know who did something extra special or had a great idea that they talked to the product owner about and now we've got a better product. Who's, you know, adding value, who's ultimately passionate, who stood, you know, stayed up all night testing the bug that we just couldn't get right so the engine could continue to pump out on Monday morning. Recognize that, you know, things like Prezi cards, head on the back, free coffee voucher.
You know, just saying well done, Sam. You know, that is the kind of mindset you need to have. So that will help people feel better, motivate and and and uplift morale. So you should be doing that. And again if you don't have a scrum master jazz that or a team leader who's doing that, then do it as a team also, yeah, make it, make it substantial. Don't make it. When I say make it, make it an effort.
It shouldn't be. I get a little bit vomity in my mouth when I see you know there's a button you can press and it's like celebrate Bob, celebrate Sam, celebrate Karen. It's like well you know that that's nice, but it's a little bit cheap. If you if, if I feel like always feel like you should put a bit of an effort into celebrating someone's success, not just pressing a button. The next one. The final part to have covered embracing cross functional teams, refining your ceremonies,
automate where possible. Celebrate progress and wins. And the last one in optimizing workflow is continually learning and improving. OK, this is the mantra of agile. That's the whole point of it from a cultural point of view, that you should do the same for your own team. You need to embrace and encourage a culture of continuous learning and experimentation. Be open to trying new things. Adapt your approach based on feedback and results. OK.
If you're the, you know, the hot development team who always, you know, pumps a product out on time, on budget, meets expectations, but someone comes through and goes, oh, actually, do you know that just from a design point of view, I've just noticed that one of our competitors is really using this new progressive disclosure way of designing, which is when you show information only when users need to see it, not not a whole
page of questions, for example. How can we try that, You know, embrace that and take that feedback on board and take it as a challenge. We should be trying new things. If you want to have the best product on the shelf, if you've read Power of 1, thereby Peter Thiel, then you'll understand, you know, if you want to be the best, you need to produce the best, best products. And we should always be looking
at improving. Now that doesn't mean that you have to always have a polished product, but once you're in the market and once you're just, you know, tweaking the product or you know, adding new features to your base product, go back and review what you've done. OK, so always learn and prove and I do think that our recommendation is if you have a Kanban board then you might have your blockers on there and what you've done and what you're doing in the future.
For example, I would add suggestions for improvement column and then as your teams are doing the stand up, you can think of better ways of doing things. It's not an opportunity to give other people in your team a bit of grief. It isn't like Oh well I think you should be but if things come up we could go, we could do
this. The opposite is true though too, and which is sometimes development teams take it upon themselves who inflate how long a story's going to take by using new kit because they want to. So an example being maybe there's a new HTMI, sorry HTML controller. That's really cool that everyone's using and I've decided the development team said I really want to do that. So for the next Sprint I'm going to try it. Now there's choices there, right?
The choice is to use the standard way we did it or the choice is to use something that needs to be tested more because we've never done it before and it might have a different experience for our users. So that is a that is a question for the product owner to make a decision about whether or not they want to invest in that. There are some benefits using new kit making our product better, but it should really be
their their decision. So just be aware that development teams have a tendency to want to use new foul fancy bells and whistle whistles and that can sneak in as well. So that's for me not really within alignment with what I'm talking about in terms of learn and improve. It doesn't mean you've got a free ticket just to try new stuff all the time without engaging with the team. So there is some other just hot topics you need to think about.
How you can effectively manage stakeholders, expectations that they are hard to manage, not just keeping them aware, transparent and collaboration. Make sure you think of creative ways to do that. Measure success. How do you measure success of an agile implementation? What is the ultimate success measure, especially if your product's thrown away at the end of your releases? That is a positive thing because it means you're not wasting any money on that. How can you measure that is a
success? Because that is success. But it's looked at in a different way. Just be really clear around the boundaries of Agile and some of the myths and misconception about what Agile is. I I believe it's agile delivery, which we're talking about today. And how do you ensure that those best practices are scalable and sustainable in the long term? And that's by, you know, being flexible, being adaptive, always open to learning. And so that's what you should be doing to really get Agile done
right in your organization. I hope you've learned something today. So that's agile, done right, avoiding pitfalls and optimizing workflow. I hope you've learnt something today. I really want this to be a discussion. See if you've got any feedback, let me know. I want to hear about your Agile experiences and I'll see you next time.