Project Methodologies

Traditional waterfall vs Agile

These days there are two primary project methodologies in the world of IT systems projects, traditional "Waterfall" and the more contemporary "Agile" which is a form of iterative development.


Waterfall projects are typically driven and managed through a PRINCE2 style structure, and have a very clear beginning, middle and end.  At the beginning we work out what we are trying to achieve and put some controls around that, in the middle we make the changes and at the end we deliver the changes and benefits to the organisation.  Everyone understands it.


Iterative projects have come about due to increased pace of business change and the necessity to adapt quickly to market forces.  The capability of IT systems to be created in a more adaptable manner allowing for changes to be implemented more quickly has also led to this shift in approach.  Functionality is delivered in iterations, which typically last 4-8 weeks at which point value is delivered to the business.


There are different flavours of iterative development, the most popular currently being SCRUM, however each organisation typically implements it in a slightly different manner. 


Both approaches work, and both have their pro's and con's. 


My take on methodologies


In the marketplace today there seems to be a great deal of focus on Agile, and almost a frowning upon Waterfall.


I have been involved in projects using both methodologies, and can say that both are perfectly up to the job.  However, like most things, there is a time and a place, and each project has its own unique circumstances which will drive the selection of the methodology.


It is my opinion that a combination of the two methods is likely to be most appropriate in most cases, with user experience projects being most suited to the purest form of Agile, whereas complex projects including integration of multiple systems and geographically dispersed teams suiting a greater mix of the two.


However, I am absolutely an advocate of iterative development and delivery wherever possible.  This due to


  1. The earlier the delivery of functionality, the greater the total business value

  2. The sooner we deliver functionality, the sooner we can adapt it to even newer consmumer needs

  3. Allowing business teams to prioritise requirements and see them delivered, the greater their engagement