Thursday, September 28, 2006
« Update on the CSLA .NET training | Main | If not Agile, then what? »

A colleague of mine (customer of Magenic) forwarded me a link to Steve Yegge's wonderful blog post about Agile methodologies (good and bad).

I think my favorite bit in the whole thing (and there are a lot of good bits!) is this:

Bad Agile seems for some reason to be embraced by early risers. I think there's some mystical relationship between the personality traits of "wakes up before dawn", "likes static typing but not type inference", "is organized to the point of being anal", "likes team meetings", and "likes Bad Agile". I'm not quite sure what it is, but I see it a lot.

Like Steve, I am not a morning person, and this probably explains my general antipathy towards Agile Methodologies.

This antipathy is something I've struggled with at length.

I am a strong believer in responsibility-driven, behavioral, CRC OO design - and that is very compatible with the concepts of Agile. So how can I believe so firmly in organic OO design, and yet find Agile/XP/SCRUM to be so...wrong...?

I think it is because the idea of taking a set of practices developed by very high-functioning people, and cramming them into a Methodology (notice the capital M!), virtually guarantees mediocrity. That, and some of the Agile practices really are just plain silly in many contexts.

Rigorous unit testing? Slam dunk!
Writing the tests before writing your code? Totally optional.

Pair programming for intense, multi-threaded framework code? Absolutely!
Pair programming to retrieve a DataSet using ADO.NET? Yeah right…

See that’s the thing. Formalize a set of practices into a Methodology and the practices lose their meaning. Each practice in Agile really is good – in a specific place and for a specific purpose. But when wrapped in a Methodology they become “good at all times and in all places” – at least to most practitioners.

This isn’t Agile’s fault by the way. I’m not entirely convinced that Waterfall Methodology isn’t rooted in a set of perfectly good practices, which were subverted and corrupted by becoming a Methodology.

Nah, on second though Waterfall really is just plain bad.

Thursday, September 28, 2006 5:56:33 PM (Central Standard Time, UTC-06:00)
I saw the post too.

The comparison of Agile (note the capitalization) to Scientology he makes is a darn good one. Which is too bad - because there is a great deal of "baby" in that bathwater.

You were out in front on this one - being an Agile skeptic - and should be commended for that. Seems the post might become something of a tipping point.
Aaron Erickson
Thursday, September 28, 2006 9:02:16 PM (Central Standard Time, UTC-06:00)
This appears to be a situation that I tend to take people to task on. It seems like you are slamming Agile as well as Waterfall (which is your right), but without providing or recommending an alternative, it's just b!tch!ing (if I am wrong about this, please clarify so I am under proper understanding). What would YOU recommend that has Agile and Waterfall beat? RUP? MSF? Some hybid?
JH
Friday, September 29, 2006 12:14:04 AM (Central Standard Time, UTC-06:00)
When a project gets so big that you need more than one team to get it done and the bosses of the teams have goals that are not 100% aligned, "agile" is dead because the organization isn't. The reality of the overwhelming majority of the corporate world is: Just that. Agile method within teams: Sure. Across teams: hard to impossible. "Think, Specify, AGREE, Build" sounds like the evil waterfall, but it turns out that the AGREE is really important.

Clemens
Clemens Vasters
Saturday, September 30, 2006 2:29:08 AM (Central Standard Time, UTC-06:00)
> What would YOU recommend that has Agile and Waterfall beat?

Nothing.

You don't need a methodology. You need to THINK about your situation and use the methods that are right IN THAT SITUATION. A methodology is just an excuse to stop thinking about what you are doing; it tries to replace the need for critical reasoning skills with "the rules". And when you dogmatically follow any set of rules, you are bound to lose.
Tuesday, October 03, 2006 9:39:13 PM (Central Standard Time, UTC-06:00)
Science itself has no mehtod to speak of. Just some guiding principles.

Yet it still works.
Paul Linville
Thursday, October 05, 2006 1:16:50 PM (Central Standard Time, UTC-06:00)
I agree that any methodology should not be followed dogmatically. To me, the problem is when methodologies are used as hard rules which then are used blindly without understanding why the rules were there in the first place and what the "spirit" of the rules are.

However, dismissing methodologies altogether is missing the point. Methodologies are not there as an excuse to stop thinking. It's there to give a template on how to proceed with what you are doing. It helps in breaking down a complex problem into more manageable chunks (whether it be chunks of time, or tasks) so that the team can then proceed with what you are trying to do in the first place, which is to solve a problem. To say that you can proceed by just thinking about YOUR situation and use the methods are right in that situation is assuming that YOU know enough about everything and anything.

BTW, there Science has a method. It's called the Scientific Method. I found this in wikipedia: http://en.wikipedia.org/wiki/Scientific_method.

You can call it guiding principles but to me, it's still a set of "rules" that needs to be used according to the situation.
Joen Moreno
Comments are closed.