Does Agile Software development work?

This was a question our development team was struggling with coming into the new year. I can firmly say that yes, agile development (even when not done completely right) is much better and much more accurate than waterfall development. Let me talk a little about why I feel this.

Around February of this year, we started a new project. Although we had been dabbling in agile methodologies, this would be the first project that would be developed from using these principles from the onset.

We started with monthly iterations, simply because this seemed to make sense from a release planning point of view. We also realized the importance of acknowledging the work that was done by the development group. We decided the best way to do this was to showcase the iterations work in front of anyone in our organization that wanted to take a look. Our sprint review, if you will.

Back to this application… Our business folks had a reasonable idea of what needed to happen to bring this application to market, so we started breaking out story cards from there. Once we had the story cards, we estimated and prioritized them on the calendar for a release scheduled for the end of June.

The teams (QA, development, and the business folks) went away and started collaboratively writing acceptance tests against these particular stories. This was the first project in our history that had 80% unit test coverage, and a full suite of acceptance tests in Fitnesse. We’re able to change the application with much more confidence, knowing that we haven’t broken anything along the way. This is when the impact of agile hit me.

I personally feel that the positive impact of agile development was felt in our organization at the first sprint review that we had where we were able to show the application we’d been working on. After working for only four weeks, we had the single most important part of the application on the projector in front of the entire company.

I also feel that the impact of agile was felt towards the release of the project. Instead of going through mad coding sprints until 4:00AM trying to get required features in, we were developing stupid things like splash screens and keyboard shortcuts.

As it turns out, our marketing department misunderstood a feature from the application and touted something that was not in the original story cards. However, since we were not in the mad coding frenzy and were working on trivial things, it was very easy to implement this feature and save the day.

Why did things end up like this? Because the items that the application absolutely needed to have were developed first. What a concept, but something that gets lost in a traditional waterfall model.

After having worked in this type of model, I can positively say that I would never willingly go back to the traditional waterfall model. The core agile manifesto values:

  • Individuals and interactions over process and tools, working software
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

This is in line with things that are important to me.