Steve Yegge’s piece continues to bother me (see my previous post)…

I’ve been sorely tempted to write some long essay rebutting Steve’s piece, but I don’t have that kind of time available (I’m censoring out the “snippy” thing I was going to say here).  Instead, here’s some quick thoughts that came to me while stewing over the whole issue.  Who knows, maybe sometime in the future I’ll edit the whole mess together and create that essay after all.  That seems to work for Joel Spolsky .

The first thing that occurred to me was that there really isn’t an “Agile Methodology”.  I know this term gets thrown around a lot now; I’ve done it myself.  I think that the term “Agile Development” is probably more accurate.  I’m working on changing my own vocabulary to use this term.  Methodologies do, in fact, scream “consultant” or “evangelist”.  I understand Steve’s objection to this:  it’s the tail wagging the dog.  It should be all about “what people do”, not “what people define”.

Given that there’s no “magic formula” for “doing Agile”, how do you do it?  Lets say your boss comes up to you one day and says “I’ve been reading a lot about this Agile stuff.  I think all of our projects should do this from now on”. What do you do?  Just how do you know you’re “doing Agile”?

Here’s my recommendations:

1. Read.  Start with “Practices of an Agile Developer” (ISBN 097451408X).  Then, try “Agile Software Development, Principles, Patterns, and Practices ” (ISBN 0135974445) or “Agile Principles, Patterns, and Practices in C#” (ISBN 0131857258), depending on your language preference.
2. Then, read some more.  Read the Agile Manifesto.  This is the fundamental philosophy of agile development.
3. Get a “process person”.  Either hire a contract “mentor” or bring someone in who knows how to do Agile Development.  If you bring a contractor in, top priority should be to train an in-house person to take over once they’re trained.

The bottom line is that Agile Development is not a silver bullet that allows a company to take relatively inexperienced developers and have them produce high quality work as if they had years of experience.  Instead, its an approach to software development that results in high quality software produced on time and under budget.

10/4/2006 11:30:21 AM (Pacific Daylight Time, UTC-07:00)      Comments [0]  development