Agile Vs. Waterfall Project Approach

Agile, Waterfall, and Scrum are all buzzwords in the project management field and particularly in software development. But what are these project management methodologies exactly? What is the difference between Agile and Waterfall and Scrum? And what value does knowing this information provide you, the budding software entrepreneur?

If you are considering joining the thousands of people taking a shot at becoming the next big thing in the app world, to succeed in reaching that status you need to start with a solid foundation.This means pursuing an appropriate project management method. How is the process of building your investment being managed, what are the benefits and disadvantages of each approach, and how will this impact in whose hands you place your trust to end up with a winner.

The following guide will address the most common questions regarding traditional project management approaches. We’ll explore the difference between the Agile and Waterfall methodology. We’ll also look at Scrum and how it has its place as a form of Agile testing. Hopefully, by the end of it you will have a better idea of where to start.

Putting the Waterfall Methodology Into Practice

Waterfall management has its benefits, which is why at Glance we apply it to our Discovery and Design phases. This is due to the shorter nature of these phases and the certainty of the process. Some of these benefits are:

• We can say with certainty: what will be delivered, when, how much it will cost and what is required from our clients. This makes it very popular with clients as they know exactly what to expect upfront.
• Waterfall processes have been extensively documented which minimises risks due to staffing issues – sick staff member? No problems, the documentation will ensure the replacing staff knows exactly where to pick up from.

Agile vs. Waterfall Comparison: When NOT to Use a Waterfall Methodology

When it comes to building software though, and comparing the difference between Waterfall and Agile, Waterfall project management is often not the best approach due to the rigidity of its sequential manner. This is why at this point we move into Agile management. More specifically, we advance into Scrum, which provides the flexibility to deliver the right product to our clients (more on this in the next section!).

Changes in the market, political environment, and even within the enterprises commissioning the software (i.e our clients) are some of the biggest disruptors in a project. When following the Waterfall project management methodology, input from these emerging factors is almost impossible until the end. At this point, it can be quite a costly exercise. If using the Waterfall management method for software development, we can possibly end up with a potentially obsolete product by the end due to these unforeseen changes. In terms of the difference between an Agile and Waterfall model, this is the major flaw within the Waterfall project management approach and its application in complex and lengthy projects – such as building an app.

Agile project management dates back as early as the 70s. It began when the need for a more flexible approach than Waterfall started to emerge with the rise of software. During the 90s various methods of providing this flexibility started to arise such as Scrum, DSDM and XP. All of these are now considered frameworks to deliver Agile, which came into its current form in 2001.

Agile itself is an ideology which proclaims the following set of values labelled the ‘Agile Manifesto’ which states:

What the above describes emphasises the major difference between Agile and Waterfall testing. This is the innate flexibility and collaboration that Agile facilitates over other project management approaches such as Waterfall.

The Difference Between Agile and Waterfall: Agile Advantages

The Agile project methodology is an iterative, overlapping approach to software development projects. What this means is that the product goes through multiple consecutive cycles of planning, building, and testing functionality. In leveraging Agile testing, we can acquire acceptance from the client as we go rather than at the end when the product is finished. Doing so at the end tends to result in a costly reworking of the entire app.

What Agile enables as an approach to project management is:

• Flexibility to allow for changes that naturally arise from seeing a product come to life.  These changes can be made throughout the process rather than at the end of the project.
• A sense of collaboration and rapport between client and supplier as they work together to develop a built-for-purpose product.

Within the Agile project management methods, there are tools that allow for the delivery of its values. After all, Agile management is aimed at describing what to deliver but not how. This is where the frameworks described earlier like Scrum come in.

Scrum and its terminology is derived from its comparison to a play in Rugby. The aim is for the team to work together to get the ball across the line by passing it backwards and forwards between team members.

As mentioned in the previous section, Scrum is a project management methodology used to deliver projects in an Agile way. So if Agile is a lesson to be learnt, Scrum is the book that will enable this.

The Scrum team and their associated roles, events and artefacts all work together and are essential to the success of Scrum and its proper usage in software development. The rules of Scrum then bind all of the above together and help shape the relationships formed within the Scrum Team.

The Scrum Team consists of:

• The Product Owner (usually the client or Project Manager from the client side)
• The Development Team
• The Scrum Master (at Glance this role is fulfilled by our Project Manager)

Scrum Events are put in place throughout the development cycle to facilitate communication between the team and at the same time minimise unnecessary meetings.

• Sprints – these are the development cycles which generally vary between 1-4 weeks depending on the project.
• Sprint Planning – sessions, where the work to be performed in the sprint, is planned
• Daily Scrum – daily meeting to share progress and concern with the rest of the team
• Sprint Review – demonstration of work completed for the sprint at the end of that cycle, this is shared with the client
• Sprint Retrospective – internal meeting held at the end of the Sprint with the Development Team to discuss what went well and what can be improved on based on the last cycle

Scrum Artifacts are the products of each Sprint and provide a measurable way of assessing a project’s health. They are:

• Product Backlog – a collection of all tasks to be performed by the end of the project
• Sprint Backlog – selected tasks from the Product Backlog to be completed in the current Sprint
• Increment –  the sum of all tasks completed in a Sprint plus all work completed in previous Sprints packaged into a build that can be demonstrated to the client for approval

The Development Team work in conjunction with the Product Owner and Scrum Master to deliver a shippable product Increment by the end of each Sprint. The product is presented to the client and any changes required are noted and agreed with the client with regards to schedule and the next sprint is planned. This cycle continues until the end of the project.