This blog will be highlighting waterfall and agile workflow approaches in software development. Starting off with a brief history lesson. The original approach to software development was known as waterfall, and it was created in the 1970s. A sequential organisation, thorough documentation, and little client engagement are its three guiding principles. Initially, it was mostly utilised by non-software sectors like manufacturing and construction.
There were problems with waterfall where little client engagement lead to delivery of a system, after a long development cycle, that did not match the clients expectations. There were also issues with poor requirements gathering lead to change requests and a tedious circle of documentation updates.
In order to solve the flaws of waterfall, agile was created in the early 2000s. Agile is characterised by flexibility, significant client interaction, and an iterative process. It is frequently employed in the software sector.
Over the last several years there has been a strong shift to a more agile software development methodology from a traditional waterfall model.
Setting project requirements
Since product requirements can be changed at any point during the software development process, even after planning is complete, agile methodologies have an advantage over waterfall methodologies. The project requirements are established at the outset of a waterfall project. Changes to waterfall requirements are generally done using change requests which can result in changes to the original requirements specification or can be consolidated as an addendum of change requests.
Consider a situation where a business uses agile project management. They learn during product development that the function they worked on depends on an outside service, the cost of which has increased significantly, and over which they have no influence. Agile teams would perform a pivot to find a different solution, whether it was a ready-made or customised one acquired from a different vendor.
Such a turn of events would result in a change to requirements and update of documentation in waterfall. In contrast to waterfall, agile prioritises client and user demands over documentation.
Product development planning and scope
When applied as a single project that is divided into phases, waterfall represents a linear process. Before starting a new phase, the prior phase finished or close to finishing. Phases are not usually revisited except using change requests or modification of existing documentation.
The flexibility of agile over waterfall is one of its main advantages. Sprints serve as the foundation for product development in agile. Contrary to waterfall development, which calls for defined product requirements with no room for modification, product changes can be made at any point during the product development process as changes are discovered.
With waterfall, everything is predetermined before the project begins and is fixed in terms of time, cost, and scope. This has the advantage that since all requirements are documented then, in principle, it is easier to estimate a project accurately. Since agile methodology encourages detail to be teased out in each sprint, rather than in a large detailed requirements specification,
Approach to testing
Our comparison of agile and waterfall project management should also take into account the stark differences in their approaches to testing. One of the essential elements of agile is testing. Every sprint includes testing, which enables programmers to find and fix any flaws as soon as they are found. This has the effect of delivering products more quickly and saving a lot of money.
Testing comes after the build process in waterfall, which can have major consequences, especially for larger-scale projects. Early development mistakes won’t be discovered until the project is finished, which will lower the quality of the final product.
Customer involvement in product development
By deciding on agile, stakeholders are heavily involved in the creation of the product. They work as a team with the development team to ensure the product meets expectations. Customer satisfaction is prioritised heavily in agile, and stakeholders are involved at every stage of the development process.
Contrarily, waterfall restricts client interaction to the beginning and the end of the development . The customer’s role in the project concludes, for a period, with the provision of thorough project requirements and resumes at the end with user acceptance testing. This frequently leads to misunderstandings and has a detrimental effect on the calibre of the final product.
Team structure: agile vs. waterfall
Large, rigidly structured, and with each team member assigned a defined task, waterfall teams frequently consist of many people. Each team member is responsible for a certain step of the development process. The project’s outcome is up to the project manager, who serves as the project’s leader. As a result of each person concentrating largely on completing their own assigned job, less teamwork may result.
In contrast, agile teams are frequently small and have more flexible skill sets; for instance, a developer may simultaneously be a tester and an analyst. Even though the project manager typically serves as the project leader, the agile team holds everyone accountable for the project’s success. Agile fosters a culture of teamwork, and all problems are solved via consistent, efficient communication.
Communication
Excellent cooperation requires effective communication. Regular project progress communication is a top priority for agile teams. The entire product development process involves the client.
Compared to agile, waterfall communication is less structured, constrained, and irregular. The requirements phase is when the project manager and the client agree on the product’s requirements, and this is when the majority of communication takes place. The customer exits after this stage is finished and only returns when the project is ready for user acceptance testing.
Agreeing on the budget
One of the most important aspects in the product development process is setting the budget. The scope of work and the budget is established upfront and typically cannot be changed in a waterfall project. Since requirements are defined in detail with waterfall then estimation of the project should be more complete. The agile technique emphasises adaptability, and budgeting is no exception. The budget can be determined using the quantity of sprints but features developed may not be guaranteed. Since agile methodology often determines details as the project progresses then the budget and features have to be flexible. It is very difficult to run a fixed scope and fixed price project in agile without determining the requirements in detail up front. This is one of the disadvantages of agile.
Conclusion and the Real World
Which is better waterfall or agile for software development?
Agile is now the most common software development methodology in use at the current time. It is flexible and allows regular releases to stakeholders so the development team and clients stay aligned to what is being achieved. However it has not really solved all the problems associated with software development and has introduced some of it’s own.
Many organisation want a set of features for a particular budget in a software development project. Waterfall documents all these features up front, in detail, and then a detailed estimate is produced. Traditionalists would say that waterfall was too strict and did not allow for change, which invariably happened. Since waterfall can give up front estimates and a fixed set of features it is easy to look at the poor performance of waterfall in terms of projects delivered over budget.
Agile is perceived as being better with less up front documentation and less overruns. However since agile does not have a fixed set of features, or has at least some flexibility to ‘descope’ features, then it may be easy to show agile as being more successful at delivering projects in real life when in fact it is simply delivering the features that can fit into the budget for the project. Imagine an agile house builder who gives you a budget for building your new home only for you to find out that they ‘descoped’ the roof in order to fit the budget.
In reality we have found that having well defined requirements allows better setting of budgets up front. After requirements, an agile approach to implementation, can keep stakeholders involved in the development cycle.
Learn more about the digital transformation solutions provided at Pulsion. Our team has extensive experience in cloud migration, custom software development, mobile app development and artificial intelligence solutions. This ensures we are perfectly placed to understand your project and offer the most appropriate solution. Partnerships with Amazon Web Services and Microsoft ensures we are able to offer the best technology solution for your needs.
We would be happy to discuss your digital needs with you, it’s what we do, so get in touch!
