Reply to: Agile project failure rate

[NickFitz]

Interesting find Nick - a great example of how they take a simple concept (appropriate unit testing) and making it sound revolutionary and exciting.
I always did like the "Worstward Ho" quote though.

I have found the quote now, and it is in fact "TerminationCanBeSuccess" (on page 103, in case you find yourself in a bookshop soon).

Ah yes, that phrase ultimately leads to EarlyCancellationIsSuccess on the wiki.

To be honest I've never been fully convinced by the XP thing, although admittedly I haven't worked on an XP project.

I have worked on projects where agile (Scrum, to be precise) is done correctly, though (in fact I'm working on one now) and it definitely can be successful.

[thunderlizard]

FailSuccessfully

Interesting find Nick - a great example of how they take a simple concept (appropriate unit testing) and making it sound revolutionary and exciting.
I always did like the "Worstward Ho" quote though.

I have found the quote now, and it is in fact "TerminationCanBeSuccess" (on page 103, in case you find yourself in a bookshop soon).

[NickFitz]

Seem to remember one of the XP supremos saying "FailureIsSuccess", probably in Extreme Programming Refactored which is a very readable book.

I haven't read that book, but I would have expected such a phrase to appear on Ward's Wiki. The nearest to it is "Fail Successfully", which merely explains the importance of ensuring that a unit test is actually testing for the same failure trigger(s) as are in fact present in the failing application - nothing to do with process or methodology whatsoever.

Oh, and what BI said

[thunderlizard]

Oh they fail by my definition of "failure" right enough!

[BrowneIssue]

I need to fine some evidence of Agile projects failure rates. Google has given a long list on reasons Agile projects fail, but not any failure rates.

That is because such research, although done, does not provide helpful results. It is not the methodology that causes project failure. It is weak management.

It is not the programming language, the platform, the size, the scale, the mix of cultures, or whether it is bleeding edge technology. It is not whether it is public sector or private sector.

The recurring consistent theme in all those "why projects fail" lists are failures of project governance at a senior level and failures of day-to-day project management.

Agile projects fail most often due to management interference. One of the main thrusts of agile is to remove the main cause of project failure: management, from the loop. If they get their oar back in then the project is doomed, in fact I'd term it an anti-pattern.

No, I disagree. Someone has to raise the business case, get the funding, build the team, arrange training / kit / desk space / telephones, ensure standards are adhered to, deal with HR, listen to & resolve the team members' problems, ensure the business participates and protect the team from the vagaries of senior management who want to keep changing the direction.

You cannot just put a bunch of people in a room with a load of kit and say "here's £2m, I'll be back in two years to see what you've got".

It problem is not management, it is poor management. The developers need someone to stand between them and the external forces that want to hijack the team for their own political ends. And if you think "the team can do that for themselves" then the team member doing it is doing management.

Nothing wrong with agile methodology. The problem is that people who don't want to follow any process at all tend to invoke Agile as a get out clause for their shoddy work procedures, i.e. we don't need documentation we are working in an agile environment...

In an environment with poor management that do no understand and support a RAD method, it is a skiver's charter.

Developers like these methodolgies because you can start laying down (often tulip) code from Day One rather than 'wasting time' actually finding out what's required.

Unsupervised developers who have no decent project management taking an interest in the day-to-day progress and overall business outcome...

... a project using Rational Rose and the guy running it didn't really have a clue... a simple system overcomplicated so fast. Needless to say the project got canned...

Note: the guy running it was the problem, not the methodology.

So while it may work if the people driving it have the skill, I find it an absolute pain in the arse. Same with many other overcomplicated ways of developing code. Much prefer to keep it simple. Usually that way it's easier to develop, maintain, support, and faster too.

Agreed. However, once the detail of a large project achieves that point where one person can no longer hold it all in their head, having properly used a methodology from Day One will help ensure everything keeps on track. Having no methodology in place at this point will virtually guarantee failure. The purpose of a methodology is to provide the tools and means to be able to drill down to manageable sized chunks of work whilst being able to oversee everything at once. I.e., the methodology is a project management tool and NOT a developers tool. <--- read that last sentence again and think about it.

Agile is a project management tool. Without good quality project management, Agile - just like every other method - becomes increasingly likely to fail.

Small teams of commited, compitent developers should be able to achieve all they need to without all this added bloat. I reckon this type of tulip is the main reason large projects fail so spectacularly.

What about major projects? The 200-strong, £100m projects? For example, the government announces a new agency or the merger of two ministries? Or a plc buys another plc? Or HugeCo wants to launch a completely new web service? These kinds of immensely high risk, high value changes cannot be entrusted to "The I.T. Crowd" - that's just not going to happen in the real world.

Strict governance, formal standards, rigid methodology application and close day-to-day project management are essential to contain risk and scope-creep. What the methodology is, does not matter. Sadly, those things often do not happen properly either.

But we all know why the vast majority of projects fail: it's because the vast majority of people are no bloody good at their jobs.

Sorry, NickFitz, I disagree slightly.

The vast majority of projects fail because the vast majority of senior management and project management are no bloody good at their jobs.

With good governance from properly trained overseers, a focussed, determined and sufficiently senior project sponsor and an experienced, trained, professional project manager responsible for the day-to-day management of the project, the main risks of project failure are eliminated. The methodology in place is immaterial.


P.S. Originally Posted by thunderlizard Full-on XP projects in particular cannot fail
I'd like to see your definition of 'fail'!

[NickFitz]

Seem to remember one of the XP supremos saying "FailureIsSuccess", probably in Extreme Programming Refactored which is a very readable book.

Full-on XP projects in particular cannot fail, because they remove such niceties as defined deliverables and deadlines ("Schedule is the customer's problem" after all...). They just reach a point where the customer stops putting money into the project: maybe because they're happy, maybe because they're irate, but the effect's the same for the XP team.

The XP mob, though very talented and frequently correct, seem to suffer from the problem of zealotry. As with all forms of zealotry, it becomes necessary to sift the wheat from the chaff. It's also worth noting that, although XP is usually associated with Agile, it's not necessary to adopt XP to follow an Agile process, nor is it necessary to be Agile when using XP (although I would imagine it helps).

In fact, let's cut through the crap by removing the capitalisation of "Agile": agile is an attitude, not a methodology. Pretty much any methodology can be followed in an agile manner. The crucial thing about being agile is that, at any and every stage, the immediate requirements that will bring the project closer to a successful implementation override the dictats of the process.

And no, that isn't the same thing as "making it up as you go along" - if more people understood the distinction, there'd be fewer people believing that that's what "agile" means.

Why am I posting about this stuff at this time on a Friday night? Jeez, what a geek... and I don't even do project management... I develop stuff... that's what I do...

[thunderlizard]

Seem to remember one of the XP supremos saying "FailureIsSuccess", probably in Extreme Programming Refactored which is a very readable book.


Full-on XP projects in particular cannot fail, because they remove such niceties as defined deliverables and deadlines ("Schedule is the customer's problem" after all...). They just reach a point where the customer stops putting money into the project: maybe because they're happy, maybe because they're irate, but the effect's the same for the XP team.

[NickFitz]

How many different ways can you find of saying the same thing (design, document, develop, test, deploy) whilst adding another layer of confusion in the process?

Exactly what Agile is intended to avoid.

All carp I'm afraid, managers love it, developers hate it. Small teams of commited, compitent developers should be able to achieve all they need to without all this added bloat.

Exactly what Agile is intended to enable.

As has been said repeatedly in the various Agile-related threads over the past week or two, the vast majority of so-called Agile projects are either Make-It-Up-As-You-Go-Along, or Waterfall-With-Standup-Meetings-And-Backlog-Spreadsheets.

If Agile is used properly then it works well. If it's used badly it fails. The only problem with finding stats concerning the matter is that nobody's going to report that "We were too stupid to follow Agile properly so the project failed", "We followed an Agile approach but failed because the team is made up largely of incompetents", or "We just dicked about and burnt the entire budget because we thought Agile was an excuse to be lazy". Instead they'll report that "We failed because of following an Agile process".

But we all know why the vast majority of projects fail: it's because the vast majority of people are no bloody good at their jobs. Unless you're sure of your team's competence, follow whichever methodology you want: you can blame your project's failure on any of them.

[PAH]

Methodologies? Don't make me larf.

How many different ways can you find of saying the same thing (design, document, develop, test, deploy) whilst adding another layer of confusion in the process?

All carp I'm afraid, managers love it, developers hate it. Small teams of commited, compitent developers should be able to achieve all they need to without all this added bloat.

I reckon this type of tulip is the main reason large projects fail so spectacularly.

I think both myself, and Atw would agree with you. Shame I can't think of a SKA to concentrate all my talent and effort on, without worrying about how to pay the bills. Maybe next year.

[Shimano105]

Methodologies? Don't make me larf.

How many different ways can you find of saying the same thing (design, document, develop, test, deploy) whilst adding another layer of confusion in the process?

All crap I'm afraid, managers love it, developers hate it. Small teams of commited, compitent developers should be able to achieve all they need to without all this added bloat.

I reckon this type of tulip is the main reason large projects fail so spectacularly.

[someone has my name]

Not got a lot of time... so I will keep it short...
AGILE== a pile of brown runny nut infested poo..

[PAH]

I avoid any job adverts where full-cycle is mentioned, or any such frameworks or methodologies.

My only exposure was on a project using Rational Rose and the guy running it didn't really have a clue. He kept getting some professional in to give him pointers and training.

Never seen what should have been such a simple system overcomplicated so fast. Needless to say the project got canned because it proved unsupportable and they couldn't iron out a few major flaws.

So while it may work if the people driving it have the skill, I find it an absolute pain in the arse. Same with many other overcomplicated ways of developing code. Much prefer to keep it simple. Usually that way it's easier to develop, maintain, support, and faster too.

[Lucifer Box]

It is the only metric I have!!

Lots of talk about good and bad in the tinterweb, but alas, no stats. It is sadly stats that makes management tick, meaning that they will not want agile anyway....

From my experience, it's probably not far off the mark.

[Wilmslow]

There you go, 50%.

If it's good enough for the Daily Mail...

It is the only metric I have!!

Lots of talk about good and bad in the tinterweb, but alas, no stats. It is sadly stats that makes management tick, meaning that they will not want agile anyway....

[Lucifer Box]

I need to fine some evidence of Agile projects failure rates.

I have worked on two agile projects - one a complete success, the other failed spectacularly.

There you go, 50%.

If it's good enough for the Daily Mail...