In the information technology sector and beyond, "agile" software development models have become increasingly popular.
Agile models promise a more customer-centric delivery approach, resulting in more useful and robust software on a shorter timeline than was generally expected from the former industry standard: the "waterfall" software development model. This article will compare the older "waterfall" model to the newer "agile" model, highlight some important considerations for contracting in the agile context, and highlight issues that agile developers and customers may wish to consider as they move their projects forward in the COVID-19 business environment.
Waterfall Software Development
The "waterfall" software development model was once the most popular model for software development and informed the drafting of software development contracts. Waterfall contracting is premised on the idea that the customer is in a position to clearly and comprehensively define their needs in the form of specific project requirements before development begins. That product definition is set out in the contract between the parties from the beginning of the relationship, and is generally not changed (or changes minimally) over the life of the project.
The software development exercise in the waterfall context is linear. It is intended to closely follow well-defined, sequential stages which typically include planning, design, coding, testing and deployment stages. Over the course of the project, the developer's progress is tracked in reference to pre-defined "milestones". Once development is complete, a complete piece of software is delivered to the customer for testing, troubleshooting and eventual deployment.
The main disadvantages of the waterfall software development model are threefold. First, since the customer's requirements are defined at the beginning of the project and since the waterfall model is not particularly responsive to change, the waterfall model can sometimes result in delivery of software that does not adequately meet the evolving needs of the customer despite conforming to the project requirements. Second, as a general matter, software development does not lend itself well to defined timelines. Failure is a part of the software development process and holding developers to strictly defined milestones fails to adequately account for the nature of the software development exercise. Finally, the waterfall model can pose problems for customer testing, because at the end of the development phase a piece of software is delivered to the customer and is expected to be thoroughly tested in a relatively short time. This can cause defects to go unnoticed and unamended within the prescribed warranty period.
Agile Software Development
In recognition of the fact that contract disputes make developers and customers unhappy in equal measure, and of the practical realities of software development, the agile model of software development was born.
Unlike the waterfall model, the agile model does not presuppose that a customer can accurately define, or even know all of its requirements for the software before development begins. Accordingly, the agile model dispenses with pre-defined software requirements and focuses on defining the high-level objectives of the development project. Typically, "user stories" are developed to help define in functional terms what a customer would like to be able to do with the software to help it achieve its high-level objectives. For instance, a customer may decide one of its high-level objectives is to keep track of the number of widgets in its warehouse. The customer may then explain its functional requirements as a user story, told from the perspective of customer personnel actually tasked with keeping track of the number of widgets in the warehouse. One potential user story may look like this:
The user stories or other items in the backlog are then completed
in short, iterative "sprints" by the developer. At the
end of each sprint, the developer usually delivers a working piece
of software that aligns with the user story or other requirement it
is based upon. That working software can then be tested by the
customer without having to wait for the completion of the entire
software product. If the software delivered at the end of the
sprint fits with the "definition of done" agreed to by
the parties ahead of time, then that item is finished and removed
from the backlog. If it does not, the customer will typically give
the developer feedback, and the item will be returned to the
backlog to be worked on further. All of the user stories are
catalogued in order of priority in a document usually referred to
as the product "backlog", which serves as a running
"to-do list" for the developer. The items in the backlog
can be shuffled around or added to in accordance with the
customer's changing needs.
These concepts drive the agile software development model and generally result in a highly customized and robust, well-tested software product that aligns well with the customer's business needs.
Considerations for Agile Contracting
It is evident from the above descriptions that the underlying concepts of waterfall and agile software development models are very different from one another. Accordingly, contracts governing each kind of development model should be drafted to account for these differences. Since development contracts of past were generally based on the waterfall model, the lawyer's task in agile development contracting is usually to adapt or redraft contracts to account for agile development concepts. Below are some key considerations when contracting for agile software development:
- Define a "Minimum Viable Product" or "MVP": Since agile development contracts generally do not contain a defined set of system requirements that the finished software product must meet, it is useful to define the "Minimum Viable Product" the customer will accept in satisfaction of the contract. This represents a compromise between the traditional list of system requirements from the waterfall context, and an expansive catalogue of user stories that might bog down completion of the project.
- Define robust governance structures. The agile development model is heavily reliant on efficient collaboration between parties. Accordingly, it is important to clearly define the roles of key individuals ahead of time, as well as expectations for timely and productive communication and dispute resolution. Failure to do so may result in the project lagging or losing focus.
- Rethink warranties. In the waterfall context, it is common to have warranties that last months (or even years) following delivery of the final software product to allow adequate time for the customer to discover defects in the complex software product that is developed. However, as explained above, the agile development model allows for targeted, intensive testing of software over the course of the project, which should allow diligent customers to discover defects. The rationale for including long warranty periods is therefore significantly attenuated in the agile context. Additionally, if customers and developers are collaborating closely such that customer personnel are involved in development activities, developers will often resist providing warranties on the resulting work, because by doing so the developer may, in effect, be accepting responsibility for the work of the customer.
These are just a few considerations that should be kept top-of-mind when contracting for an agile software development project. The radical shift in thinking inherent in the agile approach necessitates a number of departures from concepts found in more traditional waterfall-oriented contracts. We caution proceeding with agile projects without fully addressing how agile concepts will be integrated into the contract governing the project.
COVID-19 and the new cost of collaboration
COVID-19 has drastically changed how people work. Many business arrangements, including agile software development, presume that people can easily get together, fluidly communicate and collaboratively problem solve. For the time being, that presumption is no longer tenable. Telework, video calls and email strings are standing in for the traditional office and human interaction that drives most work places. People work on different schedules (if they are working at all), use less effective communication tools and are often trying to follow business processes that were simply not designed for the current business environment. This means that collaborative processes may take longer than they did before. When things take more time, it typically means they cost more money. The difference between the normal cost of collaborative enterprise in the pre-COVID-19 environment, and the new, higher cost of collaborative enterprise today, has been referred to by some as a "collaboration tax".
But who bears the cost of this "tax"? That will depend on the particular terms of the contract governing the project. For instance, if the contract provides that the developer will complete a user story on a fixed-cost basis, the added time it takes to complete the user story will drive up the developer's costs, but those costs will not be passed on to the customer. On the other hand, if the customer has agreed to pay for the development project on a time and materials basis, it may cost the customer more than originally planned to achieve the desired result.
One way to mitigate the risk of cost escalation attributable to the COVID-19 collaboration tax is to re-design the conventional work processes. For agile contractors, this means taking a critical look at the governance structures guiding agile software development and looking for ways to make them more efficient. What is appropriate will vary from arrangement to arrangement, but the ultimate goal should be promoting efficient, productive communication while eliminating low value-added interactions and processes.
The IT contracting professionals at MLT Aikins have the depth of experience with waterfall and agile contracting required to help your business identify how your project contract may unexpectedly drive up costs, how those risks may be mitigated and how your contract may be amended to account for today's business environment.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
