Goodbye Waterfall, Hello Agile.

Having recently started using an agile development process at work, here is a very informal look at some of the things I like most about the process from a developers point of view. Don't expect anything too in depth though!

Recently the business that I work within on a daily basis has adopted an agile process to deliver web development projects. I am not an agile evangelist, nor an agile expert, as the process is relatively new to me. However, having got a handle on the basic concepts of an agile development process, I really believe it is a truly great way of running projects. I am now of the conclusion that in any instance where it is possible, running things in an agile manner will deliver better than a traditional waterfall approach. Here are a few of the things about agile that have really pushed me towards my opinion.

It focuses on delivering what is important, not what is ‘nice’

I have found that writing out cards and sticking them on a huge whiteboard in the office really gets the stakeholders in a project to decide on priorities in a way that I have not seen before. Much of the functionality that would be ‘nice’ to have often disappears out of scope totally, when via a waterfall process specification, they may well have remained as must-haves.

Requirements written as acceptance criteria are very clear

When a piece of work is decided upon a user story is created. Alongside the user story a set of acceptance tests or ‘requirements’ are written for it. The work is complete when the acceptance tests are met. This means that a clearly defined goal is available for a piece of work before any code is written. No more waiting or plundering through huge specification documents trying to find what the piece of work is supposed to achieve.

It embraces inevitable change

One of the core reasons behind the agile process is that change is inevitable. We all know this, yet so many departments try to work to a fixed schedule and reject any changes to scope as they would take the project off of schedule.

The agile process allows everything to change (except for the ultimate delivery date) meaning that features can be added, changed and removed quite freely. This leads directly to point one in that everything is prioritized in a much more precise manner as the most important things are always worked on first. This is unlike a traditional waterfall approach in that everything is developed in order.

Test Driven Development produces solid code.

Whilst not a core part of the agile process (belonging to extreme programming - one method that can be used to deliver an agile project) Test Driven Development is something that I have found vastly improves the quality of code produced (if you’re not familiar with TDD I suggest you read this article). This ultimately leads to less time fixing bugs and re-factoring code to work properly.

Granted, there is a but to this statement - To run TDD well, you need developers that can write good tests. However, I believe that the time developers spend learning how to write good tests will definitely be a good return on investment on the long run.

Everyone involved is responsible for a projects success

In an agile project, everybody has a responsibility for the smooth running of the project. I have found that this has removed a considerable amount of a "let’s just chuck it on the web team and come back in 3 months when it’s done" attitude. It gives everybody involved a vested interest and responsibility in keeping things on track.

I’d like to hear your comments and experiences of the agile process. Do you feel it’s improved things for you? Are you new to it? How are you finding it? Have you been using it for years and would have it no other way? Please leave your thoughts in the comments, let’s get a good discussion going.