Don't trust on methodologies!

Prince2, ITIL, WaterFall, Agile Software Development, they all are intended for and add value in particalur environments.

Agile methods are often characterized as being at the opposite end of a spectrum from "plan-driven" or "disciplined" methodologies. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined." A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive." Agile methods exist on the "adaptive" side of this continuum.

<--Agile--> <--Iterative--> <--Waterfall-->
<----|-------------|----------------|----->
Adaptive                         Predictive

We believe that "adaptive" methods are better suited for web application development, than methods like Waterfall. During the developement period, which normally takes 1 to 6 months, customers continously get new insights and need to be able to redefine the specification to leverage business values.

The first projects we used the WaterFall method, which resulted in a perfect pitfall due to optimistic estimates and fixed price contracts. This was a very harsh way to learn this method didn't work well for us, so we explored other ways to manage our development process. After a few googles Extreme Programming showed up.

Extreme Programming suggests using cards and have the customer write down small features in "stories". Each card contains a story which will be broken down in technical tasks, which will be estimated by the programmers. I think this is a good practice, because it assures customer involvement to write the specs and estimating small tasks is easier and more accurate. For this to work the customer should always be around to answer questions about or even rewrite stories.

In real life we were not able to persuade the customer to work like this, so we decided to use our development skills to write a tool which assists us in involving the customer, by allowing the customer to add and modify stories in the portal, a place which is available to both parties 24 x 7.

The next project we started writing stories for the customer and divided work in iterations on our website. This project also didn't work that well because we were continuously changing the stories, each time delaying the iteration deadline. But we found out that customer involvement really leverages quality. The system almost fully suited the customers "dreams", but we still got off budget.

The last three projects, we were able to give better estimates because we now have data about actual time spend on tasks. Making the end date of an iteration absolute we discovered this provides a good opportunity to inform your customer of the current status. Telling the customer why some of our estimates were off creates an understanding of the complexity of developing software. By allowing the customer to decide on the trade offs he has better control over his budget.

So in a way Extreme Programming has been useful for us, but instead of living by the rules we bended the rules to adapt it to our environment. It is not a spoon.