Julio Santos

I used to say that the main problem with Extreme Programing was its name, especially the “Extreme” part, which doesn’t feel professional enough. No longer do I feel that way.

This is still just a theory, based on my observations and seeing both small and large, very large, companies going from “no formal process” or “big heavy process” to “we need to adopt agile process X”.

Ever since I came across Kent Beck’s white book in 1999, Extreme Programming Explained, I’ve called myself an “agilist”.

I’ve championed, trained, led, explained, evangelized, read, blogged, and of course practiced Agile Methods ever since. Enough to become a go-to guy when it comes to no-nonsense project management practices. Yes, despite all the literature, there’s still a lot of nonsense going on.

I started noticing something strange a few years ago. Teams who insist in adopting agile, sometimes they do it wrong in an obvious way. I mean, I understand doing it wrong if you’re forced to do something, but if it’s your decision, why would you mess it up on purpose?

For example, they would say “I’m doing the same as before, expect I’m no longer designing anything, that’s XP right?”, or “Agilists say that good clear code doesn’t need comments, so I’m removing all the comments from my code” or still “I don’t need to worry about being responsible for my code, because now we practice Collective Ownership”.

These are all terrible misconceptions, and I help correct them as soon as I see them. But why do they happen at all? After all, the reason I liked Agile practices so much, it’s because they make so much sense while being so simple. They’re just, well, obvious.

Teams adopting agile practices tend to have people who fall roughly in three categories:

- Agile is a much better way, and I can’t believe I never thought of this before (I’m there)
- I’ve been programming all my life, and I don’t need no stinking agile practices (smart people with the most experience are the worst offenders and I have a theory why, that I’m saving for a different time)
- I like Agile if it’s hot and I can put it on my résumé or it can help me sell if I mention it.

This last category is the one I’m talking about.

I’m now seeing companies, who tend to be slow to adopt new things, starting to push for no-nonsene ways. At first this seems like great news. If agile becomes so mainstream that it’s featured on People Magazine and everyone is getting on board, it can only be good for Software Development as a whole. I’m not complaining.

Where I start complaining is when these companies, at the same time push for agility, but also encourage lip service. Why would a company, for example, insist on iterative development with short iterations, and at the same time, insist that the scope of the project to be fully defined, 100% clarified, before implementation starts. It could be confusion or misconception of what agile is, but I don’t think so.

Well, misunderstanding could be true at first, but if they persist after clarification, you know something else is up. Marketing seems to it.

There’s a push in the industry for agile methods, and companies don’t want to do what they would if a project was a car, they don’t want to slow down while taking a turn (to use one of Ron Jeffries analogies). Instead some companies decide to do whatever they were doing before, and then rebrand it with new, fresh terms. It’s as if the important thing is to be able to slap a “Built with Agile Practices” sticker on the box when the product ships.

This is bad for several reasons. In the short term it’s not helping the company go faster and improve quality. It might help sell a little bit more, but eventually reality will come back and bite them.

More importantly even, is that it dilutes and corrupts what it means to use agile practices. We will no longer be able to point at projects using agile software development, and use that as a reason for their success. Instead, all these projects, failed and otherwise, will have the “Built with Agility” sticker on the box.

Given that apparently agility is not that easy to grasp, especially if you’ve been in the industry for a long time, why else would people sign up for a ScrumMaster program for example? It’s supposed to bring you from “I have no idea what agility is” to “I’m a master” in just two days. Why would this even be possible? Is it because:

- Companies are sending their people to 2-day ScrumMaster classes, so the company can justify those “built with agile” stickers.
- Individuals are doing it themselves, so they can put it on their résumés.

And this is the trouble with successful software methodolgies (or anything successful for that matter). It gets hijacked by people who are more interested in the packaging than in the content. If buyers like X, because X has been known for doing good things, let’s skip the step where we actually use X, and jump straight to the part where we *say* we use X.

With dubious ScrumMaster and RUP Certifications being commonplace now, it may be time to start thinking about the next “Real No BS Agile Methdology”. This new technique should have a name that companies won’t like to advertise on their boxes, even if they still want to use it because it helps them (in a real way).

Extreme Programming didn’t go far enough. Certainly the word “Extreme” was and still is, hard to swallow for many, but not enough.

Just to be on the safe side, the next methodology should be called something like “Loser Practices” or “Stinking Programming” or even “No Bullshit Software Development”. Maybe that will help companies focus more on what these practices can do for their projects, and less on what pretending to use it, can do to sales.