Slashdot Mirror
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?"
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?"
If you're doing "Agile Projects" or have "Agile Project Managers" you're not doing agile. Agile is a set of PRODUCT methodologies. If you assemble a project, identify scope, get seed funding, kick off, and then decide to delivery you're project "Agile", you've missed the key point of agile: adjust priorities in response to change.
I get why people hate "agile", it's because most people haven't done the real thing. https://www.youtube.com/watch?...
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.
Please do not read this sig. Thank you.
"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')
Where I work, Agile means 50 people sit around a conference table for an hour (at least) watching the project manager fill out a spreadsheet.
I myself keep my brain from dying during this by writing limericks and praying to ancient gods for a merciful death.