An interesting change has occurred across software development projects over the past several years, which has seen the practice of Agile software development overtake that of the traditional Waterfall model. Rooted in the 2001 Agile Manifesto, Agile development favors greater interaction between technical and business teams, resulting in a more fluid development lifecycle. That is in comparison to the Waterfall approach, which operates on the basis of clear defined stages and objective within the project.

In the past, with a Waterfall approach, a software development project would be scoped out in full, with every detail and eventuality planned out, and with a completion date identified. So when asked “When is the project launching?”, a project manager or stakeholder would confidently reply with a set date, possibly months or years into the future.

With Agile development, the understanding is that not every detail can be mapped out, and requirements may change as the project advances. Agile allows for shifting of goals and deliverables as requirements shift during the development lifecycle. For that reason, work is done in small increments – referred to as sprints – with each sprint resulting in some working piece of code or “minimum viable product” (MVP). So when asked “When is the project launching?”, a project manager or stakeholder will likely not have a firm date, and instead reply “We expect a working version of this piece of the project by the end of the next two-week sprint.”

Due to its fluid nature, contracting for Agile projects can present unique challenges. Careful consideration should be paid to the following areas:

Pricing

While fixed-price models may work well for Waterfall projects with fully-scoped deliverables and resources, fixed-pricing may not align well with Agile projects – although fixed-pricing is still used and here’s an example of a fixed-price agile contract. Stephanie Overby, writing in a 2016 CIO article, argues that a time-and-materials model (or a variation thereof) is more appropriate for agile development, as overall project scope and resource needs may change based on evolving requirements. That argument doesn’t ignore the concern that time-and-materials billing could be exploited by developers charging recklessly for unneeded hours of work. Overby writes, “The T&M model is more palatable due to its more client-friendly termination rights. However, there is a huge risk here: once the project is sufficiently far along, the client’s desire to complete the project outweighs the flexibility to easily exit the project.” This risk can be managed, however, by working with known partners and establishing trust through communication. This is particularly so since the goal of Agile projects is to leverage that personal communication for best results.

Product Vision and Project Planning

The Product Vision is the overarching framework for the project which the parties collaborate to achieve. It is updated as customer requirements change. This will likely be drafted and maintained separate to the agreement and referenced throughout the project. Agile projects work best when structured in smaller, discrete deliverables that can be reorganized and reprioritized based on shifting requirements. The agreement should define the iteration process, including the length of each iteration; the parties involved; and the “Definition of Done” or acceptance criteria.

According to a Stride post by technology blogger Debbie Madden, there are four options to align your contract with your agile team.

1. If the client chooses to constrain money, write the contract to have a fixed budget. With the limited budget, features are continuously prioritized with a focus on the most important ones. “Helping teams determine the ‘must-haves’ vs. the ‘nice-to-haves’ can be integral, because a fixed budget requires that we stop building when we hit that budget, or consciously decide to increase the budget.”
2. If the client chooses to constrain time, write the contract to have a fixed length. In situations like this, you’ll want to give a cost estimate, and make clear the project will end on a certain date.
3. If the client chooses to constrain scope, write the contract to have a fixed scope. Madden argues that this type of contract is the most challenging because the necessary features and project deliverables must be clearly outlined. In instances like these, communication with the client is important to understand that both time and cost can increase in order to ensure the agreed upon features are delivered.
4. If client and developer cannot agree that one and only one variable can be fixed, then the project is essentially fixed bid. This is the type of situation that Madden and others familiar with Agile projects seek to avoid. “Trying to complete an Agile project under the constraints of a contract suited to another type of process will make life for the team very difficult.” It’s worth re-stating that this is due to the fluid and ever-changing nature of the agile methodology.

Project Roles

The agreement should clearly define project roles and responsibilities, including those for the development team, product owner and Scrum Master (i.e. the individual tasked with removing obstacles from the development team). Understanding exactly who will be assigned what tasks is key. Furthermore, detailing the level and term of engagement is also important. With a focus on small, iterative tasks, will an individual developer be expected to be available for every sprint, or only when needed? Understanding and keeping in mind these resource allocation options can better ensure a successful project.

Intellectual Property Rights

As described in a white paper by the Bird & Bird law firm titled “Contracting for Agile Projects”:

[t]he ownership of the IP rights developed by the Supplier is a key area in any development project. In particular, the contract will need to identify whether the Customer will own the IP rights in the developed project or whether the IP rights will be retained by the Supplier and licensed to the customer.

The parties should make clear who will own the intellectual property rights in the developed software, and at what point ownership is transferred to the buyer. Furthermore, it should be made clear what documentation must be submitted, and at what point throughout iterations it would be delivered. According to Bird & Bird, key issues to be addressed include:

1. The contract should clearly specify whether (or not) the Customer will own the IP rights in the developed product (and the individual product increments); and
2. Regardless of #1, the contract should provide for the Customer to own all IP rights in the Product Vision and Product Backlog, which are standard ongoing components within the Agile methodology, where requirements and to-do items are stored and updated for implementation.

Termination

The contract should specify when it may be terminated, which often means at the end of an iteration. However, since iterations are intended to result in the delivery of completed, functioning code, agile projects are less likely to go drastically out of scope, so these agreements usually do not include termination charges. But when should each party be entitled to bring an end to the project?

Referring back to Bird & Bird’s whitepaper, arguably the customer has an inherent right in an Agile project to de-scope the product backlog at any time, remove outstanding items, and declare the project completed. On the other hand, the supplier may have invested significant time and resources in dedicating a development team to the project, justifying some form of compensation for the work that was done but which did not result in an MVP.

To address these key concerns, Bird & Bird suggests that contracts should address the following:

1. Clearly deal with each party’s right to terminate the project. The customer will likely insist on the right to terminate after each iteration. Although the customer may be reluctant to grant the supplier the same flexibility, since it creates the risk of the customer being abandoned by the supplier mid-project.
2. Include standard rights to terminate immediately, for example in cases of material breach by, or insolvency of either party.
3. The contract should also make clear if and when any compensation will be payable to the supplier if the contract is terminated early.

We hope to cover the topic of Agile software development more fully in future blog posts.

Share this article:

Facebook

Twitter

Linkedin

email