1
00:00:00,320 --> 00:00:03,160
The Better Business Analysis 
Institute. 

2
00:00:03,520 --> 00:00:05,880
Presence the Better Business 
Analysis podcast. 

3
00:00:05,880 --> 00:00:14,040
With Benjamin Walsh. 
Hi, everybody, and welcome back 

4
00:00:14,040 --> 00:00:17,800
to the Better Business Analysis 
podcast with your host, Benjamin

5
00:00:17,800 --> 00:00:21,160
Walsh. 
And this week we continue on our

6
00:00:21,200 --> 00:00:26,480
BA Byte series and we're diving 
into Remember Agile. 

7
00:00:27,040 --> 00:00:32,000
Yeah, about that. 
Once Upon a time, Agile was a 

8
00:00:32,000 --> 00:00:36,000
shiny new buzzword that promised
to revolutionize the way we 

9
00:00:36,000 --> 00:00:40,440
delivered projects. 
Manifestos were signed, stand 

10
00:00:40,440 --> 00:00:45,160
ups became sacred rituals, and 
teams everywhere started 

11
00:00:45,160 --> 00:00:50,400
slapping Agile onto their CVS. 
Like it was a magic wand. 

12
00:00:52,960 --> 00:00:57,760
But somehow, along the way, 
Agile went from revolutionary 

13
00:00:57,760 --> 00:01:03,520
to, well, awkward. 
Now Agile isn't dead. 

14
00:01:04,120 --> 00:01:08,680
It's just rebranded, adapted, 
and misunderstood to a point 

15
00:01:08,960 --> 00:01:12,000
where some companies are 
treating it like a dirty word. 

16
00:01:13,240 --> 00:01:17,280
So in this episode, we are going
to unpack the ghost of Agile 

17
00:01:17,280 --> 00:01:22,040
past, tackle its modern 
struggles, and most importantly,

18
00:01:22,320 --> 00:01:26,960
figure out how to breathe life 
back into this iterative an 

19
00:01:26,960 --> 00:01:32,120
adaptive workflow without 
tripping over the dogma or where

20
00:01:32,120 --> 00:01:37,240
some people have taken it. 
Spoiler alert, it's not about 

21
00:01:37,240 --> 00:01:41,040
being agile. 
It's about being smart, focused,

22
00:01:41,400 --> 00:01:45,080
and adaptive. 
Let's dive into some real tales 

23
00:01:45,520 --> 00:01:50,440
of iterative project chaos, 
where things went spectacularly 

24
00:01:50,440 --> 00:01:55,920
wrong and how small tweaks can 
bring projects and sanity. 

25
00:01:56,360 --> 00:02:00,800
Back on track. 
Chapter 1 When flexibility 

26
00:02:00,800 --> 00:02:10,039
becomes indecision, teams took 
adaptivity to mean we don't need

27
00:02:10,039 --> 00:02:15,000
to stick to the plan. 
Without clear goals, they pivot 

28
00:02:15,120 --> 00:02:19,320
endlessly, leading to missed 
timelines and frustrated 

29
00:02:19,320 --> 00:02:23,680
stakeholders. 
Even more so, they always fall 

30
00:02:23,680 --> 00:02:27,240
back onto we didn't have the 
requirements signed off yet, 

31
00:02:27,480 --> 00:02:29,480
which of course is a different 
model. 

32
00:02:31,640 --> 00:02:37,120
A mobile app project started 
with a simple Go goal, launching

33
00:02:37,120 --> 00:02:40,960
MVP three months. 
Three months later, the team 

34
00:02:41,160 --> 00:02:44,720
still hadn't agreed on what 
features were must haves versus 

35
00:02:44,720 --> 00:02:47,440
nice to haves. 
By the time they aligned, the 

36
00:02:47,440 --> 00:02:50,200
competitors had beaten them to 
the market. 

37
00:02:52,120 --> 00:02:56,400
How do we fix this? 
We define a northern star goal 

38
00:02:58,160 --> 00:03:01,000
have a clear overarching 
objective. 

39
00:03:01,080 --> 00:03:06,680
If one everyone rallies around 
like strategic objectives, which

40
00:03:06,720 --> 00:03:11,960
is also a good chance to drop 
down into the what high level 

41
00:03:11,960 --> 00:03:19,600
watts in terms of epic stories. 
This you introduce time box 

42
00:03:19,600 --> 00:03:24,000
decisions, set deadlines for 
deciding priorities during each 

43
00:03:24,000 --> 00:03:28,920
cycle to avoid endless debates. 
And this can be hard in a 

44
00:03:28,920 --> 00:03:32,680
hierarchical organization. 
So you need to get your project 

45
00:03:32,680 --> 00:03:35,520
manager, your project governance
team to agree this upfront. 

46
00:03:35,960 --> 00:03:39,600
You missed the time wiggle ago 
with the recommended option 

47
00:03:41,480 --> 00:03:45,320
build in feedback loops allow 
space to reflect and adjust. 

48
00:03:45,960 --> 00:03:48,800
Not many teams do this. 
They do not take time out. 

49
00:03:49,080 --> 00:03:52,840
They don't do a retro, they 
don't take a breath and adjust. 

50
00:03:52,840 --> 00:03:57,960
That's the whole point. 
Obviously, you need to complete 

51
00:03:57,960 --> 00:04:00,600
some planned iterations before 
you do that. 

52
00:04:00,640 --> 00:04:02,080
OK? 
It's not just about another 

53
00:04:02,080 --> 00:04:09,720
meeting. 
Chapter 2 The meeting that ate 

54
00:04:09,720 --> 00:04:17,040
the Sprint Syndrome teams began 
and became bogged down in 

55
00:04:17,040 --> 00:04:20,120
ceremonies. 
Daily stand ups turn into 30 

56
00:04:20,120 --> 00:04:22,880
minute status updates. 
Everyone talked. 

57
00:04:24,200 --> 00:04:26,320
Planning meetings stretched for 
hours. 

58
00:04:26,760 --> 00:04:31,000
Work was sacrificed on the altar
of over communication. 

59
00:04:34,160 --> 00:04:37,360
One example is a project team 
spent 12 hours a week in 

60
00:04:37,360 --> 00:04:42,400
meetings leading developers with
only half their time to actually

61
00:04:42,400 --> 00:04:43,960
code. 
The result? 

62
00:04:44,120 --> 00:04:45,960
Missed deadlines and 
frustration. 

63
00:04:47,800 --> 00:04:51,600
How do we fix this? 
Cap stand ups to 10 minutes. 

64
00:04:52,880 --> 00:04:56,560
Everyone shares only key 
blockers or wins. 

65
00:04:57,400 --> 00:04:59,200
Not what they're doing this week
or last week. 

66
00:04:59,600 --> 00:05:03,240
Who cares. 
Look on the Cambian board like 

67
00:05:03,800 --> 00:05:06,080
updates in slack or shared 
document. 

68
00:05:06,280 --> 00:05:08,880
That's where you can reference 
those. 

69
00:05:08,880 --> 00:05:13,280
Limit retros to action items. 
Focus on lessons learned and 

70
00:05:13,280 --> 00:05:14,520
action. 
More items. 

71
00:05:14,840 --> 00:05:18,040
Not about venting. 
It's not for venting that 

72
00:05:18,040 --> 00:05:22,080
creates negativity and just 
starts to destroy the team 

73
00:05:22,080 --> 00:05:28,680
culture. 
Chapter 3 Lack of unified 

74
00:05:29,640 --> 00:05:35,280
product vision. 
Teams build features without 

75
00:05:35,280 --> 00:05:38,880
understanding the bigger 
picture, leading to disjoint 

76
00:05:38,920 --> 00:05:41,520
user experiences and wasted 
effort. 

77
00:05:42,840 --> 00:05:47,760
An example, a retail company 
spent three months developing a 

78
00:05:47,760 --> 00:05:52,880
buy now, pay later feature. 
Turns out customers were asking 

79
00:05:52,880 --> 00:05:56,440
for better search filters, not 
deferred payments. 

80
00:05:57,280 --> 00:05:59,880
The feature flocked and 
resources were wasted. 

81
00:06:00,440 --> 00:06:03,600
People are now over that kind of
feature and they could have just

82
00:06:03,840 --> 00:06:06,240
integrated with an existing 
provider. 

83
00:06:07,440 --> 00:06:11,280
How do we fix this? 
Start with customer discovery. 

84
00:06:12,960 --> 00:06:16,480
Talk to users to validate what 
they really need. 

85
00:06:16,880 --> 00:06:18,720
Is it desirable? 
Is it feasible? 

86
00:06:20,040 --> 00:06:23,920
Is it viable? 
Use a lean road map. 

87
00:06:24,240 --> 00:06:28,400
Prioritize high impact features 
that align with your objectives 

88
00:06:28,760 --> 00:06:34,360
and your epics. 
And there needs to be a clear 

89
00:06:34,360 --> 00:06:38,560
connection to business goals, 
not just an arbitrary 

90
00:06:38,560 --> 00:06:40,360
connection. 
Backup. 

91
00:06:41,600 --> 00:06:45,120
Keep stakeholders alight. 
Communicate to stakeholders 

92
00:06:45,440 --> 00:06:49,280
about each feature and how it 
fits in terms of the overarching

93
00:06:49,480 --> 00:06:56,840
product vision. 
Chapter 4 Done but not 

94
00:06:56,840 --> 00:07:02,320
delivered. 
Team Smart work is done but 

95
00:07:02,320 --> 00:07:05,760
didn't ensure it was usable or 
valuable to end users. 

96
00:07:06,640 --> 00:07:11,400
Done became a technical 
milestone instead of a customer 

97
00:07:11,480 --> 00:07:19,720
focused 1. 
I know of a Financial Services 

98
00:07:19,720 --> 00:07:21,880
Act. 
They completed all the back end 

99
00:07:21,880 --> 00:07:24,480
development for a new investment
feature. 

100
00:07:26,040 --> 00:07:28,600
I actually forgot to integrate 
it with the UI. 

101
00:07:30,600 --> 00:07:32,880
Users had no idea that they had 
done that work. 

102
00:07:32,880 --> 00:07:35,800
That feature even existed 
because it wasn't generating 

103
00:07:35,800 --> 00:07:41,640
value to the UI. 
You need to redefine them. 

104
00:07:42,240 --> 00:07:46,160
It includes testing, 
integration, customer validation

105
00:07:46,240 --> 00:07:51,320
as part of the criteria. 
There's too much time spent with

106
00:07:51,320 --> 00:07:53,640
developers telling testers what 
they should test. 

107
00:07:53,840 --> 00:07:58,000
Instead of developers testing 
their own code and the testing 

108
00:07:58,000 --> 00:08:00,520
being driven by the business 
requirement. 

109
00:08:01,880 --> 00:08:04,720
Use demo days. 
Showcase completed work to 

110
00:08:04,720 --> 00:08:08,720
stakeholders and users to ensure
and meet expectations. 

111
00:08:08,720 --> 00:08:10,400
You don't have to wait for a 
retro. 

112
00:08:11,080 --> 00:08:16,400
That's where the ceremonies are 
enforced, whereas demo days may 

113
00:08:16,400 --> 00:08:19,200
just happen as and when 
required. 

114
00:08:20,360 --> 00:08:22,560
Make sure you test in small 
batches. 

115
00:08:22,600 --> 00:08:26,640
Deliver small user face facing 
increments to get feedback 

116
00:08:26,640 --> 00:08:28,280
sooner. 
That's what testing is about. 

117
00:08:28,880 --> 00:08:30,720
Technical testing is another 
story. 

118
00:08:30,800 --> 00:08:34,400
And actually, that is the area 
where AI and a lot of automation

119
00:08:34,400 --> 00:08:36,600
or even outsourcing would be a 
better option. 

120
00:08:38,559 --> 00:08:40,679
Remember, done isn't a check 
box. 

121
00:08:42,720 --> 00:08:49,520
Chapter 5 stakeholder ambushes, 
last minute stakeholder demands 

122
00:08:49,520 --> 00:08:51,760
threw off the team's focused and
planning. 

123
00:08:52,080 --> 00:08:54,240
Happens all the time. 
Where's the protective shield 

124
00:08:54,240 --> 00:08:57,680
here? 
This is one of the reasons why 

125
00:08:57,840 --> 00:08:59,800
Scrum was developed in the first
place. 

126
00:09:01,280 --> 00:09:05,640
A marketing executive insists of
adding a new promotional feature

127
00:09:05,680 --> 00:09:10,480
mid iteration, delaying delivery
of a critical bug fixes for Go 

128
00:09:10,480 --> 00:09:12,920
life. 
How do you fix this? 

129
00:09:12,920 --> 00:09:16,200
You need to set clear change 
request protocols. 

130
00:09:16,680 --> 00:09:22,880
But I thought we were doing 
agile mid flight cycle changes. 

131
00:09:23,520 --> 00:09:25,800
There needs to be a process 
wrapped around it. 

132
00:09:28,360 --> 00:09:32,240
Agile is about being agile at 
the iteration level, not within 

133
00:09:32,240 --> 00:09:36,440
the iteration level. 
Schedule regular. 

134
00:09:36,440 --> 00:09:39,640
Check insurance. 
Make sure stakeholders are aware

135
00:09:39,640 --> 00:09:42,280
of what you're working on. 
Be very clear with your plan. 

136
00:09:42,560 --> 00:09:44,080
An agile plan might not be good 
enough. 

137
00:09:45,160 --> 00:09:46,720
It's not good enough for 
stakeholders. 

138
00:09:46,720 --> 00:09:50,200
Give them a project plan, not a 
detailed one in project, but 

139
00:09:50,200 --> 00:09:53,240
tell them what you're working on
this week and help them 

140
00:09:53,240 --> 00:09:55,920
understand. 
And of course create a parking 

141
00:09:55,920 --> 00:09:59,080
lot. 
Log non critical requests for 

142
00:09:59,080 --> 00:10:02,720
future prioritization and again,
it doesn't just go on the 

143
00:10:02,720 --> 00:10:07,240
backlog and gets determined by 
the individual scrum team or 

144
00:10:07,240 --> 00:10:10,040
Sprint team or squad. 
It's actually something you're 

145
00:10:10,040 --> 00:10:12,520
going to do. 
So sometimes that doesn't work 

146
00:10:12,520 --> 00:10:18,760
very well in Agile. 
In the end, it's not about 

147
00:10:18,760 --> 00:10:22,080
remembering Agile as it was, 
it's about evolution. 

148
00:10:22,560 --> 00:10:25,600
It's about taking those 
principles that are so valid and

149
00:10:25,600 --> 00:10:30,280
fit it in today's realities. 
The ceremonies, the jargon, 

150
00:10:30,280 --> 00:10:34,360
they're just tools, but there is
some structure and diet that you

151
00:10:34,360 --> 00:10:36,920
need to understand why it's 
there. 

152
00:10:39,080 --> 00:10:42,240
What really matters is 
delivering value, staying 

153
00:10:42,240 --> 00:10:46,080
adaptive, and keeping teams 
motivated and working. 

154
00:10:46,640 --> 00:10:49,840
So next time you hear someone 
groan at the word agile, remind 

155
00:10:49,840 --> 00:10:53,280
them it's not agile that failed,
it's how we used it or abused 

156
00:10:53,280 --> 00:10:56,360
it. 
Let's fix that together.