The Better Business Analysis Institute. Presence the Better Business Analysis podcast. With Benjamin Walsh. Hi, everybody, and welcome back to the Better Business Analysis podcast with your host, Benjamin Walsh. And this week we continue on our BA Byte series and we're diving into Remember Agile. Yeah, about that. Once Upon a time, Agile was a shiny new buzzword that promised to revolutionize the way we
delivered projects. Manifestos were signed, stand ups became sacred rituals, and teams everywhere started slapping Agile onto their CVS. Like it was a magic wand. But somehow, along the way, Agile went from revolutionary to, well, awkward. Now Agile isn't dead. It's just rebranded, adapted, and misunderstood to a point where some companies are treating it like a dirty word.
So in this episode, we are going to unpack the ghost of Agile past, tackle its modern struggles, and most importantly, figure out how to breathe life back into this iterative an adaptive workflow without tripping over the dogma or where some people have taken it. Spoiler alert, it's not about being agile. It's about being smart, focused,
and adaptive. Let's dive into some real tales of iterative project chaos, where things went spectacularly wrong and how small tweaks can bring projects and sanity. Back on track. Chapter 1 When flexibility becomes indecision, teams took adaptivity to mean we don't need to stick to the plan. Without clear goals, they pivot endlessly, leading to missed timelines and frustrated
stakeholders. Even more so, they always fall back onto we didn't have the requirements signed off yet, which of course is a different model. A mobile app project started with a simple Go goal, launching MVP three months. Three months later, the team still hadn't agreed on what features were must haves versus nice to haves. By the time they aligned, the competitors had beaten them to the market. How do we fix this? We define a northern star goal have a clear overarching objective.
If one everyone rallies around like strategic objectives, which is also a good chance to drop down into the what high level watts in terms of epic stories. This you introduce time box decisions, set deadlines for deciding priorities during each cycle to avoid endless debates. And this can be hard in a hierarchical organization. So you need to get your project manager, your project governance team to agree this upfront.
You missed the time wiggle ago with the recommended option build in feedback loops allow space to reflect and adjust. Not many teams do this. They do not take time out. They don't do a retro, they don't take a breath and adjust. That's the whole point. Obviously, you need to complete some planned iterations before you do that. OK? It's not just about another meeting. Chapter 2 The meeting that ate the Sprint Syndrome teams began and became bogged down in
ceremonies. Daily stand ups turn into 30 minute status updates. Everyone talked. Planning meetings stretched for hours. Work was sacrificed on the altar of over communication. One example is a project team spent 12 hours a week in meetings leading developers with only half their time to actually code. The result? Missed deadlines and frustration. How do we fix this? Cap stand ups to 10 minutes. Everyone shares only key blockers or wins. Not what they're doing this week or last week.
Who cares. Look on the Cambian board like updates in slack or shared document. That's where you can reference those. Limit retros to action items. Focus on lessons learned and action. More items. Not about venting. It's not for venting that creates negativity and just starts to destroy the team culture. Chapter 3 Lack of unified product vision. Teams build features without understanding the bigger picture, leading to disjoint user experiences and wasted effort.
An example, a retail company spent three months developing a buy now, pay later feature. Turns out customers were asking for better search filters, not deferred payments. The feature flocked and resources were wasted. People are now over that kind of feature and they could have just integrated with an existing provider. How do we fix this? Start with customer discovery. Talk to users to validate what they really need. Is it desirable? Is it feasible? Is it viable? Use a lean road map.
Prioritize high impact features that align with your objectives and your epics. And there needs to be a clear connection to business goals, not just an arbitrary connection. Backup. Keep stakeholders alight. Communicate to stakeholders about each feature and how it fits in terms of the overarching product vision. Chapter 4 Done but not delivered. Team Smart work is done but didn't ensure it was usable or valuable to end users.
Done became a technical milestone instead of a customer focused 1. I know of a Financial Services Act. They completed all the back end development for a new investment feature. I actually forgot to integrate it with the UI. Users had no idea that they had done that work. That feature even existed because it wasn't generating value to the UI. You need to redefine them. It includes testing, integration, customer validation
as part of the criteria. There's too much time spent with developers telling testers what they should test. Instead of developers testing their own code and the testing being driven by the business requirement. Use demo days. Showcase completed work to stakeholders and users to ensure and meet expectations. You don't have to wait for a retro. That's where the ceremonies are enforced, whereas demo days may just happen as and when required. Make sure you test in small batches.
Deliver small user face facing increments to get feedback sooner. That's what testing is about. Technical testing is another story. And actually, that is the area where AI and a lot of automation or even outsourcing would be a better option. Remember, done isn't a check box. Chapter 5 stakeholder ambushes, last minute stakeholder demands threw off the team's focused and planning. Happens all the time. Where's the protective shield
here? This is one of the reasons why Scrum was developed in the first place. A marketing executive insists of adding a new promotional feature mid iteration, delaying delivery of a critical bug fixes for Go life. How do you fix this? You need to set clear change request protocols. But I thought we were doing agile mid flight cycle changes. There needs to be a process wrapped around it. Agile is about being agile at the iteration level, not within the iteration level. Schedule regular.
Check insurance. Make sure stakeholders are aware of what you're working on. Be very clear with your plan. An agile plan might not be good enough. It's not good enough for stakeholders. Give them a project plan, not a detailed one in project, but tell them what you're working on this week and help them understand. And of course create a parking
lot. Log non critical requests for future prioritization and again, it doesn't just go on the backlog and gets determined by the individual scrum team or Sprint team or squad. It's actually something you're going to do. So sometimes that doesn't work very well in Agile. In the end, it's not about remembering Agile as it was, it's about evolution. It's about taking those principles that are so valid and
fit it in today's realities. The ceremonies, the jargon, they're just tools, but there is some structure and diet that you need to understand why it's there. What really matters is delivering value, staying adaptive, and keeping teams motivated and working. So next time you hear someone groan at the word agile, remind them it's not agile that failed, it's how we used it or abused it. Let's fix that together.