Blog | Feb 26, 2013
Waterfall vs Agile Methodology
There are continuing discussions that go on debating which approach is better: the Waterfall or Agile Methodology. There are pros and cons on either side of the table, but the question is what works best for you?
In a traditional Waterfall approach you have sequential steps of design, development and testing. Each team is assigned their specific responsibilities and stage of the project to control the quality and on-time delivery. The Waterfall approach is very structured to help ensure a successful project is the end result and that groups of resources on the project are not competing with each other to accomplish their specific tasks. The benefits of a Waterfall approach are controlled and structured stages that result in a successful completion, but this also relates to a longer timeline for the entire project. In addition, should something ‘happen’ along the way it could require you to revert back to a previous stage and start all over from that point.
In an Agile approach you take the same overall concept of a Waterfall approach by assigning specific responsibilities and tasks to your respective resource groups, but instead of working in a more structured stage-by-stage approach you allow parallel activities to be worked on at the same time. The benefit here is what we call ‘shorter sprints’ to completion and decreasing the overall timeline, or increasing the amount of projects that can be worked on at the same time. So what are the cons? Infrastructure costs. In order to allow your resource groups to work in parallel, you need to provide them with access to a database or environment that will not conflict with the other groups. The more groups, the more databases or instances you will need. This can drive up your CapEx and not create a good ROI.
The following illustration compares the two approaches based on independent research.
As the workload and project list grows more and more clients are timeline constrained by instance strategy and management. It is critical that Environment Managers understand and are aware of the multiple project objectives and timelines. We often see project start dates get pushed out because an instance would not be available until a project team completes a set of tasks. Clients have increasingly started to separate instances for easy manageability and to reduce the complexity in coordinating with application development and test teams for clones and other maintenance tasks. Some clients have project based strategies, with instance streams (Dev -> Test-> QA) for development and enhancement and others for post-production support. But again, you are picking up either a CapEx cost for the additional environments or an OpEx cost for the increased timeline.
Keep this in mind when deciding:
Cloud isn’t just in the sky anymore, it’s everywhere. As you are deciding how to tackle your upcoming projects, whether it be technical development, upgrades or new implementations, consider leveraging a hosted cloud solution. This is going to give you the best of both worlds. You will have a structured approach, the ability to work multiple tasks or projects in parallel which will help reduce your OpEx, the flexibility to ‘roll back’ without the need of a traditional clone or refresh and not have the concern of CapEx in order to complete, or even start, your critical business objectives.