What is Agile?
Agile, from the word Agility, is defined in English as being able “to move quickly and easily” which is the core purpose of the development of the Agile project methodologies. The Agile methodology originated for software development as a new way to manage delivery and create a quicker output. Many software development projects were failing or taking much too long to complete, and industry leaders realized they needed to find a new, innovative approach.
Leaders and representatives from organisations delivering projects through Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, feature-driven development, and pragmatic programming came together and signed the Agile manifesto. This was in 2001, and was created to find an alternative to current methods of delivery for software development.
In todays world of projects, Agile is used across multiple industries from manufacturing, product development and logistics. Agile has allowed for the continuous improvement of project delivery throughout various markets, sectors and industries.
What is Waterfall?
The Waterfall method of delivering projects got it’s name due to the way tasks were arranged on a Gantt chart. This method of project delivery focuses on a linear approach of delivery, from detailed planning, closed development and a ‘big bang’ approach to final delivery. On a Gantt chart the arrangement of tasks looks similar to a waterfall. Waterfall is the traditional method of project delivery, and which methods like Prince2 were founded upon. Many projects still use the Waterfall methodology today, but a lot of project professionals refer to this method as outdated.
A lot of projects are transitioning to a more hybrid model of using both Waterfall and Agile, mainly because some organisations or industries cannot completely shift to the Agile methodology. This can be down to skill and experience, but also the specific industry cannot operate that way.
Top 5 differences between Agile and Waterfall
1. Approach
Waterfall, as described above, is a sequential and linear approach to delivering projects, with still a high number of projects globally (usually outside of the IT sector) still being delivered in a Waterfall method. However, with Agile projects we are able to progress iteratively and incrementally which enables for quicker adaption to change and can significantly reduce the risk of failure.
An example of this with both approaches is when you want to design, develop and deliver a car. In a Waterfall method, you would design, plan and build the car in detailed linear stages and would usually only find issues with the design or build during test. There would be a long period between issue detection and fix. Also, key stakeholders are not close to the project so cannot see the progress. Whereas in an Agile project, the key stakeholders work much closely and change is invited early in the process. So the first step would be to plan the must-have features, then test those. If there are any issues, these can be dealt with quickly without incurring too much cost.
2. Requirements
Waterfall projects have fixed requirements that are defined at the beginning of the process by the key stakeholders and project team. The teams would usually agree that the scope of the project (based on the requirements) is then planned. There is very little room to change these requirements once the project gets started. Agile however, tends to have a more flexible approach when it comes to requirements and can be easily adjusted (with the right controls) throughout the project.
3. Planning
Planning is a detailed exercise at the start of the project in Waterfall methodologies, as the whole project plan needs to details exactly each activity right from beginning to end. This helps to plan resources, budgets and provide expectations to the key stakeholders. However, the biggest risk here, is that there is no room for change. In Agile projects, planning is less detailed and more focussed on adaptability and responsiveness to change. In SCRUM, iterations are planned through sprints (2-4 week windows) which allow delivery of features based on benefit valuations. The difference here is that these sprint plans can be changed very easily.
4. Deliverables
The primary deliverable in Waterfall is usually presented as a finished product at the end of the project. As stated before, this doesn’t allow for feedback to be gained by the key stakeholders which can be problematic, especially if any of the original features are no longer viable. The Agile method of delivery enables early view of product development and feedback from key stakeholders. This allows for quick changes to be made to development plans and designs based on stakeholder feedback, which in turn enables greater success of the overall project.
5. Team structure
Hierarchical teams with clearly defined roles and responsibilities are the typical structure of a Waterfall project. This is good, as lines of communications are clear but don’t always work practically. However, problems occur when things go wrong, as the bigger the hierarchy, the bigger the chain of command to the decision makers. Agile teams are given more responsibility and accountability when it comes to decision-making. There are more collaborative team structures within cross-functional teams who share responsibility.
Should I stop using Waterfall?
The answer in our opinion is, no! Institutions like PMI and the APM teach through their certification that it’s not about choosing between Agile and Waterfall because of preference, it depends on three key areas. In Prince2 Agile, the approach to choosing Agile is not by ‘yes’ or ‘no’, but by how much Agile.
Parts of the Waterfall methodology has its advantages for projects in certain industries, and when working alongside components of Agile you create a hybrid world of success. Linear structures give better expectation in terms of project completion. Sometimes in the Agile world it is usually open-ended as to when the project will complete as iterations can be defined as continuous.
Three key areas which should be given thought when deciding between Agile and Waterfall have been explained below.
Choosing Agile over Waterfall
1. Type of project
All projects are unique however similar they may be in nature, for instance developing a simple website is similar, but each website is slightly different. The argument here is that defining a methodology for all simple website projects is productive as everyone is aware of the approach and knows how to work. However, if they were all bespoke large web projects then it is best to consider the methodology for each. It depends on the stakeholders, and also the development and testing teams. There is not one solution for all, but knowing what works for each project will create an environment for success.
2. Organisational culture
Not all organisations are setup for Agile, even though the methodology has been around since the early 2000’s. Organisations today, usually the ones who have been around before the turn of the millennium can sometimes find it hard to switch their working cultures. The role of Agile coaches was born to help companies adapt a more agile approach to their organisations and project delivery. It is worth remembering that if Agile is directed as the method of delivery to an inexperienced team, the project is likely to fail.
3. By how much
As mentioned in the first point it is not always the case of delivering in an Agile or Waterfall method, but by how much of each. Many organisations are seeing the benefits of working in a hybrid methodology, and taking the components of each method that works for them. This only works if there are skilled professionals in each methodology who are able to analyse the situation and make a decision on how much is used of each.
If you are looking to develop the agile maturity of your projects or organisation, then get in contact with us. We can easily show you what we offer and determine if we can create value and future-proof your business engagements.