Agile or Waterfall? Let the Organization Decide
Organizations have been grappling with this question lately, and practitioners of either software development methodology (SDM) have good arguments for their preferred choice. Waterfall is the old standard, while agile methodologies are generally considered more fashionable, sparking interest because they are new and intriguing. All that being said, the same question keeps coming up: how do you decide which to use, Agile or Waterfall?
Without any additional information, I recommend that organizations default to waterfall as it is comprehensive, structured, and naturally fits most corporations’ cultures. For these reasons, most organizations do in fact leverage waterfall methodologies. In truth, when the question “Agile or Waterfall” is raised, what is really being asked is “should we move from Waterfall to Agile?”
To properly answer this question you must first determine if there are issues with your current methodology. If the answer is no, then you should not move. This is also true if you were using an agile methodology instead of the waterfall methodology. The cost of changing methodologies is high, because it negatively impacts an organization’s capacity to deliver quality applications in the short term and does not guarantee success in the long term. Changing a methodology must be accompanied by a comprehensive change management initiative and strong leadership. If there are issues, then the answer is less trivial. Before we answer, let’s consider another underlying question in this debate, “which one is better?”
I don’t think this question can be answered in absolute terms. An alternate question that does have a definitive answer is “which methodology is the best fit for my organization?”
The answer to this question depends on a few factors. Agile methodologies are not interchangeable; they have differing precepts and cover varying phases of the software development life cycle (SDLC.) They also do not always provide project management guidelines, defined processes, defined practices, defined activities, or deliverables. For the sake of argument, we will assume that your target agile methodology covers the SDLC and provides structural guidelines equivalent to that of Waterfall. Given these differences, we will focus on the common characteristics of Agile Methodologies to determine the salient factors.
When evaluating which methodology to adopt, you must consider the experience of your team, the type of software you are building, the availability of the business subject matter experts, the budget and time, and the organizational culture. The following graphic provides a quick way to determine which methodology is best suited for your organization. It is not a replacement for a formal analysis and should not be used to make any meaningful decisions.
- For each competency place a check mark representing your company capability
- Count the number of check marks that fall in Waterfall and Agile
- The methodology with the higher number of check marks is the best fit
What if your organization is having issues with the waterfall methodology, but Agile is not a good fit based on your organizational analysis? In these situations, you could modify the waterfall methodology to address specific issues, many of which can be solved through training. Some of the issues that the waterfall methodology tends not to solve easily are rapidly changing requirements and quicker time to market. I have found that these issues can be addressed by implementing an iterative Waterfall methodology. In iterative Waterfall, time is fixed, and scope is broken into segments to fit the allotted time and resources. Each iteration must go through requirements, design, build and test and is executed in a slightly staggered schedule, meaning that each iteration starts just before the previous iteration is complete. The advantage of iterative waterfall is that it provides clear points to change requirements and receive users’ feedback, reducing re-work and time to delivery. The disadvantage is that it creates more potential points of failure and additional work for the project manager. Alternatively, you could attempt to change your organization to make Agile a better fit. As pointed out earlier, changing an organization’s culture is a difficult project and should be planned carefully.
What if your organization is using Waterfall, but Agile is a better fit? Should you change? Yes! Provided you plan the change carefully. Agile methodologies provide flexibility that Waterfall cannot match, and they reduce the documentation burden and promote collaboration typically resulting in quicker time to market when executed properly.