AGILE, INCREMENTAL, WATERFALL:
Is there a quality difference?

In recent years, a new dimension has been added to the choices that CIOs must make about software development. Besides platforms, languages and development environments, now an IT organization can invest in one of several "proven" development methodologies. The relatively new "Agile" and "Incremental" project structures claim superiority over traditional "Waterfall" SW development in terms of cost, delivery and quality. Critical Logic's technologies and solutions are successfully employed by clients using all three approaches and thus we are carefully monitoring the relative effectiveness of these development methodologies.

Most managers are familiar with the traditional analyze-design-code-test, or Waterfall approach to SW development. This approach emphasizes the specification of requirements and formalization of the design before engaging in programming and testing. The relatively new Agile methodology takes an opposite tack. Development of an application is broken into a series of very small delivery increments, each with very limited functional scope. Each increment lasts two to four weeks. The small scope and limited team size permits requirements, design, coding and testing to occur informally and simultaneously with little, if any, documentation outside of the code. As its name suggests, Incremental development features longer, but still limited project durations and functional scopes than Agile, but still breaks an application development effort into several increments of delivery.

CRITICAL FACTORS FOR CHOOSING A METHODOLOGY

Whatever the other merits and limitations of the competing methodologies, a prime consideration should be the resulting software quality. We measure software quality as the ability to deliver business-useful functionality in very high reliability software (i.e. defect-free), and to do so with a minimum amount of rework. Any of these methodologies can produce high quality software, but none are universally successful in this regard. Here are the factors we have found are critical to selecting a methodology and getting quality results:

Complexity of Requirements. Assess the complexity of what you are trying to automate. When the functionality in a new application can be broken down into small, meaningful deliverables, then Agile development works very well. However, for very complex business requirements a two-three week Agile "sprint" may not give enough time to think through a complex business requirement and implement a meaningful piece of it without a high probability of having to redo it later. If not, then use a longer incremental development cycle. Remember too that some requirements (e.g. tax codes, regulatory changes) are all-or-nothing by definition, removing the benefit to the users of an Incremental or Agile approach.

Complexity of the Organization. How many stakeholders must sign off on the requirements or the release? An evolving departmental web-site might best be done using the Agile methodology. But a web-based loan application needing the concurrence of the legal, audit, and finance stakeholders could demand incremental development cycles to ensure that the requirements are acceptable to stakeholders, well defined and coded correctly the first time.

Test Overhead. With each incremental addition to an application, the new functionality must be tested and the pre-existing functionality re-tested. This means data setup, rerun of regression tests and management of the total test process. While small increments of design and coding provide the development team and user with a greater sense of progress, it can drive regression test costs through the roof and thus remove any quality benefits. Balance the quality costs of frequent incremental releases against the benefit added to the business by each release.

User Tolerance. A frequent benefit of Agile development is that the user sees continuous progress in the development of the application. For many user groups, this is very effective. However the user has to be willing to engage continuously in the development process. Some users want and need this level of engagement. Others cannot or will not tolerate the time demands, in which case the Waterfall methodology or something close to it is a better strategy.

IT'S STILL THE REQUIREMENTS

The most important thing to remember is that none of these methodologies succeed without unambiguous requirements and adequate functional test coverage. Poorly defined requirements and incomplete test coverage generate rework just as quickly in an Agile project as in one using a Waterfall structure. Invest in sound requirements and test solutions, then pick the development methodology best suited to your organization.

Experience the difference of getting it right from the start. Visit critical-logic.com or email moreinfo@critical-logic.com for more information.

Learn More and Stay in Touch:

• To learn about Critical Logic, independent validation and verification, and the Logic Based Development Process, click here
• We welcome your questions and comments. Contact us at: http://www.critical-logic.com