Agile and Waterfall Methods can both be valid

There are 2 common SDLC or software development life cycle methodologies, both of which are derived from OOAD with UML.

1. The Waterfall or Traditional approach using distinct phases and hand-offs.
2. The Agile or RAD (rapid application deployment) model, which compresses the Waterfall method and forces close-collaborative development cycles.

It is untrue that you must use Agile.  Waterfall can still be used (see below).  In many firms, the 2 concepts are often times merged to create a customized approach to software development.  Remember, an important aspect of any development is your own team’s resources and skills.  This factor, along with many business and technical variables captured within a ‘Cloud Assessment’ phase of CAF (Cloud Adoption Framework); will be a prime concern.

The Waterfall Methodology

This is largely a linear approach to software development involving distinct phases, handoffs and milestones.  In this methodology, the sequence of events is the following:

1. Gather and document requirements
2. Design
3. Code and unit test
4. Perform system testing
5. Perform user acceptance testing (UAT)
6. Fix any issues and repeat
7. Deliver the finished product

Typically, each of these phases or stages, represents a distinct stage of software development, and each stage generally finishes before the next one can begin.  Once a milestone is obtained, we then move onto the next phase.  For examples, the requirements document must be signed by the business before a technical design can begin.  This is a sensible and still necessary milestone in any project.

Benefits of Waterfall:

• Developers and customers agree on what will be delivered early in the development lifecycle. This makes planning and designing more straightforward.
• Progress is more easily measured, as the full scope of the work is known in advance.
• Design can and should be ‘frozen’ limiting change and scope requests. This should enable a complete design to be made before programming.
• Throughout the development effort, it’s possible for various members of the team to be involved or to continue with other work, depending on the active phase of the project. For example, business analysts can learn about and document what needs to be done, while the developers are working on other projects. Testers can prepare test scripts from requirements documentation while coding is underway.
• Because design is completed early in the development lifecycle, this approach lends itself to projects where multiple software components must be designed (sometimes in parallel) for integration with external systems.

Weaknesses of Waterfall:

• No iterative changes. Once set the requirements are fixed and to change design models can be very expensive.
• Clients are not always able to visualize an application from a requirements document. Mockups can help, but there’s no question that most end users have some difficulty putting these elements together with written requirements to arrive at a good picture of what they will be getting.
• Possibility that the customer will be dissatisfied with their delivered software product. As all deliverables are based upon documented requirements, a customer may not see what will be delivered until it’s almost finished. By that time, changes can be difficult (and costly) to implement.
• Length of time.  To get a client to test can be problematic and delay milestone attainment.
• Development environment is typically different than Production leading to many problems in deploying new versions, which is usually done over a weekend.

The Agile Methodology

Agile is an iterative, team-based approach to development.  Usually Agile is referred to as Devops, or at the very least, Devops and Agile are used together to denote a form of software development, devoted to faster, higher quality output of defined software functionality.  Agile-Devops is as much philosophy and culture as anything else.  To be successful however, Agile must use tools and automation.  This creates issues around skills and training.  At its core as a philosophy, Devops is trying to achieve the following:

1. Improvement of software quality
2. Deploying metrics to measure quality, functionality and usability
3. Ensuring that Production remains ‘static’, meaning you will not touch production until all code is tested and pass.  Everything flows through development.
4. Reducing time to deploy new functionality
5. Eradicating the silos of the development lifecycle namely, development, QA, deployment and operations
6. Stopping the deployment new versions over a weekend and move into a continuous delivery cycle measured in days or weeks [or in the case of Netflix and Amazon, hours]
7. Responding more quickly to business requirements and introduce a ‘fast failure’ development culture which feeds into learning and building quality into software development.

This approach emphasizes the rapid delivery of an application in complete functional components. Rather than creating tasks and schedules, all time is “time-boxed” into phases called “sprints.” Each sprint has a defined duration (usually in weeks) with a running list of deliverables, planned at the start of the sprint. Deliverables are prioritized by business value as determined by the customer. If all planned work for the sprint cannot be completed, work is reprioritized and the information is used for future sprint planning.

As work is completed, it can be reviewed and evaluated by the project team and customer, through daily builds and end-of-sprint demos. Agile relies on a very high level of customer involvement throughout the project unlike the Waterfall method.  As mentioned Agile-Devops almost always mandates the use of tools.  The most common are:

• Jira for Agile-Scrum management and workflow management.
• Github for code repository.
• Jenkins for Continuous Integration and Delivery.
• Chef for Infrastructure as a Code configuration (or Ansible).

Developers need to be trained in these tools to use Agile properly, and this means understanding Python (Jenkins) and Ruby (Chef).

Advantages of Agile:

• The customer has frequent and early opportunities to see the work being delivered, and to make decisions and changes throughout the development project.
• The customer gains a strong sense of ownership by working extensively and directly with the project team throughout the project.
• If time to market for a specific application is a greater concern than releasing a full feature set at initial launch, Agile can more quickly produce a basic version of working software which can be built upon in successive iterations.
• Development is often more user-focused, likely a result of more and frequent direction from the customer.
• Quality should be higher, since development – testing and delivery are automated.
• The development environment is the same as the Production environment and the Production environment is frozen.  This creates stability.

Disadvantages of Agile:

• The high degree of customer involvement, while great for the project, may present problems for some customers who simply may not have the time or interest for this type of participation.
• Agile works best when members of the development team are completely dedicated to the project.
• Because Agile focuses on time-boxed delivery and frequent reprioritization, it’s possible that some items set for delivery will not be completed within the allotted timeframe. Additional sprints (beyond those initially planned) may be needed, adding to the project cost. In addition, customer involvement often leads to additional features requested throughout the project. Again, this can add to the overall time and cost of the implementation.
• The iterative nature of Agile development may lead to a frequent refactoring if the full scope of the system is not considered in the initial architecture and design. Without this refactoring, the system can suffer from a reduction in overall quality. This becomes more pronounced in larger-scale implementations, or with systems that include a high level of integration.​

Which one to choose?