1
00:00:00,400 --> 00:00:04,400
The Better Business Analysis 
Institute presence, the Better 

2
00:00:04,400 --> 00:00:07,760
Business Analysis Podcast with 
Benjamin Walsh. 

3
00:00:12,240 --> 00:00:15,240
Hi, everybody, and welcome back 
to the Better Business Analysis 

4
00:00:15,240 --> 00:00:18,720
podcast with Benjamin Walsh. 
And we're going to continue on 

5
00:00:18,720 --> 00:00:22,560
our BA Bytes series today and 
we're going to be talking about 

6
00:00:22,560 --> 00:00:25,920
failure with agile. 
That's right. 

7
00:00:25,920 --> 00:00:27,480
We're going to get straight into
it now. 

8
00:00:27,920 --> 00:00:31,000
There's an article that came out
on the Register yesterday. 

9
00:00:31,000 --> 00:00:34,960
Well, I read it yesterday. 
They talked about the fact that 

10
00:00:35,000 --> 00:00:41,400
agile projects are 268% more 
likely to fail than those who do

11
00:00:41,400 --> 00:00:45,360
not use agile. 
The article suggests we need to 

12
00:00:45,360 --> 00:00:48,840
re evaluate the whole blind 
adoption of agile methodologies.

13
00:00:48,840 --> 00:00:53,440
And I couldn't agree more. 
Projects with clear requirements

14
00:00:53,440 --> 00:00:58,880
documented before development 
we're 97% more likely to 

15
00:00:58,880 --> 00:01:04,200
succeed, and that challenges the
Agile Manifesto preference for 

16
00:01:04,200 --> 00:01:07,760
working on software over 
comprehensive documentation. 

17
00:01:08,600 --> 00:01:10,760
There are a whole other stat, a 
lot of stats in there. 

18
00:01:10,760 --> 00:01:14,360
I'm not going to get to those 
straight away, but the article 

19
00:01:14,360 --> 00:01:16,800
is no surprise to me. 
And what do we do about it? 

20
00:01:17,120 --> 00:01:19,720
And then and I'm going to tell 
you what you do about it, you do

21
00:01:19,720 --> 00:01:23,200
what you should be doing today 
and that is you do upfront 

22
00:01:23,200 --> 00:01:25,600
analysis, OK? 
You need to understand your 

23
00:01:25,600 --> 00:01:29,520
people, your customers primarily
who are using your capabilities.

24
00:01:29,760 --> 00:01:32,680
Another way of saying that is 
people to the process step that 

25
00:01:32,680 --> 00:01:36,880
we do upfront before we enter 
into projects and then work on 

26
00:01:36,880 --> 00:01:39,320
our product. 
Agile has its place. 

27
00:01:39,480 --> 00:01:42,440
I am not suggesting to throw out
the baby with the baths water, 

28
00:01:42,440 --> 00:01:45,920
but agile of course was not the 
silver bullet and it never was 

29
00:01:46,200 --> 00:01:49,200
because it was talking about 
development teams and and what 

30
00:01:49,200 --> 00:01:51,760
they needed to be successful and
the fact that requirements 

31
00:01:51,760 --> 00:01:52,960
change. 
That is true. 

32
00:01:52,960 --> 00:01:56,720
There's nothing wrong with Agile
Manifesto and Scrum 

33
00:01:56,720 --> 00:02:00,280
methodologies that side of 
Agile, but it is a delivery 

34
00:02:00,280 --> 00:02:05,960
framework and it can be used 
effectively in a well oiled kind

35
00:02:05,960 --> 00:02:10,720
of scrum run agile delivery team
from their perspective, but it 

36
00:02:10,720 --> 00:02:13,160
doesn't make up for all the work
you do upfront. 

37
00:02:13,760 --> 00:02:16,640
This is where business analysis 
shines and should shine the 

38
00:02:16,640 --> 00:02:19,320
most. 
It's the upfront strategic 

39
00:02:19,320 --> 00:02:21,640
planning. 
Do you have a strategic plan? 

40
00:02:21,880 --> 00:02:23,360
Are you looking at your value 
streams? 

41
00:02:23,400 --> 00:02:26,520
Are you looking at how that maps
capabilities just like you do in

42
00:02:26,520 --> 00:02:29,360
business architecture? 
Are you looking at opportunities

43
00:02:29,360 --> 00:02:32,280
for improvement? 
Are your initiatives which are 

44
00:02:32,280 --> 00:02:35,080
your projects? 
Are they related to objectives, 

45
00:02:35,080 --> 00:02:38,760
strategic objectives, all that 
work upfront that enterprise and

46
00:02:38,760 --> 00:02:42,640
strategic analysis we call in BA
or you call business 

47
00:02:42,640 --> 00:02:45,800
architecture effectively in the 
architecture space, which are 

48
00:02:46,240 --> 00:02:49,480
very much aligned. 
They are are where you start. 

49
00:02:49,560 --> 00:02:52,520
So while you're doing this 
planning, you work out what are 

50
00:02:52,520 --> 00:02:54,920
the areas that you want to focus
on, right? 

51
00:02:55,200 --> 00:02:57,920
And what you're actually 
outputting and how this joins to

52
00:02:57,920 --> 00:03:02,280
your world today in agile 
projects is that high level 

53
00:03:02,280 --> 00:03:06,680
requirements and objectives are 
done regardless of the delivery 

54
00:03:06,680 --> 00:03:09,200
methodology in which you choose 
to use. 

55
00:03:09,440 --> 00:03:13,520
When I say choose your project, 
the project type points to which

56
00:03:13,520 --> 00:03:15,400
methodology you should use, 
right? 

57
00:03:15,600 --> 00:03:20,400
So if for example, you're moving
a server from X to from A to B, 

58
00:03:20,400 --> 00:03:23,960
because that's going to improve 
the capability which is mapping 

59
00:03:23,960 --> 00:03:29,640
to where your problem area is, 
then of course you've probably 

60
00:03:29,640 --> 00:03:32,320
done that many a time before. 
And it doesn't really make sense

61
00:03:32,320 --> 00:03:35,160
to do that in an agile way, 
agile delivery way, I mean. 

62
00:03:35,360 --> 00:03:38,600
And so therefore you can take 
some of the stand up approaches,

63
00:03:38,600 --> 00:03:41,120
but effectively you're doing a 
waterfall project where you've 

64
00:03:41,120 --> 00:03:44,920
got tight requirements moving 
from from A to B and you're 

65
00:03:44,920 --> 00:03:47,880
defining what those are. 
OK, take another example. 

66
00:03:47,920 --> 00:03:52,240
You work out that maybe there's 
an area in the value stream that

67
00:03:52,240 --> 00:03:56,760
needs improving in regards to a 
product that you produce that's 

68
00:03:56,760 --> 00:03:59,960
not delighting the customer and 
you want to make a change to the

69
00:03:59,960 --> 00:04:02,520
product. 
OK, So you look across the 

70
00:04:02,520 --> 00:04:06,320
capability maps or you know your
processes internally which link 

71
00:04:06,320 --> 00:04:09,400
to those in your business units 
and you go, OK, well, it's not a

72
00:04:09,400 --> 00:04:11,880
process issue. 
It's not actually about how the 

73
00:04:11,880 --> 00:04:14,560
business is delivering. 
It's due with the features in 

74
00:04:14,560 --> 00:04:17,079
the product, right? 
And we need to improve this 

75
00:04:17,079 --> 00:04:19,320
product. 
And we're not exactly sure 

76
00:04:19,320 --> 00:04:22,480
exactly what it is that our 
customers want us to improve, 

77
00:04:22,480 --> 00:04:24,720
but we're going to look at some 
data and then we're going to 

78
00:04:24,720 --> 00:04:27,440
test some stuff. 
That's a great example of using 

79
00:04:27,440 --> 00:04:31,160
Agile in your development site. 
But you've already worked out 

80
00:04:31,160 --> 00:04:34,920
your highest level requirements,
your scope, what value there is 

81
00:04:34,920 --> 00:04:37,880
in terms of doing the project, 
what your success measures are, 

82
00:04:38,320 --> 00:04:42,000
your stakeholders and who are 
involved before you even kick 

83
00:04:42,000 --> 00:04:44,280
that off, right? 
So if that's all done up front, 

84
00:04:44,280 --> 00:04:46,640
then you can use an Agile 
methodology to be quite 

85
00:04:46,640 --> 00:04:48,600
successful. 
And that project will most 

86
00:04:48,600 --> 00:04:50,960
likely succeed as long as you 
have a budget. 

87
00:04:51,200 --> 00:04:53,920
As long as you're running Agile 
properly, like through a Scrum 

88
00:04:53,920 --> 00:04:56,640
methodology, and you're getting 
customer feedback and your 

89
00:04:56,640 --> 00:04:59,560
measure is to improve and 
delight the customer, then you 

90
00:04:59,560 --> 00:05:01,640
can use Agile to improve that 
product. 

91
00:05:02,040 --> 00:05:04,800
That's a perfect example. 
So don't throw out the baby with

92
00:05:04,800 --> 00:05:09,440
the bathwater, but also just be 
aware that Agile is never the 

93
00:05:09,440 --> 00:05:12,080
silver bullet. 
And so as we've seen, there are 

94
00:05:12,080 --> 00:05:14,760
less agile coaches out there, 
There are less roles in that, 

95
00:05:14,960 --> 00:05:16,720
and agile is becoming a dirty 
word. 

96
00:05:16,720 --> 00:05:20,240
That's a bit of a shame. 
It should be defined as a great 

97
00:05:20,240 --> 00:05:22,920
thing to do when it comes to 
product development. 

98
00:05:23,280 --> 00:05:26,200
And we need to look across 
things that we've traditionally 

99
00:05:26,200 --> 00:05:31,000
done like proper requirements, 
regardless of methodology to 

100
00:05:31,000 --> 00:05:33,440
support projects so they don't 
fail. 

101
00:05:33,880 --> 00:05:35,960
If you want to look at 
methodologies that are quite 

102
00:05:35,960 --> 00:05:39,520
good that talk to this 
enterprise strategic analysis 

103
00:05:39,520 --> 00:05:43,040
business architecture upfront 
and look at the Agile V model, 

104
00:05:43,040 --> 00:05:46,240
which incorporates both a kind 
of a structured approach and 

105
00:05:46,240 --> 00:05:48,600
agile. 
And of course, just be open to 

106
00:05:48,600 --> 00:05:51,640
where Agile should work. 
And I would suggest strongly 

107
00:05:51,920 --> 00:05:55,360
that Agile development, which is
where it came from in the 

108
00:05:55,360 --> 00:05:59,160
manifesto, things like Scrum is 
where it's best used when 

109
00:05:59,160 --> 00:06:03,320
improving a product. 
OK, that's my BA bite for today.

110
00:06:03,560 --> 00:06:04,320
See you next time.