Playing Politics With Agile Projects (cio.com)

A harsh perspective on agile software development, shared by Slashdot reader itwbennett: Politicians would be utter failures as agile project managers, writes David Taber, and for all the reasons you might imagine, but mainly because they wantonly make promises they have no hope or thought of keeping. But then he gets into the political attributes successful project managers need. And that's where things get interesting because, while he points out that agile was 'conceived of as a way of bypassing bureaucracy and internal politics,' the attributes he says are required for success are pretty much the worst of the political behavior we've all witnessed in our organizations.

For example, "A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture. Agile should inherently involve frequent 1:1 contact with users: use that time to lower expectations! Without this habit, the inevitable scope creep and the impulse to believe "of course the system will do X for me" will get you."
His submission ends with this question. "Is it any wonder why users hate agile?"

Comments

The problem with agile is "proof it works."

[gestalt_n_pepper]

I don't think it's bad, exactly. I've worked in a shop that has been using agile for about 5 years now. Before agile, we had good releases and bad releases. After agile, we have had good releases and bad releases. I certainly *like* aspects of it, like daily meetings, limited goals, being two weeks from something shippable, etc. But my *liking* it is different from being able to prove, quantitatively, that it's much better or worse than any other software development method.

Re:MAKE UP YOUR MINDS

[david.emery]

"Agile" is -whatever you want it to be-, and that's part of my problem with it. There's no real normative definition that can be used to distinguish 'agile' from 'not-agile.' And whenever you push back at 'agile' asserting it is not meeting its promises, you get told "you're doing it wrong."

So at the end of the day, "agile" means not having to do anything you don't want to do (see 'technical debt')
 

Re:FrAgile

[HornWumpus]

Waterfall doesn't have analysis and planning phases?

You're just wrong, waterfall handles 'honestly new' just fine. Virtually every piece of software used was built with waterfall.

What it doesn't handle is 'constantly shifting demands', but agile doesn't handle that at all well either, nothing does. If the customer doesn't understand the problem, you have an analysis problem, no methodology will solve it.

If the problem changes faster than you can release, the best move is not to automate that part until it settles down.

Agile is just waterfall with all the roles and phases renamed and with a fixed, very rapid, iteration cycle.

Re:FrAgile

[sjames]

It's all iteration. Waterfall is a special case where the iteration count is one. Agile is a special case where the iterations are arbitrarily short. In some of the most successful projects, the length of an iteration is determined informally in the planning phase based on logical stopping points. The rest is largely window dressing based on the principle that all teams and all programmers are exactly alike.

Managers (especially the MBAs that have never programmed) tend to like waterfall and Agile because it lets them stick to hard fast rules. Managers that came up through the ranks and kept current will be more open to variable iteration.