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

FrAgile

[Anonymous Coward]

I am a software dev of many years and now a software dev manager on top of that (still do dev work). Agile has got to go. Developers think that because they're programmers, they're special and deadlines don't apply to them.

The prototypical case against waterfall is BS, by the way. Short, incremental waterfall, with requirements defined by product owners and sales, with set timeframes based on developer consensus and prior work, works extremely well.

Also, and this is THE KEY reason that I'll never accept agile: if your requirements change that often, while there are some businesses where they do, YOU HAVE NO PRODUCT VISION OR PLAN. YOU DON'T JUST RUN A BUSINESS SUCCESSFULLY BY THROWING SHIT AT THE WALL AND SEEING WHAT STICKS. Sometimes that works, but it's less often than not.

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.

Half agree

[raymorris]

I absolutely agree that the Agile theory that you don't find out the requirements before you begin work is stupid. Over the medium to long term, without a plan you end up either doing work and then throwing it out three months later, or constantly working around earlier decisions, ending up with a system full of duct tape hacks. That creates unreliable systems that are difficult and expensive to maintain.

Artificial deadlines are just as problematic, however. Properly designing and building a system with certain requirements requires a certain amount of time. That can't be changed by management fiat. Regularly attempting to complete projects in less than the required time can only result in one of these three results:

A) Projects are frequently not completed on time.

B) Shortcuts are used regularly, duct tape that makes the next project take longer, while compromising reliability and security.

C) Workers are frequently asked to work long hours, resulting in turnover as well as the same problematic shortcuts as b).

Once in a while, there is an externally imposed deadline - taxes have to be filed by April 15. In such cases, you can either limit the scope and only do as much as you have time
to do, or choose from the three failure modes above.

Pretending otherwise may appear to work for a while - the product is delivered. However, by shorting time, the work was necesarily shorted - testing wasn't done, code was copy-pasted from Stackoverflow without understanding what it actually did, or perhaps to make deadline the programmers used code you have no license to use. These things will come back to bite you.

The way to quality software, reliable software that can be maintained with reasonable manpower, is to recognize that it takes as long as it takes. You can rush it no more than you can rush the growing of crops. Is this inconvenient for management? Absolutely! And the job of management is to figure out how to get the best possible results from real world, non-optimal conditions.

  In fact, software development management requires talent because not only can you not dictate how long it will take to achieve a predetermined set of requirements, you can't even reliably predict it! Development is a process in which most of the work moves along at a steady pace, but the trouble spots can take unpredictable amounts of time. Yeah, that makes it hard for management. That's why management is paid five times as much as production - because they have the skills to deal with uncertainty on a significant scale.