Having spent a good part of the past several months talking to companies about agile methods and what it means to be agile, we have found people to be very receptive to the benefits of working in ways designed to emphasize communication, collaboration, working software, and embracing change. At times, however, near the end of a discussion in which a potential client truly seems to be “getting it”, they will ask a question or two that shatters that illusion. Usually it will be about budget and/or project definition and will often involve a request for a proposal in which the cost, time frame, and features to be included are all fixed.

We are getting pretty good at talking people away from that ledge but we still aren’t perfect. The simple answer we could give them would be that because they desire to fix cost, time, and features, there is only one place that remains to flex: quality. If there is anyone who hates cutting corners and producing an inferior product more than software developers, it is clients who rely on such software. Why is it, then, that so many companies believe that you can attempt to hold all the variables of a project constant?

We can talk until we are blue in the face, quote industry experts who have been through the trenches, and point to numerous failures in RUP or waterfall projects we have been a part of but nothing seems to work as well as pointing to big, respected companies that are doing what we suggest. Toyota (practically invented it), Netflix, and Google all use agile methods to accomplish great things. Now we can add Adobe to that list. A recent interview with lead architects at Adobe explains how they changed the development cycle for the development of the forthcoming CS3 product suite and underscores the point about how quality often gets squeezed out of traditional software development projects.

The change we made was going from a traditional waterfall method to an incremental development model. Before, we would specify features up front, work on features until a “feature complete” date, and then (supposedly) revise the features based on alpha and beta testing and fix bugs. But we were scrambling so hard to get all the committed features in by the feature complete date - working nights and weekends up to the deadline - that the program was always very buggy at that point. We’d be desperately finding and fixing bugs, with little time to revise features based on tester feedback.

At the end of every cycle, we faced a huge “bugalanch” that required us to work many nights and weekends again. Of the three variables: features, schedule, and quality, the company sets the schedule and it’s only slightly negotiable. Until feature complete, we could adjust the feature knob. But when we hit that milestone, quality sucked and we had only a fixed amount of time until the end. From there to the end, cutting features was not an option and all we could do was trade off our quality of life to get the quality of the product to the level we wanted by the ship date. We’ve never sacrificed product quality to get the product out the door, but we’ve sacrificed our home lives.

Of course, Adobe is going to say the only “flex-point” in the system was the work-life balance of its employees and that their new product is of the highest quality, but that cannot be true. The late nights and stress involved in this type of “cram-it-all-in” development style inevitably causes a degrading of quality over time coupled with the opportunity cost of additional features (and the underlying value to the business they represent) that cannot be created.