The dawn of the digital age begot a myriad of new tech startups in the world. This growth is especially present in Berlin, where a new startup is born every 20 minutes. However many of these startups, in Berlin and elsewhere, fail because of the idea that a complex product, such as an app, can be successfully created after careful planning and ideation.
A method of taming the complexity of software development was introduced in 2001, when seventeen software developers wrote and signed the “Agile Manifesto.” This manifesto would revolutionize the way in which software was made, and the principles described therein were written in support of four important value shifts:
Individuals and Interactions over processes and tools; Working Software over comprehensive documentation; Customer Collaboration over contract negotiation; Responding to Change over following a plan. In the years that followed, these four principles led to a number of Agile project management frameworks such as Scrum and Kanban. As a consequence, many companies shifted from the traditional “Waterfall” approach, a cascade-based management system, to one of these Agile approaches.
However, despite the Agile Manifesto being around for almost two decades and the accomplishments of the startups that employ it, some business owners and project managers retain a Waterfall framework for their software development. In this blog post, we will go over the key differences between Waterfall and Scrum, the most popular Agile method, and explain why Scrum is the better choice.
In Waterfall project management, a production plan is written which includes the application’s features and details each of the development phases and the project timeline. The app is designed, built, tested and finally deployed, all before the final deadline. This may sound like a sound way of developing software however, it neglects to incorporate important steps that greatly contribute to the product’s success.
One of the biggest issues of the Waterfall approach is the inclusion of customer feedback at the end of development. The Waterfall developers gather all necessary information about the customers during the early planning phase, and use it to define a list of product features. Whether or not they meet the customer’s requirements will be found out after the application is finished and deployed. By that point, the damage is already done: important features that the developers did not consider during the planning phase may be missing from the final product, and features that the developers thought would be important may in fact be useless.
Another issue of the cascading nature of the Waterfall method occurs when an error is found to have been made in a previous stage, as it can’t be easily undone without risking deviating from the development timeline. For instance, when a design error is discovered during the testing phase, it must be corrected by going back to the drawing board and restructuring/rewriting part of the application. This typically causes delays which is often compensated by “code crunching,” an extended period in which developers work overtime to meet the previously defined deadline. This is problematic because code crunching harms morale in that it infringes upon a healthy work/life balance, as well as harms the quality of work because of intensified time constraints.
Scrum, the most popular Agile framework, is empirical in nature. This means that decisions are made based on knowledge that comes from experience and observations. The product that is being developed is iteratively tested in the market through what is known as the minimum viable product or “walking skeleton.” Assumptions about market demand are made to fail as early as possible in the development process so that the product’s development strategy can be adapted and result in a product that is catered to user needs.
In Scrum, development is done in one to four week long “Sprints,” though two weeks is most common. A Sprint is a time window during which a usable, and potentially releasable product increment is created. Before a Sprint starts, the development team estimates how much work from the product backlog, a list of feature descriptions ordered by relevance, can be completed during the Sprint.
During this planning phase of a Sprint, the developers estimate how much effort a given feature requires in order to finish it according to a shared “Definition of Done”. The amount of effort is assessed by attributing “effort points” to the features. After a number of Sprints, the team becomes familiar with how many of these effort points can be feasibly achieved in a Sprint, and how many sprints are needed before the final product can be released.
At the end of a Sprint, the product increment is tested against the feature descriptions during an event called the “Sprint Review.” In this review, the increment is shown to stakeholders who are typically comprised of end-users/clients. These stakeholders then have the opportunity to give feedback and influence the direction of development, which optimizes product development and increases the final product’s value.
In summary, the Scrum development philosophy is different from that of the traditional Waterfall method in three important ways. First, the release date of the final application is based on the team’s rate of development, which is measurable in every Sprint. This realistic approach to deadlines manages expectations and keeps the quality of the developers’ output high by adhering to a common “Definition of Done.” This is different from the Waterfall method, in which the deadline is set before development starts and does not take into account the development team’s speed, which in turn often leads to code crunching.
Second, the end-user is a stakeholder that can influence the final product. In Waterfall, the end-users are not part of the development process and see the product only after it is finished. Features of the application imagined during the Waterfall’s planning phase are rarely all-encompassing and often includes features that the user does not need or want. In Agile, by immediately including important end-users/clients in the development process, the direction of the development can be influenced so as to maximize product value for the customer.
Finally, at the end of each Sprint, a potentially releasable product increment is created which can be released as part of the minimum viable product. By doing so, the product can already deliver value before it is in its final form, potentially creating a revenue stream that may help to fund the product through to its full completion.
18 December 2024
10 June 2024
