Welcome to the Architecture Corner.
Today we're digging into. Ah.
A pretty persistent tension in our field, the relationship
between software estimations, rigorous planning and agile
methods like Scrum. The question really is, can you
actually integrate that kind of planning into agile
productively? Or are.
They, you know, fundamentally at odds because development is just
so uncertain. My position is that estimations
are essential tools, really vital for managing risk and the
problems we see. They stem from misuse, not
because the tools themselves are broken.
Hmm, I'm not quite sold on that. I think the very nature of
software development where you know each project has this
unique element, it really limits how useful those early estimates
can be that. Creates a.
Real fundamental tension with agiles whole idea of embracing
change and learning as you go we have to admit that trying to
plan everything out in high detail right at the start well
that often just. Creates waste.
OK. I absolutely agree with you on
the uncertainty part. But that's.
Precisely why we need to shift our focus.
We're not really estimating completion dates in the way
people think we should be modeling risk.
And if you just dismiss estimations entirely, you miss
their main benefit. They force really important
discussions. They bring delight just how
unclear requirements might be. The sophistication isn't in
hitting a date, it's intriguing estimates as distributions.
You know distributions with variance and certainty attached.
Like. X percent confidence you'll be
within Y percent variance. If we could just correct that
mindset. Lanning becomes this crucial way
to spot high risk areas, not just Reddit to date.
That sounds, well, compelling in theory, but the reality is the
cone of uncertainty kind of proves that even those early
distribution models are still going to be highly speculative,
right? If you.
Do really detailed planning way ahead of time and then the
requirements pivot, which let's be honest, they almost always do
a lot of that planning effort just.
Gets thrown. Away the basic truth for complex
software is that our understanding the requirements,
they constantly sharpen U as we learn more.
And that's why that sentiment, you know it's done when it's
done. Even if it sounds impractical
commercially, it's actually rooted in the reality of how
innovation happens in software. Look, I appreciate the
philosophical angle, I really do.
But it kind of ignores the organizational reality we all
live in, this idea that we can just operate under.
It's done when it's done well. It's simply unsustainable for
almost any company. You have finite budgets, you
have customer commitments, these external constraints, fiscal and
contractual. They demand some kind of
planning mechanism, even if the dev process itself stays agile.
So if we accept that budgets aren't infinite, we have to look
for a solution that gives us that organizational governance
but keeps the development team agile.
OK. So if we must have those
guardrails, what approach can actually deliver that without
just reimposing the old rigidity that Agile trying to get rid?
Of. Right.
And this. Is where I think a specific
technique comes into play. 1 Articulated really well by Mario
Bittencourt, the work breakdown structure, the WBS.
I believe the WBS is potentially the key to bridging that gap
between governance and agile execution.
It forces you to breakdown Major.
Features. Hierarchically, down to a level
where you can actually isolate tangible, estimable risks.
ABS, when it's done right, is primarily an organizational
budgeting tool and only secondarily a task planning
tool. It lets you alley that variance
modeling we talked about to specific high risk pieces much
more accurately than just slapping story points on a.
Big feature. That makes sense for many fiscal
governance, but what about the operational cost?
Isn't there a real risk that the WBS just leads straight back to
the analysis paralysis Agile is supposed to prevent?
I mean, you're arguing for a method that ends U creating this
super detailed list of tiny elements.
If our backlog refinement is already good and detailed, and
in a mature scrum set it really should be, doesn't the WBS just
become, well, redundant? It feels like organizational
waste duplicating planning effort way before you actually
need that level of detail for a Sprint.
Yeah, I hear that concern about duplication, but a WBS done
properly shouldn't replicate backlog refinement.
They serve different purposes. Backlog refinement that's about
tactical execution, getting ready for the next Sprint.
WBS is more strategic. It's about decomposition for
financial tracking and large scale scope alignment.
It's value is in forcing everyone to agree on the major
components and the critical path risks tied to them.
And that feeds directly into those variance estimates we
discussed earlier, plus the process itself doing the WBS,
comparing outcomes to the plan. That's the learning mechanism.
That's how estimation stops being a guessing game and
becomes a structured way to learn and improve.
OA sounds like. We're sort.
Of agreeing that estimation isn't dead, it has a role.
As a. Tool for risk management for
fostering discussion Our main point of difference seems to be
on how much formal structure. Like a.
Work breakdown structure is needed to get that
organizational alignment versus maybe.
Hindering rapid development, I still.
Lean towards. The idea that the.
Overhead of building and maintaining a formal WBS can
often outweigh its benefits and a fast moving product
environment potentially slowing things down.
And I'd argue that without some kind of structural tool like
WBS, organizations just lack the common language they need for
that fiscal governance and big picture scope negotiation.
It leaves the agile team vulnerable to budget shocks from
outside. Look, neither extreme works
right? No plans at all or completely
rigid perfect estimates. That's not desirable.
Finding the balance requires pragmatism and focusing on
understanding that bigger picture.
Well, thank you for. Joining us for this discussion.
Yeah, thanks for listening. Do check the description For
more information. And just a reminder to
subscribe. For free.
To the Architecture Corner newsletter over at
architecturecorner.substack.com.