Ah, the ever so fun debate between agile methodologies and waterfall for IT development. Take a deep breath. Not only is this a big debate, but it’s often very heated.
Waterfall was the way to go for many, many years. Recently, though, the agile methodologies have been providing more of a sustainable path for companies because of the flexibility and success. Because I actually leverage both, I thought I’d share some insights into both methodologies.
This is the typical IT project methodology. It is a linear, sequential approach to software design. Each phase is a silo, from which you don’t move on until it’s completed. Waterfall is very schedule- and milestone-oriented, which results to detailed requirements and understanding of the final product before teams get to start building. A change control process is put in place to ensure the right things are documented and nothing is missing. By nature, Waterfall is process-driven and heavy with documentation and prescribed deliverables.
Phases of a typical waterfall project usually follow a predefined route.
- Project Initiation: The initiation phase is leveraged to create the Business Case, charter or vision statement, budget, and some planning documents.
- Define: This phase allows project teams to describe the project’s requirements and understand the needs for process and the application’s functionality. The typical deliverables are the Project Requirements document and Business requirements.
- Design: This is the time for product functionality and technical design. It’s when wireframes and prototypes are created to ensure the final product will meet the customer needs. The deliverables are dependent on the environment and interpretation needed for the teams to become aligned.
- Develop: This is encompasses final technical design and development. It is more of the “behind-the-scenes” effort for the technical team. The business partners typically do not have heavy involvement during the phase.
- Test/Deploy: Like it says, test and deployment.
- Warranty: Usually a 30-day cycle to allow the project team to manage any open or new defects before handing the product over to the support team.
A few additional things to note are the defect management and change control processes. These ensure that the team has a level of flexibility while moving through a project. It also ensures the proper level of documentation for education of, and validation by, other members of the project team.
Agile methodologies are very different. They’re a group of software development methods based on iterative and incremental development. Requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. They leverage adaptive planning, iterative development and delivery, a fixed iterative approach, and encourage rapid and flexible response to change.
The driver behind these methodologies is the Agile Manifesto, which was created in 2001. The methodology typically focuses on individuals and interactions over processes and tools,working software over comprehensive documentation,; customer collaboration over contract negotiation, and responding to change over following a plan.
It’s easy to understand why Agile requires a different mindset. Individuals and teams have to be adaptive and react in a positive way to change. It also requires a willingness and commitment for teams to move forward and constantly adapt and change.
Some popular Agile methods are:
- Agile Unified Process (AUP)
- Extreme Programming (XP)
- Open Unified Process (OpenUP)
- Lean Software Development
Comparing the Two
Waterfall is like a traditional waterfall, literally. It starts at the top and drops in a linear fashion until it is “done.” Agile is not as predictive and allows for iterative change and process.
Waterfall is better for projects that are predefined and understood. Agile is better in situations where there is still a bit of uncertainty regarding the end solution. Waterfall does not allow for interactive development. Agile enables the team to close the feedback loop more quickly and enables communication to start early in the process.