This white paper attempts to remove the mystery and confusion witnessed in the gap between Waterfall and Agile software development lifecycle (SDLC) methodologies. Many executives, managers, project managers, and others who make decisions in information technology (IT) strategy, have become immersed in supporting one method over another without deeply understanding the differences, or lack thereof, between the two SDLC methodologies. The truth is the Waterfall and Agile methodologies are much more similar than they are different, and by understanding the common threads, IT professionals and stakeholders can become much more effective in managing projects, making decisions that will increase the effectiveness of their teams, and providing greater value to their customers and organizations.
The approach presented here will, literally, turn the teaching theory upside down. Rather than attempt to describe the characteristics, benefits and drawbacks of each, the approach of this paper is to provide the similarities among the methodologies’ phases, then compare how the phases are aligned within each methodology. The goal is to create both a greater understanding and the ability to plan and track tasks through projects, regardless of the chosen methodology.
As a professor of project management, the need to provide concise lessons plans to help students understand the basics of SDLC methodologies is critical. Text books often led with the description of the methodologies, then worked back to describe the processes and procedures of each methodology, leading to questions and confusion. The mistake in these text books is that all of these methodologies are different approaches to the same operation: software development. With this in mind, my revised lesson plans started with common elements, then compared how these elements were manifested within the methodologies. This clarified the nature of project management methodologies and allowed for the identification of smaller variances. The driver for this approach parallels the ultimate goal of any project: to take an idea from concept to delivered functionality by simplifying the underlying concepts. But instead of focusing on a complete application, scope or program, the focus is initiated by looking at an individual requirement (for this paper, ‘requirement’ and ‘user story’ are synonymous) or piece of functionality. Prioritizing and scheduling the deliverables within any project management methodology follow. Then running the requirement through comment elements is next. The final step in the lesson is to bundle the requirements – making a scope for a project – to managing the project.
To deliver an idea into the hands of customers and end-users, a requirement must go through seven distinct steps to ensure the application will perform to acceptable standards. And while seven are identified, various methodologies have merged some together to identify as few as three, while others create more granular steps to produce as many as thirteen. The seven steps identified here define unique processes in the transition of an idea into deployed and supported product.
The seven steps are: 1) Concept, 2) Analysis, 3) Design, 4) Build, 5) Test, 6) Deployment, and 7) Support.
If this sounds like the basic Waterfall phases, you are correct. The reason is that Waterfall aligns these steps, or phases, in a linear fashion. But let’s briefly review each of these phases to develop a high-level, common ground of what occurs in each phase. Later, how these phases are expressed and where they occur within the methodologies will be defined.
In the Concept phase, the need and/or opportunity is identified. This is the first, and highest level, iteration of the requirement.
The Analysis phase evaluates if the requirement is financially feasible, along with describing who will use it, what it will accomplish, when the requirement will be used in the flow of the application and/or transaction, how the interfaces will appear, and why the requirement is needed in the large roles of the users.
The Design phase plans how the requirement will be developed and/or configured to deliver the functionality to the users. Along with laying out the transaction flows, database designs, and user interfaces, designers plan for security protocol and the bandwidth to satisfy the needs of the users’ organizations.
During the Build phase, the code is actually written and/or the application configured for the requirement. Developers confirm the functionality by unit testing their code.
In the Test phase, the code is verified to work as defined in the requirements.
The Deployment phase moves the verified requirement into the production environment and confirms that no issues have arisen during the migration.
The Support phase, which includes training and coaching, assists users during the transition to the new functionality and processes.
With each of the phase descriptions, the focus is on the requirement rather than the scope of the application. But to be able to compare the project methodologies, multiple requirements must be grouped together. For Waterfall, the grouping is the entire project scope. For Agile, the grouping is by Sprints. A critical understanding with this statement is that the total scope of the project, regardless of the methodology selected, is identical.
The two most common methodologies in use today for IT projects are Waterfall and Agile.
The Waterfall Methodology takes the phases listed above and executes them sequentially. Between each phase, processes such as Exit and Entry Criteria, and Go / No Go decisions may be used to ensure that the project is still feasible and ready to continue onto the next phase.
The application progresses through a series of environments throughout the project. One path through these environments begins in the Development environment, where coding and configuration are completed. The completed application is promoted simultaneously into the Test and Stage environments. QA is executed in Test. After completing QA, the application is moved from in its entirety from Stage into Production for use by customers. Of course, this explanation is simplistic.
Figure 1 – Waterfall Flowchart: Tasks over time.
Figure 2 – Agile Flowchart: Tasks over time.
As mentioned before, the Agile Methodology differs from Waterfall in that the scope is broken up into Sprints. Portions of the entire Scope are produced and delivered to either the Stage or Production environment in smaller batches. Note that the same tasks are performed for each requirement. As noted in Figures 1 and 2, the column headings reflect the difference created by the batching of the requirements. But again, the functions performed on each requirement remain the same.
A more important revelation comes through further review of the charts. By considering any column for the flow of a single-Sprint Agile project, the phases and steps performed in the Agile project parallel a Waterfall project. In a very real sense, looking at an Agile project as a series of short-term, narrowly-scoped Waterfall projects can make sense. From this perspective, the project manager can focus on the small nomenclature and procedure differences rather than be overwhelmed by imaginary chasms between the two methodologies. Furthermore, the project manager can begin to take the better attributes from one methodology and apply it within the other, or (better yet) can synthesize a new hybrid methodology that best suits the project types, resources, technologies and organization.
To further clarify the how tasks align, the chart to the right shows how the phases of Waterfall project and Agile sprint compare.
In the Agile methodology, the Plan phase takes the concept and high-level analysis, along with prioritization, to define the sprint. Final analysis, design, build and test are completed in the Execute phase. Then the completed code is deployed into either the Stage or Production environment.
While this may be a simplified version of the many different variations of the Agile methodology being implemented throughout the IT industry, the basic premise holds true. The processes that a requirement must go through in order to assure that the functionality and reliability of the system meets or exceeds customer expectations are the same.
By understanding the processes that every requirement must successfully go through, and then applying them in a bottom-up analysis to create the project, the mystery and confusion that accompanies project management is eliminated, allowing for a project manager to move easily between Waterfall and Agile projects.
Thomas McCarthy 