Agile Vs. Waterfall: Determining Which Methodology is Right For You

Agile Versus WaterfallI meet with a lot of organizations who use Waterfall as their standard development methodology and are looking to adopt Agile instead.  During these meetings I always bring up several questions -  What are the result you are trying to achieve?  What problems are you attempting to solve that you feel Agile will help?  What will Agile give you that you are not already getting?  Through these conversations, I have found there is usually a misunderstanding of what Agile provides and when it is appropriate to use. 

Development methodology is really not appropriate for universal use and deciding what to use should be based on the type of system.  During our Application Portfolio Management (APM) assessments, we use Gartner's Pace-Layered Application Strategy to evaluate applications and assign into three categories.

  • Is it a new or emerging technology?  In these "Systems of Innovation,"there is a lot of experimentation, processes change rapidly and you need to be able to respond quickly.  This dynamic environment is great for Agile.  It is also important to keep in mind that in Agile, the business has to be very involved and do a significant share of the work.  Again, this is where Agile proves to be appropriate for these innovative projects.  You work hand-in-hand with the business as you get ideas from them, they show you new concepts, give you feedback on the changes you are making, and you can push changes out into the market and begin to gather real feedback.  

  • Is it a system that provides competitive advantage?  "Systems of Differentiation" are typically applications that started as Systems of Innovation, have met or exceeded benchmarks set for them, and have shown enough value to invest further.  It is important to note however, these systems may have to be completely re-written to become a System of Differentiation.  Innovation needs to be quick and flexible whereas Systems of Differentiation need to be supported, they will have a larger user base, and there is more emphasis on them from a disaster recovery perspective.  So, where you were highly experimental and flexible when it was a System of Innovation, now you will be less experimental and have stricter change control.  The System of Differentiation will need to be more stable as you are bringing the application into your overall enterprise.  Agile can still be appropriate for these types of systems because you still want flexibility and an iterative process, however you should look at increasing the duration of the sprints, having a dedicated team, and creating more structured release management. 

  • Is it a core or foundational system? "Systems of Record" are foundational to your business such as policy management systems for insurance companies or supply chain management systems for manufacturing companies.  These systems are usually $1M+ implementations, require an entire team to support, and if they go down, it costs a significant amount on an hourly if not a minute by minute basis.  Agile is generally not a good fit for these systems for two main reasons.  First, Agile requires heavy business engagement but Systems of Record generally cross multiple business functions which makes business owners hard to identify or consist of a large committee which is difficult coordinate a cohesive involvement in the process.  Second, Agile requires a great deal of flexibility and a level of experimentation, both of which are incompatible with a system of record because you need to have a much stricter change control process.  Systems of Record will have a heavy emphasis on testing to pass numerous tollgates and will likely have release windows quarterly, semi-annual, or even annually.  In these systems you will need to gather requirements, develop, test, then release - this is a Waterfall process. If you are suddenly Agile in your core management systems, you are going to encounter higher degrees of churn, more outages, and significantly higher costs.

By understanding the appropriate tools to use for each situation, you are one step closer to more effectively managing your application portfolio. 

If you are interested in using Gartner’s Pace-Layered Application Strategy to categorize your applications, we recommend first inventorying, documenting, and evaluating your portfolio with Gartner’s TIME framework.  You can get started today with our free worksheet to evaluate your applications with TIME.

Evaluate Your Applications with TIME Worksheet

Topics: Application Development, Application Portfolio Management