Agile vs Waterfall
Photo by Collins Lesulie on Unsplash
Photo by Scott Graham on Unsplash
“There is nothing so useless as doing efficiently that which should not be done at all.” — Peter Drucker
Update - Aug 2021
Here is a great article on the tussle between Agile and Waterfall methodologies. As a long-time fan of the Toyota Production System it is a fascinating read.
Waterfall
In the past, software engineers used the Waterfall model to summarize the software development process. Simply stated, the Waterfall model is:
System and software requirements: captured in a product requirements document
Analysis: resulting in models, schema, and business rules
Design: resulting in the software architecture
Coding: the development, proving, and integration of software
Operations: the installation, migration, support, and maintenance of complete systems
The problems with using the Waterfall models consist of (but are not limited to):
Your client definitely does not know exactly what their requirements are at the outset of the project.
Software designers may not know exactly how long it takes to implement a novel feature.
In an attempt to deal with the shortfalls of the Waterfall model some enhancements were proposed. These include Extreme Programming (XP) and Agile software development. We will deal with Agile development in the next section since it has achieved buzzword status.
Agile Methodologies
Agile was made popular by The Manifesto for Agile Software Development. It states:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
It is arguably more resilient to the changing winds of customer satisfaction, it is welcoming of close cooperation between customers and developers with (ideally) very short feedback loops between the two groups, and regular reflection by software developers on how they can improve.
Agile is no panacea though. Critics of Agile state (among other things):
It lacks an overall product design due to its de-emphasis on documentation. This is a key feature for things like aircraft systems which require extensive manuals to operate.
Agile often employs frequent “standups” in which teams are required to literally stand in hopes it will motivate them to be brief in their summaries. This software engineer has observed that while some folks are comfortable with brevity, others will wax eloquent into the ingeniousness of elegance of their particular design and waste time doing so. Others insist on injecting problem-solving into the standup meetings in front of the entire team — even when it would make more sense to break off later into smaller groups to have these discussions.
A focus on delivering new functionality can allow technical debt to increase. In the research world, technical debt is a constant battle. According to Wikipedia, technical debt is:
… a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.[2]
As with monetary debt,[3] if technical debt is not repaid, it can accumulate 'interest', making it harder to implement changes. Unaddressed technical debt increases software entropy. Similarly to monetary debt, technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) is required to move projects forward. On the other hand, some experts claim that the "technical debt" metaphor tends to minimize the ramifications, which results in insufficient prioritization of the necessary work to correct it.[4][5]
A danger to have too much context switching, again caused by the emphasis of chasing the shiny new feature.
Developer burnouts are a common occurrence on poorly-managed Agile projects. Overuse of the term “sprint” tends to exacerbate these problems.
Pair programming can be a bummer if you get paired with a jerk.
