Does Agile Make Developers Work Like Dogs?
The Waterfall model has become the whipping boy of 20th century software development. The idea that analysis, development, and testing are separate, distinct phases of a development project, where time must be allocated to each, and one must be completed before the next begins, is history. Although it was seldom actually practiced, with time and budget constraints compressing schedules and steps, it was often an ideal to shoot for. There was some integrity in it, as I recall. For a long time, we regarded the model as a sign of care and craftmanship. Unfortunately, this approach made it easier for a company to head in the wrong direction for too long, masking problems in the development process until it was too late to fix them. It could also squander resources on software that, upon completion, was functional but irrelevant to the market and it’s users.
The era of quick turnaround is now upon us. It’s harbingers include Agile, Scrum, and Continuous Integration and Deployment. The terms are new, stories and points instead of requirements and estimates, but the aim is the same: produce software products as quickly and effectively as possible. For anyone who is paying attention, Agile is really just Waterfall on a compressed time schedule. Think of Agile as lots of Baby Waterfalls. We’re still gathering user needs, translating them into specifications, coding, then testing against the specs, but we’re doing it in two to four week time boxes instead of three to six month ones.
With no points for craftmanship or burndown rates on quality, software has become life in the fast lane. Everything, all the time. With daily check-ins, a culture of sprints, and a clear agenda of speed over quality, let’s be careful that Agile doesn’t become just another fast-food corporate construct to build garbageware and make good developers work like dogs. People have burndown rates, too.