1
00:00:00,090 --> 00:00:01,820
Welcome to the Architecture 
Corner. 

2
00:00:02,560 --> 00:00:05,390
Today we're digging into. 
Ah. 

3
00:00:05,440 --> 00:00:09,010
A pretty persistent tension in 
our field, the relationship 

4
00:00:09,020 --> 00:00:13,250
between software estimations, 
rigorous planning and agile 

5
00:00:13,260 --> 00:00:17,030
methods like Scrum. 
The question really is, can you 

6
00:00:17,040 --> 00:00:20,170
actually integrate that kind of 
planning into agile 

7
00:00:20,180 --> 00:00:21,730
productively? 
Or are. 

8
00:00:21,740 --> 00:00:25,330
They, you know, fundamentally at
odds because development is just

9
00:00:25,340 --> 00:00:28,130
so uncertain. 
My position is that estimations 

10
00:00:28,140 --> 00:00:31,550
are essential tools, really 
vital for managing risk and the 

11
00:00:31,560 --> 00:00:34,710
problems we see. 
They stem from misuse, not 

12
00:00:34,720 --> 00:00:36,370
because the tools themselves are
broken. 

13
00:00:36,720 --> 00:00:41,050
Hmm, I'm not quite sold on that.
I think the very nature of 

14
00:00:41,060 --> 00:00:44,450
software development where you 
know each project has this 

15
00:00:44,460 --> 00:00:48,420
unique element, it really limits
how useful those early estimates

16
00:00:48,430 --> 00:00:50,280
can be that. 
Creates a. 

17
00:00:50,290 --> 00:00:54,480
Real fundamental tension with 
agiles whole idea of embracing 

18
00:00:54,490 --> 00:00:58,180
change and learning as you go we
have to admit that trying to 

19
00:00:58,190 --> 00:01:01,640
plan everything out in high 
detail right at the start well 

20
00:01:01,690 --> 00:01:03,400
that often just. 
Creates waste. 

21
00:01:03,590 --> 00:01:05,720
OK. 
I absolutely agree with you on 

22
00:01:05,730 --> 00:01:07,650
the uncertainty part. 
But that's. 

23
00:01:07,660 --> 00:01:10,040
Precisely why we need to shift 
our focus. 

24
00:01:10,570 --> 00:01:13,240
We're not really estimating 
completion dates in the way 

25
00:01:13,250 --> 00:01:15,550
people think we should be 
modeling risk. 

26
00:01:16,200 --> 00:01:18,880
And if you just dismiss 
estimations entirely, you miss 

27
00:01:18,890 --> 00:01:21,710
their main benefit. 
They force really important 

28
00:01:21,720 --> 00:01:23,910
discussions. 
They bring delight just how 

29
00:01:23,920 --> 00:01:27,630
unclear requirements might be. 
The sophistication isn't in 

30
00:01:27,640 --> 00:01:30,930
hitting a date, it's intriguing 
estimates as distributions. 

31
00:01:30,980 --> 00:01:34,430
You know distributions with 
variance and certainty attached.

32
00:01:34,560 --> 00:01:36,560
Like. 
X percent confidence you'll be 

33
00:01:36,570 --> 00:01:39,720
within Y percent variance. 
If we could just correct that 

34
00:01:39,730 --> 00:01:41,910
mindset. 
Lanning becomes this crucial way

35
00:01:41,920 --> 00:01:45,140
to spot high risk areas, not 
just Reddit to date. 

36
00:01:45,210 --> 00:01:50,110
That sounds, well, compelling in
theory, but the reality is the 

37
00:01:50,120 --> 00:01:54,320
cone of uncertainty kind of 
proves that even those early 

38
00:01:54,330 --> 00:01:57,860
distribution models are still 
going to be highly speculative, 

39
00:01:57,870 --> 00:01:58,880
right? 
If you. 

40
00:01:58,890 --> 00:02:02,460
Do really detailed planning way 
ahead of time and then the 

41
00:02:02,470 --> 00:02:06,420
requirements pivot, which let's 
be honest, they almost always do

42
00:02:06,610 --> 00:02:08,060
a lot of that planning effort 
just. 

43
00:02:08,070 --> 00:02:11,110
Gets thrown. 
Away the basic truth for complex

44
00:02:11,120 --> 00:02:14,350
software is that our 
understanding the requirements, 

45
00:02:14,500 --> 00:02:17,010
they constantly sharpen U as we 
learn more. 

46
00:02:17,120 --> 00:02:20,020
And that's why that sentiment, 
you know it's done when it's 

47
00:02:20,030 --> 00:02:21,930
done. 
Even if it sounds impractical 

48
00:02:21,940 --> 00:02:25,290
commercially, it's actually 
rooted in the reality of how 

49
00:02:25,300 --> 00:02:28,850
innovation happens in software. 
Look, I appreciate the 

50
00:02:28,860 --> 00:02:31,070
philosophical angle, I really 
do. 

51
00:02:31,220 --> 00:02:34,430
But it kind of ignores the 
organizational reality we all 

52
00:02:34,440 --> 00:02:37,430
live in, this idea that we can 
just operate under. 

53
00:02:37,440 --> 00:02:41,000
It's done when it's done well. 
It's simply unsustainable for 

54
00:02:41,010 --> 00:02:43,950
almost any company. 
You have finite budgets, you 

55
00:02:43,960 --> 00:02:48,160
have customer commitments, these
external constraints, fiscal and

56
00:02:48,170 --> 00:02:50,680
contractual. 
They demand some kind of 

57
00:02:50,690 --> 00:02:54,940
planning mechanism, even if the 
dev process itself stays agile. 

58
00:02:55,050 --> 00:02:58,520
So if we accept that budgets 
aren't infinite, we have to look

59
00:02:58,530 --> 00:03:01,680
for a solution that gives us 
that organizational governance 

60
00:03:01,730 --> 00:03:04,050
but keeps the development team 
agile. 

61
00:03:04,230 --> 00:03:05,650
OK. 
So if we must have those 

62
00:03:05,660 --> 00:03:08,240
guardrails, what approach can 
actually deliver that without 

63
00:03:08,250 --> 00:03:11,240
just reimposing the old rigidity
that Agile trying to get rid? 

64
00:03:11,250 --> 00:03:12,080
Of. 
Right. 

65
00:03:12,150 --> 00:03:14,340
And this. 
Is where I think a specific 

66
00:03:14,350 --> 00:03:19,100
technique comes into play. 1 
Articulated really well by Mario

67
00:03:19,110 --> 00:03:23,460
Bittencourt, the work breakdown 
structure, the WBS. 

68
00:03:23,830 --> 00:03:27,660
I believe the WBS is potentially
the key to bridging that gap 

69
00:03:27,670 --> 00:03:30,820
between governance and agile 
execution. 

70
00:03:31,560 --> 00:03:33,590
It forces you to breakdown 
Major. 

71
00:03:33,600 --> 00:03:35,870
Features. 
Hierarchically, down to a level 

72
00:03:35,880 --> 00:03:39,150
where you can actually isolate 
tangible, estimable risks. 

73
00:03:39,860 --> 00:03:43,970
ABS, when it's done right, is 
primarily an organizational 

74
00:03:43,980 --> 00:03:47,610
budgeting tool and only 
secondarily a task planning 

75
00:03:47,620 --> 00:03:49,830
tool. 
It lets you alley that variance 

76
00:03:49,840 --> 00:03:54,410
modeling we talked about to 
specific high risk pieces much 

77
00:03:54,420 --> 00:03:57,510
more accurately than just 
slapping story points on a. 

78
00:03:57,520 --> 00:04:00,380
Big feature. 
That makes sense for many fiscal

79
00:04:00,390 --> 00:04:03,050
governance, but what about the 
operational cost? 

80
00:04:03,420 --> 00:04:06,570
Isn't there a real risk that the
WBS just leads straight back to 

81
00:04:06,580 --> 00:04:09,270
the analysis paralysis Agile is 
supposed to prevent? 

82
00:04:09,970 --> 00:04:12,460
I mean, you're arguing for a 
method that ends U creating this

83
00:04:12,470 --> 00:04:14,740
super detailed list of tiny 
elements. 

84
00:04:15,110 --> 00:04:18,740
If our backlog refinement is 
already good and detailed, and 

85
00:04:18,750 --> 00:04:23,260
in a mature scrum set it really 
should be, doesn't the WBS just 

86
00:04:23,270 --> 00:04:26,680
become, well, redundant? 
It feels like organizational 

87
00:04:26,690 --> 00:04:29,560
waste duplicating planning 
effort way before you actually 

88
00:04:29,570 --> 00:04:31,460
need that level of detail for a 
Sprint. 

89
00:04:31,610 --> 00:04:36,620
Yeah, I hear that concern about 
duplication, but a WBS done 

90
00:04:36,630 --> 00:04:39,800
properly shouldn't replicate 
backlog refinement. 

91
00:04:39,870 --> 00:04:43,780
They serve different purposes. 
Backlog refinement that's about 

92
00:04:43,790 --> 00:04:47,240
tactical execution, getting 
ready for the next Sprint. 

93
00:04:47,330 --> 00:04:51,740
WBS is more strategic. 
It's about decomposition for 

94
00:04:52,090 --> 00:04:55,530
financial tracking and large 
scale scope alignment. 

95
00:04:55,590 --> 00:04:58,600
It's value is in forcing 
everyone to agree on the major 

96
00:04:58,610 --> 00:05:02,080
components and the critical path
risks tied to them. 

97
00:05:02,230 --> 00:05:05,260
And that feeds directly into 
those variance estimates we 

98
00:05:05,270 --> 00:05:10,140
discussed earlier, plus the 
process itself doing the WBS, 

99
00:05:10,330 --> 00:05:13,790
comparing outcomes to the plan. 
That's the learning mechanism. 

100
00:05:13,860 --> 00:05:16,690
That's how estimation stops 
being a guessing game and 

101
00:05:16,700 --> 00:05:19,010
becomes a structured way to 
learn and improve. 

102
00:05:19,080 --> 00:05:20,120
OA sounds like. 
We're sort. 

103
00:05:20,130 --> 00:05:23,130
Of agreeing that estimation 
isn't dead, it has a role. 

104
00:05:23,140 --> 00:05:24,970
As a. 
Tool for risk management for 

105
00:05:24,980 --> 00:05:28,350
fostering discussion Our main 
point of difference seems to be 

106
00:05:28,360 --> 00:05:32,550
on how much formal structure. 
Like a. 

107
00:05:32,560 --> 00:05:35,960
Work breakdown structure is 
needed to get that 

108
00:05:35,970 --> 00:05:39,290
organizational alignment versus 
maybe. 

109
00:05:39,300 --> 00:05:41,780
Hindering rapid development, I 
still. 

110
00:05:41,790 --> 00:05:42,900
Lean towards. 
The idea that the. 

111
00:05:42,910 --> 00:05:45,980
Overhead of building and 
maintaining a formal WBS can 

112
00:05:45,990 --> 00:05:48,940
often outweigh its benefits and 
a fast moving product 

113
00:05:48,950 --> 00:05:50,900
environment potentially slowing 
things down. 

114
00:05:51,070 --> 00:05:54,650
And I'd argue that without some 
kind of structural tool like 

115
00:05:54,690 --> 00:05:58,730
WBS, organizations just lack the
common language they need for 

116
00:05:58,740 --> 00:06:01,940
that fiscal governance and big 
picture scope negotiation. 

117
00:06:02,330 --> 00:06:05,080
It leaves the agile team 
vulnerable to budget shocks from

118
00:06:05,090 --> 00:06:07,660
outside. 
Look, neither extreme works 

119
00:06:07,670 --> 00:06:10,080
right? 
No plans at all or completely 

120
00:06:10,090 --> 00:06:12,590
rigid perfect estimates. 
That's not desirable. 

121
00:06:12,940 --> 00:06:15,790
Finding the balance requires 
pragmatism and focusing on 

122
00:06:15,800 --> 00:06:17,370
understanding that bigger 
picture. 

123
00:06:17,420 --> 00:06:20,150
Well, thank you for. 
Joining us for this discussion. 

124
00:06:20,200 --> 00:06:22,950
Yeah, thanks for listening. 
Do check the description For 

125
00:06:22,960 --> 00:06:25,150
more information. 
And just a reminder to 

126
00:06:25,160 --> 00:06:26,850
subscribe. 
For free. 

127
00:06:26,920 --> 00:06:29,090
To the Architecture Corner 
newsletter over at 

128
00:06:29,100 --> 00:06:32,050
architecturecorner.substack.com.