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.