Agile vs. waterfall

First of all, what am I talking about?

The waterfall methodology is a very traditional way of managing software development. this is what I (and countless others) was taught at school and university and is a logical system which fits most projects across all manner of industries and business.

It fits the name as the diagram the model produces shows the project flowing from one discrete stage to the next, like a waterfall.

The main stages usually are:

Requirements specification
Design
Implementation
Testing
Installation
Maintenance / feedback

It suits larger companies as it's easy to report on, you can track what stage a project is at, and the idea is that it should give certainty around when the project will be delivered. The requirements and design stage are very important and produce many detailed and accurate documents about the project. Once the requirements have been signed off, they should not be changed. This means that someone new coming in should be able to understand all the details of the project simply from the documentation. It's good for multinationals who may have large development teams over several countries, everyone needs to be able to refer back to the same, correct set of documents.

Agile, on the other hand, as it's name suggests, tries to be a lighter and quicker method for managing projects which enables a team to change direction if necessary.

It places much less emphasis on documentation and more on face to face communications and producing working software quickly. The project will be broken down into smaller tasks which can be developed in 'iterations' (small 2 to 4 weeks worth of development). These tasks will produce prototypes or pieces of working code which can then be shown to the customer or internal business owners to get more feedback. You don't need to wait till the end of the project for feedback.

Within an iteration, the requirements for the team should not change, but requirements for the project as a whole can change and will feed into subsequent iterations.

The process involves daily short 10-15 minute meetings (scrums) for all of the small team to discuss what they are doing and any blocks they are facing. Business owners or customers can come along to those meetings but they shouldn't get involved in the discussion, they can come to the iteration planning to demo/review meetings to see what has been produced and what is planned for the next iteration. A simple addition I've found in my current role is to have the whiteboard which shows each task in the iteration and at what stage the task is at (to do, doing, done, blocked...), in a very visible place like the kitchen or the reception area. No-one can say they don't know what's going on!

I've found that the agile methodology works best for web development in smaller companies. The nature of most web projects mean that requirements are difficult to pin down 6 months or a year before (as the waterfall method would need). In the time taken between signing off the requirements and the project being completed the online market may have changed, the internal structure of a company may have changed, a competitor may have entered... it is a fast moving space. So developing in an agile way means that a team can adapt as necessary. It's still very important to have a vision and high level roadmap of where you want the product to get to, but the details of that don't need to be set in stone.

However, I did say "in smaller companies". I have worked on web projects in large companies and this is a different kettle of fish. In the larger organisation where your developers may be in another country, it could be difficult to have the level of face to face communication needed. Also many corporates have their own project management standards, it can be difficult for a central admin group to understand why your team doesn't need to (or can't) spend time filling it's hundreds of forms which the rest of the project will do. They need to sign off your work and to report up the progress of your team and they can't do that without you jumping through the same hoops as everyone else.

But for in a small, co-located team, it works well and is really motivating to see functionality being delivered often, and to know that what you ultimately produce will suit the needs of the customer and the market.