A Critique on Agile

I'm almost certainly a partidary (is that a word?) of Agile Methods.

But since this is a blog about rants, I'm going to criticize, hopefully with reasonable arguments, the ideas behind agilism.

I find most troublesome that both Scrum and XP require sprints (or iterations) to not change and not accept other endevours in the mean time. The whole point about being agile is being able to change, but somehow both methods seem to imply that not all change is good, specially when you are working toward the sprint goal (or the iteration goal if your doing XP).

I agree. Most projects fail because during the week the objectives are changed, and this change happens almost daily and sometimes several times a day, and at the end of the project, you are asked "why did we fail?".

"So we did have an objective?" - you ask perplexed

As you can imagine the situation is not very amenable and you not only loose your job or your contract, but you also loose something much more important: Your credibility.

Most professionals do not have any credibility, so you have to work hard to obtain some credibility in a credibility lacking market.

Loosing your credibility is comparable to opening a bottle or your favorite cola and finding water with soil in it. You go to change it to the local store and they give you another identical. You would stop buying cola.

But you do buy cola, don't you? Obviating the health risks, you buy cola because cola has what marketeers call "mental space". When people hire you as a consultant or as a knowledge worker, you are being hired because of the same mental game "when I need something like this, I just call this guy...". Information asymetry. You wouldn't hire yourself because you already know exactly the same as the person you would hire.

Nevertheles, people who hire you learn quickly (they are not morons), therefore you have to keep learning in order to be required in the future.

So both Scrum and XP are right on requiring you not to change objectives during a sprint, but they are contradicting themselves. They are trying to avoid you the pain of having nothing to show at the end of the iteration, but on the other hand they are prescribing just the opposite of their original idea.

Is there a better way?

I think there is. Simply say: Ok, but we are not going to achieve the goal on time.

It works like magic, because it allows the marketing people to make an informed decision while at the same time, you have saved your face. It is important because you don't want to loose your market mind share, while at the same time to avoid conflict in which probably you are going to loose because they are the clients, so they probably know what they want, they just need to know the consequences of their decisions and it is your job to communicate the risks.

(Note: I'm not recommending this particular project managemente course, although I do think that project managers should take courses like this. I'm referrig to it, because an integral part of project management is communicating risks, and not only project managers need to communicate risks, all developers should know about this, because risks happen everywhere in the project, so if only the project manager knows he needs to communicate risks, the project is in jeopardy).

Ok, so now to the second critique. I already mentioned this critique on XP before, but I'm going to repeat it here: XP insist in that you shouldn't use software to do XP.

The rationale is that once you set it up in software it is like if it were carved in stone.

This is the proverbial "In the house of the blacksmith, the knives are made of wood" (I don't know if this is known in English, but at least in Spanish it is "En casa de herrero, cuchillo de palo").

Software is not stone. You can change it. If you can't change your software, it is probably because you are not using the right tools. I think the whole industry is too adept to static compilers and stuff. But there is a tendency in the patterns movement to make software more dynamic.

I think we should replace all the programming problems into configuration problems.

And configuration should be done on the fly. Not on property files.

Then the XP fear of software will disappear.