[fooqux]

> bastardizing Agile

Sensationalist headline followed by lots of examples of people doing Agile incorrectly and the author seemingly being surprised by the outcome and blaming Agile.

Garbage in, garbage out applies to all sorts of things, and processes and frameworks are certainly in that set. If you willfully ignore the principles of Agile and do "waterfall in sprints" don't be surprised when it ends up being a mess.

[the_af]

Agreed, but at some point, if nobody can follow a set of guidelines right, and projects following said guidelines tend to fail just as frequently as those which don't, could we say there is a problem with the guidelines as well?

A set of principles that nobody seems to be able to follow correctly surely has a fundamental problem?

[fooqux]

There are plenty of people who do follow it correctly, and have done so in the past. I've been on some of those projects, and I've even ran some (although I'll admit I'm biased there; the devs might tell another story). Hell, I've heard prospective devs during the hiring process say that they would have walked if we didn't use Agile. The fact that Agile became popular should attest to the fact that it can work, but with that popularity comes the people like this article mentions that just read a 1 page synopsis of an Agile framework and then try to use it with no further training.

The primary reason IMHO for why Agile fails isn't due to the principles of Agile or any of the frameworks. The reason is that Agile shifts the balance of power and gives much of it to the devs. It requires trust in the people you work with and who report to you. Many people can't seem to give power up, or they come up with excuses for why they can't trust their people and must continue to "manage" them. This sabotages the entire process.

Moving to Agile is not a process change. It's a culture change, and those are hard.

[AnimalMuppet]

I've actually been on a team that did agile well. (XP, which is a subset.) It worked just like it was supposed to...

... until an upper manager couldn't understand our progress without documents the way he was used to. He also insisted on a large increase of scope without a change of schedule. And that was that.

It wasn't that we were failing to deliver. It was that upper management couldn't handle the lack of their normal process.

It also put too much pressure on the person playing the "customer" role - perhaps because we were a very large XP team (30 people).

It worked well as long as management let it, though. We delivered some releases, with solid, maintainable code, on time.

[the_af]

But that's shows the problem, right?

If management ends up interfering, and since Agile is supposed to be "about people", and management is people, Agile seems to be just as prone to mismanagement as other practices/principles, right?

I didn't mean that within a small team it doesn't work. I think there is merit to lowercase-a agile. But if capital-A Agile -- which is supposedly all about communication* -- fails to communicate with upper management, then where does that leave us?