One of the most abhorred phrases in the software development industry is the "death march." This term characterizes the period of time at the close of a production cycle in which developers and testers must ramp up their efforts to meet a release deadline. Often, the increased workload presented by these instances places an incredible amount of stress on team members. Under traditional waterfall-based operations, death marches have been a relatively common occurrence, particularly when projects are given unrealistic release time frames.
The most recent – and possibly famous – example of such unfeasible development demands is the troubled production schedule outlined for the Obama administration's HealthCare.gov website. As noted by TechRepublic contributor Ken Hardin, although the precise details surrounding the development process remain unknown, it is generally agreed upon that government officials outlined a production schedule that contained unrealistic goals and benchmark dates. Under these conditions, developers and quality assurance members must fully dedicate themselves to the task of working out the kinks and addressing as many performance flaws as possible. In many cases, these efforts fall short, resulting in a faulty product.
Alleviate development stress with Agile
Because of the high release rate of buggy software, death marches are often seen as the mark of an ineffective organization. When teams adhere to the traditional waterfall approach to software development, these late-period pushes will likely continue to occur sporadically – if not on a regular basis. ReadWrite contributor Matt Asay stated that although waterfall methodology is marked by a long development process that incorporates initial planning stages, that does not ensure success for the finished product. By moving to an Agile approach, businesses essentially embrace the inevitability of flawed software, placing more emphasis on continual development and release than a single, laborious production cycle.
"Agile assumes that IT projects often fail, despite our best intentions," Asay wrote. "It's therefore a way to minimize the cost of failure by making the software development process highly responsive to change."
Accepting that software cannot be 100 percent error-free at some arbitrarily determined point in time will free developers and QA professionals of the unrealistic expectations placed upon them by their superiors. With Agile, death marches should evaporate, as all of that nail-biting testing will be peppered throughout the development process instead of delayed until the very end of production. In addition, development teams will be more prepared to incorporate suggestions from upper management or consumers regarding features that should be included in a finished product. This way, software can be changed on the fly without causing a great deal of upheaval or throwing development off track.
Citing an executive from a large financial services organization, Asay explained that the ultimate goal of Agile is to create more stable software products. Often, the release of a new software package – either for internal business use or external customer consumption – is treated as a major event. Under these circumstances, end users rightfully expect a fully functional product with minimal – if any- performance issues. These lofty demands are often difficult to meet. The Agile approach of continual release and alteration can facilitate a much more realistic quality of service, offering users a workable application that may need some minor fixes to be made. With each new release, IT members can further iron out any lingering issues and work toward a more effective product.