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.