« Livejournal Has Massive Usability Problems | Home | Last.fm gets it right »
Agile vs agile
By Jacob Cohen | May 25, 2007
Agile software development, with a capital A, is a collection of software processes geared towards minimizing the risk of changing requirements. Typically this is accomplished with short timelines, an emphasis on delivering something rather than large up-front design, a tendency to eschew large and lengthy meetings, and so on.
This type of software process has gained a lot of popularity in recent years, and now there are seminars, books, courses, experts, consultants, everything that essentially makes an entire industry around the Agile software process collection.
Strangely enough, the people who use and evangelize Agile software methods seem more concerned with software process than people who use non-Agile methods. They hold heated discussions on mailing lists about why certain Agile methods are better than others, and how any failed project was just doing it wrong.
I find it strange that there is so much emotional investment in something that is supposed to be the antithesis of heavyweight software development processes.
Perhaps it has something to do with the name. If you’re not using an Agile software process, maybe that implies that your software development isn’t agile. That is, it’s cumbersome, slow, and inflexible. Is this necessarily the case? I think there is a difference between being agile in your software development, and using an Agile development method.
Perhaps the reason people are hesitant to say anything bad about their experience with an Agile method has more to do with wanting to avoid seeming un-agile, than with actually believing that the software process is perfect.
I think developers should be agile in how they respond to changing requirements. However, this doesn’t require an emotional investment in the Agile software methods. If you’ve tried something and it isn’t working, try something else. Isn’t that what agile is about?
Topics: General |
May 25th, 2007 at 9:10 pm
Jacob, I’ve recently unsubscribed from some ‘agile mailing lists of all the reasons you cited. These clowns spend all their energy trying to make agile rigid. They really don’t get it and their projects do fail because they don’t “do agile” properly. They sit around abstracting the rules. For me it’s a set of abstract processes and the rules as to how to apply them are flexible!
Gah! Drives me nuts too.
Paul
June 3rd, 2007 at 12:22 pm
There’s just one thing to say, and it’s quite general:
As soon as some (usually quite loosely defined) engineering or management concept seems to gain followers, some effin suit will invent a name for it and make a business plan how to rip of other effin suits by making them send their workforce to braindead seminars and pay for braindead auditing services. And of course they’ll insist that their /precise/ way to do it is the one-and-only-one, and all the others who want to sell something similar are ridiculously silly because they just don’t “get it”. Get used to it.