By: Ajay Patil On: March 12, 2013 In: Agile Project Management, Project delivery Comments: 0
To Agile or not to Agile

To Agile or not to Agile

Let me start by saying I love agile project management and I’m a big advocate of the methodology. But, like with all great methodologies, it’s never a good idea to get married to it. Whether that’s process, technique or methodology, you have to do what works for the project in the environment that you’re in. All projects are not created equal and context matters.

Adopting an agile methodology where requirements, scope and functionality change on a daily basis is a great way for a software development shop to get software releases and new enhancements out on a regular basis. However, for larger organizations where scope, budget and timelines are a key component and are normally a prerequisite to having a project approved, an agile methodology may appear to add risk.

Design and Requirements

A good fit for using an Agile methodology would be:

  • A project where exact requirements may not be fully defined and can change almost on a daily basis based on user feedback over time
  • A start-up working on a new mobile application for example, having the flexibility to add and remove functionality based on user feedback is a big advantage

A good fit for using an Agile hybrid or traditional waterfall methodology would be:

  • A project where the requirements may have been fully defined and any changes to requirements need to go through many rounds of approval before a change to the requirements can be made
  • A project  where significant lead time may be required to allow for deployment, change management, data migration in terms of resources and execution making scope definition a key prerequisite


  • In an Agile world, functionality is broken down into small chunks
  • The project manager can move functionality from one iteration to the next in order to meet release timelines
  • A PM may sacrifice core functionality A for Q1, if core functionality B and C can be implemented and then reschedule functionality A into Q2
  • On a large project, where there is one release date, all functionality has to be included and there is no room to juggle core functionality and therefore locking down requirements and timelines in a waterfall methodology is key


  • Agile promotes iterative development and testing associated
  • Testing resources that are assigned to the project and will always be required through each iteration
  • The biggest concern for those from a waterfall background is the increased cost of having dedicated QA resources for the duration of the project and also this may limit the opportunity to share resources across multiple projects

In conclusion, there are many benefits to using an Agile methodology, however, it may not be suitable to all. The best solution is to weigh up the pros and cons of each methodology across the different phases of your project and develop a hybrid methodology that uses the pieces that complement your project and your organizations objectives.

Look out for an upcoming blog post on where Agile works for large projects.