Everything flows, even for Agile and the Waterfall method?
For the annual “State of Agile Survey” users of Agile methods were questioned about their experience with and the benefits of the process. This recent report also raises questions that are gaining traction with Agile Manifesto authors such as Andy Hunt.
It’s been 14 years since the publication of the Agile Manifesto. The expectations that appeared as a consequence of this lightweight working philosophy seem to be moving towards a downward trend, thanks to proponents of the method now questioning whether the expectations were justified in the first place.
After the motivational push for the adoption of Agile, the 9th Annual State of Agile Survey has revealed that about 53% of the approximately 4,000 participants surveyed believe the switch provided their team with a productivity boost. Susan Evans, an author well versed in Agile project management, questions whether these expectations are actually plausible in terms of increased productivity.
SEE ALSO: Agile videos across the spectrum
As a contrast to the Agile approach, Evans tried the Waterfall model. These methodologies are rather different, with the Waterfall method requiring departments to follow a pre-determined production plan. Step by step and piece by piece, the final product is assembled, to ultimately deliver an absolute product in accordance to the agreed time and quality set by the client.
Panic under the Waterfall
Under the Waterfall method, development teams get a time frame, such as six to nine months, to produce software ready for production. This leads, as Evans says, very plausibly to different developer working speeds in the team and their daily work. Initially, production pressure and urgency are perceived as quite low. Teams are relaxed and relatively calm.
Changes start to crop up after three to six months. Miscommunication between the teams come to the fore, as well as management, transparency and project status all becoming problematic for most participants. Finally, after seven or eight months, the deadline appears threateningly on the horizon. Pressure is turned up full blast amongst all stakeholders, resulting in a panic.
Work intensity increases exponentially, teams are required to put in more overtime and developers are working under circumstances of extremely high pressure; this results in the production of inferior code. Poor standards of work are a direct result of the enormously stressful working conditions, which also leads to dissatisfaction, declining morale and in extreme cases, a total dissolution of the team.
Become Agile and everything flows?
As we see the above process failing, we remind ourselves of some of the principles of the Agile Manifesto:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Business people and developers must work together daily throughout the project.
Working software is the primary measure of progress.
Obviously, all the above mentioned problems in the Waterfall model can be avoided with adequate implementation of certain Agile principles. For Evans, the workload and productivity pressure consistent with the Waterfall method (depending on the ratio of product status: timeframe) means that an Agile approach would be more appealing. So Agile follows the motto of pre-Socratic Greek philosopher Heraclitus in “Panta Rhei” or “Everything flows”.
In these scenarios, periodically completed product units that are produced and delivered at a constant intensity of work reaps better rewards. Team members remain motivated because they’re not subjected to working under stress, with boredom also somewhat cured due to the constant workflow. As a testament to their own sense of achievement, they write and deliver high-quality code, which they actually care about.
From the results of the State of Agile Survey and the still popular Waterfall model in mind, Evans logically concludes that most respondents confuse increased productivity with optimised labor intensity. For example, those who aim to maintain constant working hours and a constant level of quality in the team for greater job satisfaction should consider Agile an important factor in achieving these goals. After all, all employers would want to keep top developers and for Evans, this is the real reason that Agile is more productive than the Waterfall model.
Agile in the eye of the beholder
Contrary to the State of Agile survey results, confusion and disappointment still lurks in the Agile movement. The theme of constant work with regular output has had to face Andrew Hunt’s objections to the stubborn nature of those who follow Agile “rules” to their most extreme. Without stable and transparent alignment to a project’s status, the zealot’s path can quickly lead to internal disagreements and external obstacles of all kinds.
Evans’ examination of the survey results suggest that not only is Agile still a topic for discussion, but the perception of the framework is also a continued point of contention. Both Agile and Waterfall offer room for misunderstandings and false expectations of finding team production salvation, with the worst case scenario being project failure.