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 Benjamin Walsh. And we're going to continue on
our BA Bytes series today and we're going to be talking about
failure with agile. That's right.
We're going to get straight into it now.
There's an article that came out on the Register yesterday.
Well, I read it yesterday. They talked about the fact that
agile projects are 268% more likely to fail than those who do
not use agile. The article suggests we need to
re evaluate the whole blind adoption of agile methodologies.
And I couldn't agree more. Projects with clear requirements
documented before development we're 97% more likely to
succeed, and that challenges the Agile Manifesto preference for
working on software over comprehensive documentation.
There are a whole other stat, a lot of stats in there.
I'm not going to get to those straight away, but the article
is no surprise to me. And what do we do about it?
And then and I'm going to tell you what you do about it, you do
what you should be doing today and that is you do upfront
analysis, OK? You need to understand your
people, your customers primarily who are using your capabilities.
Another way of saying that is people to the process step that
we do upfront before we enter into projects and then work on
our product. Agile has its place.
I am not suggesting to throw out the baby with the baths water,
but agile of course was not the silver bullet and it never was
because it was talking about development teams and and what
they needed to be successful and the fact that requirements
change. That is true.
There's nothing wrong with Agile Manifesto and Scrum
methodologies that side of Agile, but it is a delivery
framework and it can be used effectively in a well oiled kind
of scrum run agile delivery team from their perspective, but it
doesn't make up for all the work you do upfront.
This is where business analysis shines and should shine the
most. It's the upfront strategic
planning. Do you have a strategic plan?
Are you looking at your value streams?
Are you looking at how that maps capabilities just like you do in
business architecture? Are you looking at opportunities
for improvement? Are your initiatives which are
your projects? Are they related to objectives,
strategic objectives, all that work upfront that enterprise and
strategic analysis we call in BA or you call business
architecture effectively in the architecture space, which are
very much aligned. They are are where you start.
So while you're doing this planning, you work out what are
the areas that you want to focus on, right?
And what you're actually outputting and how this joins to
your world today in agile projects is that high level
requirements and objectives are done regardless of the delivery
methodology in which you choose to use.
When I say choose your project, the project type points to which
methodology you should use, right?
So if for example, you're moving a server from X to from A to B,
because that's going to improve the capability which is mapping
to where your problem area is, then of course you've probably
done that many a time before. And it doesn't really make sense
to do that in an agile way, agile delivery way, I mean.
And so therefore you can take some of the stand up approaches,
but effectively you're doing a waterfall project where you've
got tight requirements moving from from A to B and you're
defining what those are. OK, take another example.
You work out that maybe there's an area in the value stream that
needs improving in regards to a product that you produce that's
not delighting the customer and you want to make a change to the
product. OK, So you look across the
capability maps or you know your processes internally which link
to those in your business units and you go, OK, well, it's not a
process issue. It's not actually about how the
business is delivering. It's due with the features in
the product, right? And we need to improve this
product. And we're not exactly sure
exactly what it is that our customers want us to improve,
but we're going to look at some data and then we're going to
test some stuff. That's a great example of using
Agile in your development site. But you've already worked out
your highest level requirements, your scope, what value there is
in terms of doing the project, what your success measures are,
your stakeholders and who are involved before you even kick
that off, right? So if that's all done up front,
then you can use an Agile methodology to be quite
successful. And that project will most
likely succeed as long as you have a budget.
As long as you're running Agile properly, like through a Scrum
methodology, and you're getting customer feedback and your
measure is to improve and delight the customer, then you
can use Agile to improve that product.
That's a perfect example. So don't throw out the baby with
the bathwater, but also just be aware that Agile is never the
silver bullet. And so as we've seen, there are
less agile coaches out there, There are less roles in that,
and agile is becoming a dirty word.
That's a bit of a shame. It should be defined as a great
thing to do when it comes to product development.
And we need to look across things that we've traditionally
done like proper requirements, regardless of methodology to
support projects so they don't fail.
If you want to look at methodologies that are quite
good that talk to this enterprise strategic analysis
business architecture upfront and look at the Agile V model,
which incorporates both a kind of a structured approach and
agile. And of course, just be open to
where Agile should work. And I would suggest strongly
that Agile development, which is where it came from in the
manifesto, things like Scrum is where it's best used when
improving a product. OK, that's my BA bite for today.
See you next time.