It's coming, as we all knew it would.

All in all, I think this is a bit of a shame. I'm not one to speak for others, but I'm sure the "originators" (for want of a better term) of agile processes like Scrum and XP are a little disconcerted to see their ideas turned into nothing more than fodder for technical books and recruitment checklists. (I could be horribly wrong about this. I know there are some people who think this was the entire point from the beginning, but I'm not that cynical yet).

The thing that turns so many people off is the steady evolution of the word "agile" into its sexier buzzword connotation of "Agile." These days, everything is fucking Agile this, Agile that. Let's not be distracted by the buzzword... Instead, try to remember the point of it all, and realize that these are just solutions to problems developers have had since the beginning of time.

One of the most stressful parts of being a developer has to be deployment. And especially re-deployment. We want our stuff to work, and we want the people who use our software to be happy with it. I used to absolutely dread uploading changes to an existing site because I was never confident I hadn't introduced new bugs into the code base. Having unit tests solved that for me, personally. I am now pretty sure my code hasn't regressed because of my adoption of this one practice. I happen to enjoy writing my tests first, before I write the code to make them pass, but that's a personal choice and it doesn't detract from the main purpose; being confident in my code. At the very least I'm less stressed out, which is a good thing.

I've worked places before where the developers didn't talk to one another. Stuff would get duplicated needlessly, and developers would go for days down paths that others had previously trodden. Having daily standup meetings where each developer goes over what they worked on yesterday, what they'll be working on today, and what's impeding there progress goes miles towards solving this. I'm not saying that this is the only solution, but it is a good, simple one.

Why does it suck so much when Uber-Developer A goes on holidays for a few weeks? Is it because they're the only one working on a project (or a sizable chunk thereof) and if anything goes wrong while they're gone everyone else is screwed? Why do some developers get so damned smart so fast, while others wallow in mediocrity alone in their offices for months? Is it because Mediocre-Developer B is useless? Try spreading the love around by pair-programming for a while. You don't have to be religious about it, but I've found that having at least some time together with another developer can go a long way towards alleviating the above problems.

How does our code get into a state whereby it becomes extremely hard to add new features? Why do we need 5 lines of comments to explain what a function does? It sure would be nice if we could just look at it for a few seconds to let the understanding sink in. By ruthlessly refactoring our code before it reaches this state we can fight the entropy. It also helps if our unit test suite can be run afterwards to make sure we didn't change the meaning of the code.

The bottom line, and the point I'm trying to make, is that the little bits and pieces that make up "Agile" processes are there to solve very real problems that we as developers have. In the end, it doesn't really matter how these problems are solved or what we call our processes. The purpose is to make our lives as developers easier. The whole point of being agile is to be able to react to change without fearing it.