More than a process

The great software-development-methodology wars never cease to amaze me. Agile, Waterfall, XP, SCRUM, RUP… so many people are so occupied with convincing everyone around them that their favorite methodology is the ultimate answer to practically any question.

Why is this a problem? Because no one methodology will ever be able to solve all problems. The process of developing software is (like almost anything else in our life) context sensitive. With every new project comes a different set of challenges, constraints and expectations. Each methodology has some great things to offer. No methodology, however, can fit as-is to every project.

In a recent post, Ed Gibbs describes how he was disappointed to realize that the stakeholders of a new project refused to adopt Agile development despite of some successful pilots conducted in his company:

“I just assumed that we’d be using our official Agile methodology on this high profile project. […]

[…] I turned out to be on a different page then the rest of the room. There idea appeared to be that we would run this as a traditional project. Traditional for us means a sort of strange version of waterfall, but waterfall none-the-less.”

Here’s the good news. The methodology wars are 90% psychological. If we would just stop using the names of one methodology or another in our discussions, most of our disagreements will disappear. At the end of the day, it all comes down to common sense.

In his post, Ed was troubled by the risk of spending weeks on writing requirement documents for a two-month project. Ed is right. This is a concern. It does not make sense to spend weeks on writing lengthy documents for such a short project. I bet he will be able to convince the other project’s stakeholders that there is a better way to manage the requirements in this project. I bet he will be able to do that without mentioning the word ‘Agile’.

At the same time, it might make sense to take a different approach when it comes to another aspect of development. Maybe the design of the product should be well-thought of before implementation starts due to the complexity of the product and the risk it imposes. Does this approach contradict Agile development? You know what, I don’t really know. What I do know is that for some projects it makes perfect sense.

You see, it doesn’t matter what you call it. Apart from the pseudo-prestige of saying “we use [your-favorite-methodology]”, the name of the methodology has no meaning.

Every methodology offers certain tools, guidelines and practices. That’s great. You have a great variety to choose from. No one says, however, you have to buy the entire package. You should use whatever tools and practices make sense for your current project. Create a customized process that fits perfectly to your needs and the needs of your stakeholders.

When you manage to do that, don’t be tempted to apply your customized process to a different project as-is. You should carefully analyze whether your process fits the new project, and adapt it as needed.

***

One more thing: please don’t comment on the fact that this article is tagged under ‘Agile’ against my own recommendation. That is, unless you really have to… ;)