Agile vs. Waterfall

• Detailed product requirements and documentation enable new programmers to onboard quickly and easily.
• Documentation provides a clear scope to the project, enabling project managers to communicate budgets, timelines, and key milestones to interested parties.

• Clients can find it difficult to outline all of their requirements at the beginning of the project, leading to gaps in documentation.
• Minimal customer collaboration during the development process can lead to costly changes if the product does not meet expectations.
• Testers report issues and bugs later in the process, which could have informed an alternative program architecture.

In contrast to waterfall development, agile is defined by its iterative approach to project management. Instead of drafting lengthy project requirements at the onset, an agile team breaks out the product into specific features, and they tackle each one under a specific time constraint, known as a sprint.

Agile project management requires a cross-functional, self-organizing team that typically consists of five to nine members. Together, they develop a workable piece of software during each sprint, which combines with other functional code from previous iterations. By the end of the sprint timebox, the team demos their work to stakeholders for feedback, allowing them to be flexible in their approach to software development. Since the team has access to frequent feedback, they can adapt the product roadmap during the development lifecycle to ensure that functionality truly meets user expectations. In a waterfall approach, customer involvement typically coincides with the delivery of the final product, which can be costly when requirements are misinterpreted or documented incorrectly.

There were 17 individuals who found the waterfall project management system to be a highly ineffective, and in 2001, their ideas around the software development process culminated in a piece of work known as the “Agile Manifesto (link resides outside ibm.com)”. This document highlights specific values and principles to prioritize within software development workstreams, and it has yielded a number of popular agile frameworks, such as Scrum, Kanban, Feature Driven Development (FDD), and Extreme Programming. Since then, agile software development has increased in popularity, especially when compared to the waterfall model.

Inspired by the game of rugby, agile scrum emphasizes teamwork to meet deliverables, similar to the way that forwards need to work together in a scrum to gain possession of a rugby ball. The skillset of the agile scrum team varies, but they usually include the following roles:

• Product owner: This team member represents the needs of both the customer and the business. By crafting user stories, the team can understand how a feature request can help resolve a specific problem, and these stories formulate the backlog of tasks for the team to tackle. This person also prioritizes the stories by their value to the customer, which should, in theory, translate into value for the business. While the product owner leads the team in this way, they do not set deadlines or instruct the team on how work should be delivered.
• Scrum master: This team member facilitates the overall agile development process. Similar to a project manager, this person keeps the team on task, ensuring that the team remains focused during the project. They can also act as a neutral party to mediate disagreements among team members. For example, team members may disagree on how much to take on in a given sprint. Product owners, in particular, may pressure teams to commit to more than they can deliver within a given timeframe. In these cases, scrum masters can remind team members the scope of their role on the team.

Other team members of an agile team can vary, but they typically include users from a variety of disciplines, such as design, analytics, QA, and development. These individuals collaborate together to decide on how much work to take on and how they will complete it.

Agile methodologies are also defined by the ways in which the team comes together. There are specific meetings which help facilitate the workflow across the team. Some of them include the following:

• Sprint planning: During this meeting, the team comes together to determine which stories will be part of the current sprint. The product owner will prioritize the user stories, but the rest of the team will need to agree on how many and which user stories they can complete during that set time period.
• Daily standup: These brief meetings are also known as daily scrums. During these check-ins, each team member communicates their individual progress, such as completed tasks, upcoming ones, and any blockers or dependencies which may result in delays.
• Demo: This meeting showcases the working software that the team completed over the course of the sprint, which can range between two- to four-week increments. The product owner will determine if a user story has met the definition of “done.” If not, the product backlog may be groomed to account for anything missing. This is also an opportunity for the team to present to stakeholders for feedback.
• Retrospective: This time is reserved for team introspection, where the team identifies how they could improve upon their workflow to achieve better results in the future

• Team design facilitates more collaboration.
• Product development takes an adaptive design approach.
• Since code is tested with each iteration in the development phase, code defects can inform future design of the software.
• Tends to yield higher customer satisfaction since frequent feedback leads to increased prioritization of customer needs.
• Enables continuous integration as each feature is its own workable piece of software.
• This lean type of software development can lead to lower costs as there is less risk of customer and product misalignment.

• An agile approach can lack comprehensive documentation. This makes it difficult to onboard new developers, project timelines to stakeholders, and provide accurate cost estimates.
• Can be difficult to scale.

While development teams have been successful under either project management approach, there is certainly more momentum around agile processes. It’s not hard to see why when we observe the benefits that it can offer companies today. While there are a number of project management tools that can help teams track progress, IBM can also provide systems to enable developers to code in a more agile way.