Agile or Waterfall: Balancing Legal and IT needs with Acceptance Criteria

Jason Bess
Corporate Legal Director

Every successful company, regardless of industry, must be able to effectively implement various IT projects. Whether the purpose of a project is customer-facing or for internal use it has to work as envisioned. The success of any project depends on the ability of a development team to meet their client’s needs. The attorney assigned to such projects must understand the parties’ goals,  how the work will be completed in a timely manner, how to evaluate risk associated with implementation, and draft a contract that foists responsibilities and risks appropriately among the parties. While contracts cannot automatically manage clients or vendors, having an objective acceptance criteria (AC) will prevent larger disputes and lead to quicker remediation efforts between the parties.

 

Project Methodologies

Before discussing the AC, each attorney should know the preferred project methodology their company uses. While not exclusive, most IT teams utilize an Agile or Waterfall methodology. The Agile methodology is a practice that fosters continuous iteration of development and testing during the development process. It separates the project development lifecycle into sprints. Agile allows for development and testing activities to be concurrent and simultaneous. A great feature is that it allows for more frequent communication between customers, developers, managers, and testers. In contrast, the Waterfall methodology dictates development is followed in a sequential order ensuring a development team only moves to the next phase of development if the previous step is completed correctly.

There are advantages and limitations for each method. Agile is client focused. The client is continually involved throughout development. Agile usually ensures the quality of development is maintained because it is based on incremental progress. As a result it generally reduces the risk in development. But Agile does have its drawbacks. Usually an expert is required to make decisions throughout the process and a project can easily be derailed if the project manager is not clear on outcomes or disengaged from the project.

Waterfall is the easier to manage because it is based on a sequential order of deliverables dependent on the last. Therefore, each  development phase has specific deliverables with well-document results. Waterfall is also more adaptable for shifting team members. However, if requirements are not clear from the outset, or requirements change,  Waterfall’s lack of flexibility can be problematic.. Because it is sequential, it is timely and costly to make changes to previously completed phases. Usually too, once testing starts development is deemed to be complete. This can be a significant disadvantage as when IT projects inevitably encounter configuration issues later in the projects.

Writing your contract does not necessarily need to be dictated by your development team’s preferred approach. An skilled attorney with an aptitude for IT can draft an Agile-Waterfall hybrid scope. Outside of development teams transitioning from Waterfall to Agile, a hybrid is preferred when a project has a set budget and delivery date but would benefit from Agile’s fast design, analysis and planning. An attorney preparing a hybrid contract should look at the project from both the enterprise perspective and the actual development (requirements, design, implementation). Specifically naming key deliverables, even with set dates, allows for checkpoints. The development or project then lends itself to specific project levels utilizing Agile methods. For example, a named deliverable such as “Deliver New Application with XYZ functionality on [Date] (‘collectively D1’)” fits neatly into an enterprise goal. Within the same contract, building out the functionality, user designs, handling necessary migration, or specific developmental work must be addressed. The simplest, but not the only , way is to state further “D1 will be provided in an iterative manner divided into 2 week sprints wherein the parties will determine the acceptance testing for each sprint.” There are many ways to create a hybrid approach. The correct approach will depend on your specific problem and determining which methodology fits best.

 

Determining and Drafting Acceptance Criteria

Whether your development team is using Agile, Waterfall, or a hybrid methodology your contract must address the AC. The AC details how the client will accept the goods, the specifications of phases (i.e., deliverables that must be met in order to be accepted), a client’s opportunity to test, and how rework will be completed. Developing a proper AC can be difficult because it is unlikely a project team will know exactly what they will be asking for during a sprint down the road. The attorney too may have difficulty determining what amounts to a proper code error rate or what each sprint will entail throughout the project.

In drafting an acceptance criteria, you must be mindful that its purpose is to define how a particular feature will be used from an end user’s perspective. AC quickly establishes scope boundaries and guides development; it directs developers when applications or phases do not work as intended and ultimately describes what will be verified during acceptance testing. Your AC will depend on what is being developed – is it functions, processes, specific user tasks? Or is development focused on non-functional conditions such as design elements? Does an application need to meet a specific performance level? Though not an exhaustive list, AC should be based around user experience, impact of user stories to other features, intent of a feature of system, and performance concerns.

In working with your development team, you must aim to gather specifics that allow you to write an AC before any works begins. Should development fall short of your client’s expectations you can point to the mutually agreed to AC in order to demand that work be redone or simply withhold payment. Rarely are conditions ideal. AC is usually dynamic and modified over the course of a sprint as user stories are developed and modified.

There is no one way to write an AC. It is especially difficult to draft an AC that can account for all phases and requirements weeks or months in advance. If you are unable to name specifics, the AC should, at a minimum, address that the parties will agree to develop: 1) AC for each deliverable, phase, or sprint; 2) testing procedures and a plan for acceptance testing that address programming errors and functionality; 3) the time frame to complete acceptance testing; 4) time frame of production processing which shows the deliverable satisfies the named AC; and 5) time frames to remedy any errors or deficiencies Also keep in mind nothing prevents the parties from incorporating the agreed to AC used for each sprint into a statement of work.

In short, be sure to include AC in your contracts in order to solve for multiple problems at once. AC will prevent ambiguity, improve quality assurance, and document the expectations for your client. Whether your IT is utilizing an Agile or Waterfall methodology be sure to choose the best format that allow you, the attorney, to minimize risk and allow for quicker resolutions during disputes.

 

Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the official policy or position of AutoZone

Tags: Drafting Clause, Agile, Waterfall

Contributors

Jason Bess
Corporate Legal Director

You may also like

Y-Combinator SAFE Agreement Briefing

Matias expounds on his teardown of the Y Combinator SAFE Agreements, discussing why this document is important and some of the common practices to watch out for.

Cannabis Simple Agreement for Future Equity

The primary goal of the cannabis Safe is to address the regulatory complexities that come with raising money in the industry. For example, depending on whether a company is raising a priced round (i.e., selling equity at a fixed valuation) or a convertible security round (i.e., a Safe or convertible note), each triggers different regulatory reporting and/or approval processes.