Print

Integration Watch: The zealots of agile



Andrew Binstock
Email
March 1, 2009 —  (Page 1 of 3)
The agile movement has been nothing if not evangelical, even messianic, since its inception. From its founding with the publication of a manifesto (a manifesto!) to its subsequent, continual attack on the so-called waterfall model, agile and its exponents have hewn closely to the position that theirs is the one true path. And, consistent with this evangelical view, those who disagree either don’t really understand agile or are irretrievably deluded. For the deluded, only spectacular failure of their project will open their eyes.

This point of view makes dialog about agile’s strong points difficult and about its weak points impossible. It fails to acknowledge that agile projects also fail and that, prior to agility, many very large software projects came to fruition without using agile techniques. We did, after all, land a man on the moon without agile. We also routed phone calls, conducted the census, flew aircraft, made reservations, and performed many other activities that relied on large-scale software that met requirements and generated valid results—all without agile. Every major operating system in use today was written with pre-agile techniques. So before lecturing on the one true path, it’s important to acknowledge that other paths can indeed generate successful projects. There is not a single true path. There are at least two.

The agile zealot’s take on the successes of the “other” path generally runs along the lines; that’s all well and good, but the vast majority of all software development projects are failures. The presence of some notable successes does not belie the landscape littered with the detritus of dead or abandoned projects.

I am in full agreement. And in fact this argument brings me to my second gripe with agile evangelism. Agile projects fail too. The widely quoted failure rates of projects have barely dropped since the Agile Manifesto. And while the agile movement might want to lay claim to this small drop (and attribute its small size to the fact that so many projects are not agile), I would disagree.



Related Search Term(s): agile

Pages 1 2 3 


Share this link: http://sdt.bz/33300
 
Most Read  Latest News  Resources


Comments


03/09/2009 04:09:00 PM EST

Perhaps when you assault a movement, you may want to dig into the history a tad more. The Agile Manifesto appeared at least 5 years after "Extreme Programming Explained." Agile didn't start with the Manifesto. And Kent Beck is so close minded to feedback regarding XP that he wrote a second edition to Extreme Programming Explained. A second edition, by the way, that contains many improvements and additions compared to the first book. Feedback he not only accepted but sought. And the movement is so deaf to criticism that they invited Pete McBrean, author of Questioning Extreme Programing to their conferences. Giving him time on the schedule so his voice can be heard. So his anti-XP voice can be heard AT THE XP CONFERENCE. This kind of journalism wouldn't even cut it on Fox News. And by the way, defending your ignorance by claiming "those who disagree either don’t really understand agile or are irretrievably deluded." is not just bad form, it's a fallacy. And it doesn't excuse your ignorance.

United StatesCurtis Cooley


03/09/2009 06:34:47 PM EST

You said: It is easy to endlessly test and endlessly refine and refactor code to the point that it becomes an all-consuming diversion that does not advance the project. And the leading agile exponents Kent Beck, Bob Martin (especially) and others, tirelessly support this. In their writings and lecturing, THERE IS NO SENSE OF WHEN SOMETHING IS GOOD ENOUGH. ############################################################################################# In XP Explained, 2nd edition, Beck says: Software design is curious in that there are usually many designs that are GOOD ENOUGH for the software to be successful. Design quality doesn't ensure success, but design failure can ensure failure. ...[in some cases] purely instinctive design is sufficient. Any old design will do. You can go ahead and design today and be successful. ...[in some other cases]the question of when to design isn't as clear. Careful thought would lead to a GOOD ENOUGH answer, but experience would lead to a better answer. You don't have the option of not designing at all, because unconscious design will lead to failure. Should you make the bulk of your investment in design now, or wait until you have some experience? ...[in yet other cases] incremental design is inevitable. No amount of thought without experience will result in a design that is GOOD ENOUGH. Only experience will result in enough understanding to produce a GOOD ENOUGH design. One factor to take into consideration in deciding when to design is the value available through the different strategies. If pure thought creates most of the value without feedback, designing sooner makes more sense. If experience creates most of the value, designing just enough today to get going and then designing mostly in the light of experience makes more sense. Another factor in deciding when to design is the cost. If you design early, the initial cost of the design is simply the time you spend. Overall costs may be high if you make many mistakes that have to be repaired or worked around for the life of the project. The cost of designing based on experience is the time for the bare-bones initial design, which is lower than that of designing up front, plus the cost of retrofitting later design decisions into running code and live data. Many XP practices are intended to lower the cost of ongoing design. ##################################################################################### Refactoring and Testing are never all-consuming diversions that don't advance the project. They are two key practices that XP uses to lower the cost of ongoing design when it is needed.

United KingdomPhilip Schwarz


03/10/2009 10:42:55 AM EST

This whole article is mean spirited. I don't know why SDTimes would publish a piece full of personal attacks and accusing the reader of delusion for not agreeing.

United StatesStephen Rylander


03/10/2009 06:43:13 PM EST

Although I'm not a "Evangelist" for Agile I think it's pretty great and has lots of value. 1) If you are making the case that Waterfall *AND* Agile projects fail, wouldn't it be better to fail earlier (or know it isn't workable sooner) and spend less money in the process? 2) In your article you talk about software written "pre-agile" without agile techniques, but then you contradicts yourself by talking about Unit Testing (which I think the Agile movement has gotten the word out about) was Pre Agile. I'm sure other techniques that Agilists use existed "Pre-Agile" but it doesn't mean they weren't used in non "Agile" projects in the last fourty years. 3) Not really sure what the point of your rant was or how it adds value to the conversation. You say agile has value and you use it, but it seems you're edifying Joel's remarks which make it sound like a waste of time. If an activity doesn't add value, DON'T DO IT! I don't get why the strawman of bad refactoring is blamed as an Agile thing. Code could be refactored or changed in traditional development or Agile Development. Bad refactoring decisions aren't specific to a single methodology. It's like somebody saying they like a Porsche, but not a Ferrari because their friend crashed his Ferrari - maybe it's operator error at issue; not the choice of car.

United StatesGreg Ostravich


03/13/2009 04:46:08 AM EST

It's all about the people. Good teams will succeed no matter what the methodology and bad teams will fail. But that's the whole point of agile. Why invest loads of time doing a big design when it will not improve your chance of succeeding? Why have loads of methodology overhead when it doesn't pay? When people matter, set them up for success and leave them to do their jobs! The real people in any methodology to watch out for are not the zealots but the dogmatists, the people who try to enforce the rules to an extreme without understanding them. (Or in Spolsky's case the people who attack the rules without understanding them). As waterfall is bigger on rules it attracts more of them but I've seen some agile dogmatists too, although I've yet to see someone promote "endlessly testing and refactoring code" this goes against quite some agile ideas. Luckily the only place I have seen this is in the imagination of people like Joel Spolsky.

NetherlandsMendelt Siebenga


03/13/2009 01:27:02 PM EST

You brought out the XP zealots with your criticism, but that's predictable. If there's one thing that XP zealots hate it is hearing that traditional (heavyweight) methods had lots of successes before agile, and that lots of agile projects have failed. Pete McBrean's book "Questioning Extreme Programming" is a weak critique. It doesn't seriously challenge XP. It's like asking Tim Geithner to criticize Obama's stimulus plan. A more serious critique of XP can be found in "Extreme Programming Refactored: The Case Against XP" by Matt Stephens and Doug Rosenberg. Any real critique of XP needs to include the fact that the original XP project, the C3 project at Chrysler, was a failure. It's important to distinguish between criticism of agile and criticism of agile zealotry. I like agile, but I don't like the sophomoric zeal of so many agilists. Agile would benefit from a dose of healthy skepticism and less of the reactionary, thin-skinned attitudes on display in the comments here.

United StatesDean Schulze


03/13/2009 02:12:10 PM EST

This is getting interesting. Greg and Mendelt both say that one benefit of agile is that agile projects fail sooner than non-agile projects. I've not heard this claim made in favor of agile before, but maybe their point is valid. If a certain number of projects are going to fail it makes sense to have them fail sooner rather than later. Is there any evidence to show that agile projects fail sooner than non-agile projects, and therefore agile failures are less costly than non-agile failures? This is an odd way to defend agile, but it could be a valid point. As an aside I'll mention that both Greg and Mendelt confuse criticism of agile zealots with criticism of agile. They are definitely not the same thing.

United StatesDean Schulze


close
NEXT ARTICLE
Finding the right tool for the agile job
Experts emphasize that tools should bolster the agile process above all else Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
MAY 2013 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?