Wednesday, August 6, 2008

Agile criticism - 1

Before I get beaten to death by the Agile Evangelists, I want to say that I do believe in Agile. I am open minded, and I think Agile methodologies are a breath of fresh air in the software development community. But I'm as skeptical as I am open minded, which I think is a Good Thing. And being skeptical as I am, I think there are some fundamental problems in the way that Agile is 'sold' by some evangelists, and 'bought' by the general public. I will talk about those flaws during a series of posts.

Before I expose my first criticism I would like to quote here the Agile Manifesto. At the first time I read it, I was surprised by how short it was. I was probably waiting for something as long as the Communist Manifesto, but the Agile one is surprisingly shorter:

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.


That´s it. 10 lines. It almost feel like they wrote it in a napking over a cup of coffee, but it does the job. In a world of verbose meaninglessness, those guys are able to cut the crap and go straight to the point. They get grade A for conciseness.

I can't disagree with what it says. But what stands out to me is the following: while there is value in the items on the right, we value the items on the left more.

Great! They don't dismiss processes, tools, documentation, contract negotiation and following a plan. Hell, I like these guys! This Agile Manifesto thing seems off to a good start! But I feel that many people got it wrong, because what I often see is total dismissal of these items in favor of the agile principles. It is like everything that was ever tried in the 50 years history of software development was wrong.

This is my criticism: Agile is often seen as a 'one size fits all' solution. Also, it is seen as a replacement for everything that came before.

This is a movement that is seen very often in the software industry. Some new idea comes up, usually with a catchy name, and before you notice everybody is talking about it and using it. But most of the people don't get it right, so it is implemented 'by the book' or it is overused. At some point, people get disappointed when they find out the idea is not the holy grail of computing, then many get it wrong for a second time and start saying the idea that would solve all problems is completely useless.

The problem in the process above is that people don't understand the basic principles that drove the development of the new idea. If they did, they would most likely apply it only when it is supposed to be applied, and not everywhere as it often happens.

In the case of Agile methodologies, they came to replace traditional methodologies in the situations where they are misused. The good thing is that this describes the situation of most software projects that try to use some kind of methodology (the most common case is to have no methodology at all, in which case Agile also fits). But even then, if people don't understand the principles, they won't get Agile to work. The smart people will get it and turn Agile into a success case.

So I finish this with two advices. First, understand the principles behind Agile. Read the Manifesto. If you are using any Agile methodology, make sure you understand the reason of EVERY SINGLE PRACTICE the methodology proposes. Then see if it applies to your situation. If so, fine. If not, discard that one and use the rest.

This takes me to my second advice: be skeptical and try to understand the reasoning behind *any* new idea. Use your intelligence and feel free to question what seems to be common sense. It will make you a much better developer.

More information:

Tim High has a great post where he questions: Is Agile for everyone?

1 comments:

Phillip Calçado said...

"In the case of Agile methodologies, they came to replace traditional methodologies in the situations where they are misused."

Can't agree more but there's something very odd about misuse. I've never been in a project where traditional (i.e. bureaucratic) methos are NOT misused.

McBreen says in Software Craftmanship that the place those techniques would be useful are extremely spec-oriented projects, like those from NATO that originated the term ' Software Engineering'.

I never worked in such environment so i can't say much about those but I really think that ' misuse' for 'traditional techniques' means pretty much 'applying to non-military environments'.

cheers