Hacker News new | ask | show | jobs
by westajay 5687 days ago
My town had a lot of early agile projects in the first part of the decade. The consultants only talked about the successes and not the many failures at conferences. Specifically WRT scrum and XP. I can tell you about a scrum failure that was in the 10's of millions of dollars.

I've had many negative experiences with less effective consultants using agile as a way to convince the client that they are all wrong and the only way out is more consulting guidance. In fact, I worked for some time at a consultancy where I am sure this was their business model.

There's more than one path to the finish, and "agile" sold itself out as a vapid marketing term years ago.

2 comments

Question: If you take your own comment and replace the word "Agile" with "BDUF," does it still ring true? Why? Why not??

p.s. To be clear, I know many ineffective consultants who sell a variety of snake oils, both Agile and BDUF. I'm wary of falling into the "No True Scotsman" fallacy of claiming that what they sell isn't Agile or isn't BDUF. Really, I have no evidence that there is any methodology that turns a bad consultant into a genius, or allows a great consultant to turn a bad development team into software shipping superstars. I don't claim that anything works. But then again, I don't claim that anything "doesn't work," either.

I'd be interested to hear about (1) that scrum failure in the 10's of millions of dollars, and (2) what you prefer instead of Agile.

(I'm a developer on a scrum team and really think it helps us, but I'm not dogmatic about it or anything... I'd like to hear about the other side. I'm surprised that a huge scrum failure is possible because the customer is generally shown everything at regular small intervals, so it's hard to imagine how a project could get so far off course.)

edit: grammar

I don't know about that SCRUM failure, but the original XP project was a well-documented failure:

https://secure.wikimedia.org/wikipedia/en/wiki/Chrysler_Comp...

One way to explain things is to say that teams like Agile whether it's effective or not (for some definition of effective). Another way to explain this is to say that Agile can't make you succeed, but it's the fastest and cheapest way to fail.

When I'm selling snake-oil, I prefer the latter explanation.

"Another way to explain this is to say that Agile can't make you succeed, but it's the fastest and cheapest way to fail."

Well said... That really cuts through to both the reality of Agile, and the key advantage.