Choosing between a Waterfall or Agile Project Approach

I recently had the luxury of attending a J.Boye Master Class titled ‘Successful Web Projects with Agile’. Together with 8 other participants we were guided through Agile Development best-practices and pitfalls by Agile gurus from London-based MMT Digital and Helsinki-based Codento.

The class was very fruitful and gave great insight into the hows and whys of the much hyped Agile project model. I came away with a few key findings, particularly in relation to choosing between agile and the more common waterfall models.

Choosing between Agile and Waterfall

Some key indicators to look at when choosing between these overall project models:

The amount of uncertainty in the project. A high level of uncertainty about the final deliverables, could indicate that agile is worth a try, since its’ process encourages exploration through iteration. If on the other hand the outcome is well defined and there is little room for changes along the way, then waterfall could perform better.

Availability of a product owner. Is a product owner available to answer questions, facilitate the process and avoid breakdowns? If not, then this will significantly hamper the agile process, leading to failed sprints and unclear overall vision. Better to fully spec the project in advance before pointing your boat towards the waterfall. For more on the functions expected of a product owner, see this excellent list.

The freedom to prioritise deliverables. Does the project allow for rearranging priorities, even deferring some deliverables to a later project? If so then this could indicate that agile is the way to go. If on the other hand the need-to list is set in stone, then waterfall is probably a better option.

Developers are empowered to make decisions. When working without 100-page specifications or the like, it is important that developers are able to make decisions on the ground, without waiting for authorisation from higher up. If you do not trust your team to make good decisions, then agile is pretty much no-go. Better to give them a detailed specification and hold them accountable to that.

Access to end users. Agile demands testing early and testing often. Not just code reviews, but direct end-user testing to gather feedback and learn along the way. If the product owner is unable to supply access to end-users then this puts a lot of pressure on the projects final stages. Often user-tests are carried out with the nearly-finished product, essentially making any findings little more than foot-notes and learnings for the next phase.

Company size matters

If you are a small company, it may not be realistic to dedicate developers 99% to a single project/sprint. Typically small companies find themselves juggling their precious resources between multiple projects, estimating new things and handling support. This fragmentation of tasks and ressources sets the team up for failing sprints, which can majorly impact the ability to effectively run an agile project. In this respect, agile development can be viewed as a luxury afforded dedicated teams, which typically means larger companies.