When you contract for Agile don’t confuse it with traditional methods

By general definition, agile contracts bring the supplier and the customer together, agreeing on everything they are assuming true about the business value, the inherent risks in implementing Agile and the expenses or effort involved. 

But keep in mind -- traditional and Agile processes do not work the same way. That’s why the word “agile” strikes fear into the heart of experienced transaction lawyers across the globe. Agile’s inherent uncertainty is the antithesis of the certainty that all good contract lawyers seek.

For example, Agile methodology can be used to develop software, but the process means that you cannot identify the scope, schedule, or budget of an Agile contract when it is initiated.² Agile methodology only allows you to identify the product vision, the process that will be used, and the user stories that will be worked on.³ (A user story is the end user’s generic language for describing a software feature.)

This conundrum, too often overlooked during negotiations, can fire up legal disputes around Agile projects that are contracted in a traditional, waterfall, manner.  Issues arise. 

SIX ISSUES

The case of Austech Applications Pty Ltd v Oz Wide Trading Group Pty Ltd (‘Austech v Oz Wilde’)^4/5 involves a dispute over unpaid monies and a breach of contract claim that resulted from  a software development contract that used a hybrid Agile methodology. The issues were:

1. When is Agile the appropriate methodology?
2. What is the scope of an Agile contract?
3. What is the schedule of an Agile contract?
4. How do you control the costs of an Agile contract?
5. How are user stories created?
6. How does acceptance occur?

It was discovered that the dispute could be reduced through contractual drafting and could demonstrate what this drafting would look like.

FIRST ISSUE - WHEN IS AGILE THE APPROPRIATE METHODOLOGY?

Is Agile methodology appropriate for the work being contracted for? At first, this appears to be a commercial and practical issue regarding what project methodology is best suited for the work being done.

However, in the Austech v Oz Wilde case  it was claimed that Austech had breached their contractual duty to exercise due care, skill, and judgment by implementing an Agile methodology. ⁶ Oz Wilde was not successful with this argument because, in the words of the sitting Victorian Civil and Administrative Tribunal Member N Campbell who presided over the case:  

“[I] find that a hybrid Agile methodology was an appropriate software development methodology in this case and that Austech applied a hybrid Agile methodology to the software development.”7

 This decision was based on the evidence given by Austech’s expert.⁸  The fact that this argument was pleaded in court demonstrates that selecting a project methodology can become a legal issue. Member N Campbell’s judgment begs the question: could using Agile methodology be considered a breach of a similar contractual provision in a different factual situation?⁹ This becomes relevant if we can use contractual drafting to reduce the risk of this issue coming into dispute.  So, to answer this question we must use the following steps:

• Step 1 - identify the benefits and risks of Agile methodology.
• Step 2  - determine if the parties could agree through contractual drafting, then Agile methodology would be appropriate.

Benefits and Risks of Agile Methodology

The key advantage of Agile over Waterfall methodology is receiving more product for less cost  -- the business reason behind adopting Agile methodology. 

But Agile methodology must be appropriate to use in the specific situation. It is not without inherent risks that may make it inappropriate to use Agile methodology for a contract.

Agile describes many methodologies that try to implement the principles from the Manifesto for Agile Software Development. ¹⁰

When using Agile, you do not know all of the functions that the final product will contain.¹¹ The concept of upfront in-depth requirements documentation is often criticized by Agile proponents as being a waste of time, developing a document that is not deliverable¹² and requirements always change throughout a project.¹³It is possible to include a product vision, or a “statement describing the overall purposes and objectives of the project”¹⁴ but the description of the requirements being developed is an ongoing process.¹⁵

The Agile Contracts Primer,¹⁶describes how Agile methodology uses short increments to create a minimum viable product. This product is then reviewed and iterated  to create the perfect product that meets the customer’s business needs. As an example, the primer uses an entry level Lexus IS automobile, which would be the minimum viable product, that then has more features added with each iteration to create the luxury Lexus LS that is perfect for the particular customer.¹⁷

This process is the antithesis of the Waterfall methodology that requires the customer to select all features desired at the start of the project. Agile methodology does not guarantee what the final product will look like or how long it will take to deliver.

Advantages of Agile Methodology

The first advantage of Agile occurs before work even begins. You can in principle negotiate an Agile contract much faster than a Waterfall contract,¹⁸ because an Agile contract does not require a detailed list of all requirements and functions, but only high-level product vision.

Agile methodology also has implementation advantages over Waterfall for software and product development in a capstone design project.¹⁹ In addition, Agile offers four more advantages:²⁰

1. A simple and flexible development process²¹ involves minimal long-range planning instead using iterative sprints (short interactive cycles that result in software development).  Short sprints allow the user to adapt to changing requirements. ²² This flexibility allows the business to meet users’ needs as they are identified and updated, instead of meeting business needs that may no longer be relevant.
2. The same cross-functional sprint team throughout a project builds a highly performing team ²³ working collaboratively to maximize the efficiency of development. ²⁴
3. Each sprint involves collaborative and continuous work between the developer and the customer²⁵ which puts the focus on the customer and ensures that customer satisfaction is front and center throughout the development process.²⁶ The constant interaction and review by the customer forces the developer to maintain superior design and development in each sprint. ²⁷
4. Each iterative sprint provides a deliverable based upon a prioritized user story ²⁸showing the customer a clear picture of the work being completed and a tangible measurement of progress for both the team and the customer. ²⁹ This makes it easier to maintain customer confidence as the customer sees the work being performed.

These four advantages allow Agile methodology to maximize return on Investment (‘ROI’) for the work completed.³⁰ Both parties get a high ROI that increases the value received by the customer and the reputation of the developer.

Risks of Agile Methodology

Agile Methodology Adoption: Benefits and Constraints³¹ identify three major risks to adopting Agile methodology. ³² These are:

1. That Agile is not correctly understood and implemented. ³³
2. Poor implementation that undercuts the benefits of Agile methodology and results in an increased workload and poorer ROI than Waterfall methodology. ³⁴
3. That Agile methodology is inherently uncertain and cannot be constrained by a set scope or schedule, meaning Agile cannot guarantee the completion date for development. ³⁵

These risks are a concern for traditionally minded commercial parties.³⁶In particular, the uncertainty in Agile is not suitable for projects with a strict time limit or a clearly identified and known scope.

Contractual drafting – advantages and disadvantages

Agile methodology is appropriate for projects that do not have a fixed scope or timeframe. One risk is the lack of understanding on how the process works which, again as stated, is essential before you can take advantage of Agile methodology.

To demonstrate the appropriateness of Agile methodology, the contract would have to

• first identify, in broad terms, what Agile methodology is and what key factors are required for Agile methodology to work;
• then identify the inherent uncertainty in Agile methodology and that there is no guarantee as to scope or schedule; and
• then demonstrate agreement between the parties that Agile methodology is appropriate considering these facts.

The contract could require an understanding of Agile methodology by the appropriate personnel as part of the contract. The difficulty with this clause is not the developer drafting the clause, because the developer should never try to implement Agile methodology without a skilled team, appropriately trained for the job.  The real difficulty is the customer, who may not have personnel skilled enough to perform the product owner role.

One solution is having the customer engage a third party to perform the role or for the developer to train the customer representative to do so. Even though the exact solution is a commercial decision, you can draft the contract wording to require each party’s key personnel to understand Agile methodology.

An example of how these could be drafted is:

Clause 1: Agile methodology

1.1    The parties agree that the Product will be developed using Agile methodology.

1.1.1 Agile methodology is a flexible methodology that can adapt to changing requirements and prioritizes Customer’s satisfaction.

1.1.2 Agile methodology uses an iterative development process of short sprints to create software that meets the Product Vision.

1.1.3 Agile methodology requires a dedicated development team and continuous collaboration and involvement from Customer.

1.1.4 Agile methodology does not guarantee a scope or schedule. These are developed as the Product is developed and are subject to constant change.

1.2    The parties acknowledge and agree that Agile methodology is an appropriate methodology for developing the Product.

Note: the term “Agile methodology” can be replaced by the specific Agile methodology that will be used in the project.

SECOND ISSUE: WHAT IS THE SCOPE OF AN AGILE CONTRACT?

How do you define the scope of a contract when using Agile methodology? Although this was not an issue in Austech v Oz Wilde, the scope of the contract was unclear. The parties used a hybrid Agile methodology which implies that they attempted to define the scope of the agreement, as demonstrated by Oz Wilde providing specific examples of how they wanted the software to look. ³⁷ Member N Campbell’s decision to reduce the damages awarded to Austech for the incomplete work only further implies the contract was intended for an outcome, ³⁸ but this leads to two issues:

1. Did Austech meet the required functionality, ³⁹ and how can this be proven if the parties agreed that Agile methodology did not require detailed user requirement documentation? ⁴⁰
2. Did the scope of the contract included a clean version free of software coding errors? ⁴¹

These issues prove the above point -- how using a traditional waterfall contract structure does not work for Agile methodology that focuses on the outcome, not the process. ⁴²

If the contract had specified the process of Agile methodology, then the above issues would not have arisen. No obligation existed to meet any specific functionality to a specific standard, because the only obligation would have been to follow a process until a final product was accepted or the contract terminated.

Before we can examine if we can use contractual drafting to reduce the risk of this issue coming into dispute, we must first gain a basic understanding of the process for Agile methodology. We can then examine how this process can be implemented into a contract.

The process for Agile methodology

Based on the above, we know that Agile methodology involves a system of various methods, each based on the same principles. One of the most popular is scrum, a process defined as a framework for managing a project. Scrum is usually tied to software development, often involving decisions based on observation, experience, and experimentation.

Scrum is not the only Agile methodolog, however it is a good example of the four key components found in Agile methodolgies.⁴³ These are:⁴⁴

• product vision;
• key roles;
• sprints; and
• product backlog.

Product vision:

“The starting point for a Scrum project is the Product Vision. This is a statement setting out the overarching goals of the project and the high-level benefits that are sought. Ideally, the Product Vision will have been developed before the contract negotiations start to help the negotiation team understand the intended end result of the project.” ⁴⁵

The idea here is to provide context to the contractual document, because it involves a contract “in which the scope, vision, and business motivation of the project or product [are] utterly inscrutable”.

It is important to understand the content that must be included in the product vision before you can contract for it.  In the Agile Contract Primer, the authors specify that this vision should include:

1. who the product is for;
2. why they want the product;
3. what the product is on a high-level; and
4. how the product will provide a benefit. ⁴⁶

You can compare the content of the product vision in the Agile Contracts Primer with the view in The Art of Agile Contracting. ⁴⁷ In The Art of Agile Contracting, the authors suggest that you need “a concrete specification that was agreed upon before starting work”. ⁴⁸

The high-level summary envisioned in the Agile Contract Primer is not compatible with the concrete specifications identified in The Art of Agile Contracting. Therefore, a contract can only adequately implement one of these, not both! 

The high-level summary approach has support from other literature. In Agile Programming – Introduction and Current Legal Challenges⁴⁹ the authors specify that a product vision “describes the overall purposes and objectives of the project”.⁵⁰

This promotes the idea that the product vision is only a high-level summary, which makes more sense than providing concrete specifications. Agile methodology is based around flexible functionality requirements that change as the project matures, so having concrete specifications at the start of the project limits the ability for functional requirements to alter  over the course of the project.

A high-level summary of what the parties wish to accomplish is better aligned to Agile methodology because it will provide the context under which functionality can be added and changed. That’s why the product vision needs to be the high-level summary identified in the Agile Contracts Primer.

Key personal

Literature on Agile methodology agrees that there are the following three essential key roles: ⁵¹

• Product Owner,
• Project Manager (aka scrum master), and
• Development Team. ⁵²

It is critical that the contract between the parties accurately describes these roles, their responsibilities and the qualities desired so that each party can appoint appropriate representatives.

Product Owner

As the customer’s key representative in the Agile project, ⁵³ the Product Owner is the only one who can update new user stories to the developer. ⁵⁴ Having one authority responsible for this is vital in preventing conflicting requirements from being provided to the Development Team.

The Product Owner is also responsible for being the customer’s single point of contact. ⁵⁵ This means that the Product Owner must be available to discuss issues with the Project Manager and will be required to attend meetings between the Project Manager and the Development Team. ⁵⁶ The exact meetings that the Product Owner attends will depend on the specific project and customer, but at a minimum they will be attending all sprint planning meetings and sprint review meetings. ⁵⁷

The Product Owner is also solely responsible for providing acceptance, ⁵⁸ as discussed below in more detail. 

The Product Owner role can be performed by a customer employee or a third party appointed by the customer, ⁵⁹ which may be useful for smaller parties who lack the required skills in house.

Project Manager

The Project Manager, who is referred to as the Scrum Master in Scrum and most related documentation, is responsible for managing the project, ensuring cooperation between the parties, and ensuring that the project plan is followed.⁶⁰ This role is a developer representative who may be a developer employee or a third party appointed by the developer. ⁶¹

It is important to ensure the Project Manager has appropriate training or experience in Agile methodology. ⁶² A traditionally trained project manager may lack the relevant knowledge to lead an Agile project successfully. ⁶³ Qualifications may be used as a standard to ensure that the Project Manager is appropriately skilled.

To date no case law has been established about this, but potential issues could arise over meeting any requirements for due care, skill, and diligence by the developer if an inadequately qualified or inexperienced Project Manager has been assigned this duty. Explicitly specifying requirements for the Project Manager will reduce the risk of this occurring.

Development Team

This cross functional team is responsible for completing the actual development ⁶⁴ and exercises all relevant skills to implement the Product Vision. ⁶⁵ As noted above, one benefit of Agile is the Development Team becoming more efficient throughout the project. The Development Team, therefore, must retain the original members as much as possible to allow the customer to fully  benefit from the Agile process. ⁶⁶ While some changes in the Development Team may be unavoidable, the customer should be allowed to ask to be contractually protected from unnecessary changes within the Development Team.

Sprints

Sprints are the short iterative development cycles that form the basis of Agile methodology. The aim of each sprint is to create functional software ⁶⁷  and are each akin to an entire traditional project.⁶⁸

Sprints have the following characteristics:

• a set period of typically 2-4 weeks;
• an initial planning meeting when the Product Backlog items that will be worked on during the sprint are identified;
• a functional software capability being created; and
• a review meeting at the end of the sprint when acceptance for the developed software occurs and the sprint is reviewed. ⁶⁹

The literature^67/68/69 also suggests having a daily meeting, or scrum, as part of each sprint. ⁷⁰  Although this is a part of Scrum methodology it might not be part of all Agile methodologies. ⁷¹

Some sources recommend not including the daily meeting as part of the contract, because it ”may be overkill in many projects”. ⁷² While the daily meeting could be included as part of the sprint process, it is likely to be unnecessary in some cases and may limit how the developer can benefit the customer.

One of the key issues raised by sprints is whether "the outcome of the sprinting process should be regarded as binding” ⁷³ i.e., should there be specific obligations for the work to be completed in a sprint.

One view claims it is difficult to prepare for any penalties, because sprints are charged for and paid in a way that does not assume penalties exist. ⁷⁴ The only exception is fixed price sprints, where it might make sense to reduce the amount billed, because the work was not completed as originally agreed.  

This practice is reinforced by Agile contracts providing termination for convenience. This means that imposing termination as a penalty for failing to produce software would make little difference to the rights the parties were entitled to receive as they already have the right to terminate for convenience. Therefore, only limited circumstances exist in which obligations should be attached to the outcome of each sprint and these should not be used as a standard.

Product Backlog

This lists all features the customer wants produced as part of the project ⁷⁵ and should include the following elements:

“Items: the list of features to be developed. As the project develops, these may also include defects to be rectified and/or areas for further improvement;

Estimate of business value: an estimate by the Product Owner of the value to the Customer’s business of each item (presented in relative terms by comparison to other items);

Estimate of effort: an estimate of the effort required by the Development Team to develop each item (presented in relative terms by comparison to other items); and

Priority: the priority for each of the items, taking account of the estimates of business value and effort. In Agile projects, the development items are often articulated as “user stories” (i.e., capturing succinctly what the end user wants to achieve) [.]”⁷⁶

The Product Owner has sole discretion to update and reprioritize the product backlog, but cannot update the estimates of effort for that document or reprioritize items that are currently under development as part of the existing sprint. ⁷⁷

Contractual drafting

To reflect the reality of the Agile process, the contract would have to incorporate the positions identified above.

For the Product Vision, the contract would include an explanation of the Product Vision that meets the standards set in the Agile Contract Primer. An example of this would be:

          Clause 2: Product Vision

2.1 Developer will create the Product for Customer that will allow them to reduce their billing time by developing automated software that will identify, generate, and send invoices to Customer’s clients and log these invoices in Customer’s internal system.

For the key roles, the contract should identify the three key roles, the individuals who will fill them, and the responsibilities that they have.

The contract should also provide some restriction for replacing the identified individuals. Two methods identified in the literature are an obligation for the individuals to not be replaced without good cause or to require written consent from the other party to replace the individuals.⁷⁸ It is up to the parties to negotiate the specific restriction on a case-by-case basis, but it is a good idea to have some restriction within the contract.

An example of how all of this could look is:

          Clause 3: Key Personal

          3.1 Product Owner

          3.1.1 The Product Owner is identified in Schedule 1.

3.1.2 Customer warrants that the Product Owner has the appropriate skills or experience to complete their responsibilities with due care, skill, and diligence.

          3.1.3 The Product Owner is responsible for the following:

          3.1.3.1 Updating the User Stories in accordance with clause y.

3.1.3.2 Attending Sprint Planning Meetings and Sprint Review Meetings.

3.1.3.3 Providing formal Acceptance on behalf of Customer in accordance with clause z.

3.1.3.4 Being Developer’s primary contact for developing the Product.

          3.2 Project Manager

          3.2.1 The Project Manager is identified in Schedule 1.

3.2.2 Developer warrants that the Project Manager has the appropriate qualification or experience in Agile methodology to complete their responsibilities with due care, skill, and diligence. The acceptable qualifications or experience are specified in Schedule 1.

3.2.3 The Project Manager is responsible for the following:

3.2.3.1 Managing the Development Team

3.2.3.2 Arranging and running all meetings specified in the Clause 4 and any additional meeting reasonably required to develop the Product.

3.2.3.3 Ensuring the sprint process specified in Clause 4 is followed by the Development Team.

3.3.3.4 Ensuring that any Lessons Learnt are implemented.

3.2.3.5 Providing any governance reports that are specified in Clause z.

3.2.3.6 Being Customer’s primary contact for developing the Product.

          3.3 Development Team

3.3.1 The Development Team is identified in Schedule 1.

3.3.2 Developer warrants that the Development Team contains all resources that are required to implement the Product Vision. Developer agrees to modify the Development Team should different resources be required.

3.3.3 Developer warrants that the Development Team has the appropriate training to work in an Agile project.

3.4 The parties agree to not change the individuals specified in Schedule 1 except with written consent of the other party. Written consent may not be unreasonably withheld.

For sprints, the contract should reflect the timeframe for the sprint, the meetings that will occur, and what the outcome of those meetings will be.

An example of this would be:

Clause 4: Sprint Process

4.1 The Product will be developed using iterative sprints.

4.2 Each sprint will be two weeks in duration.

4.3 Each sprint will begin with a Planning Meeting held on the morning of the first business day of the sprint.

4.3.1 The Planning Meeting will be attended by the Product Owner, the Project Manager, and the Development Team.

4.3.2 In the Planning Meeting:

4.3.2.1 The Product Owner and Project Manager will agree on the Targeted User Stories which will be developed as part of the sprint; and

4.3.2.2 The Product Owner will confirm the priority for the Targeted User Stories.

4.4 During each sprint:

4.4.1 The Development Team will develop software based on the Targeted User Stories that can be Accepted in the Review Meeting.

4.4.1.1 This development will include designing the software, coding the software, integrating the software into the Product, and testing the software.

4.4.2 If the Development Team completes all the Targeted User Stories, then the next highest priority User Story found in the Product Backlog will become a Targeted User Story.

4.5 Each sprint will end with a Review Meeting held in the afternoon of the last business day of the sprint.

4.5.1 The Review Meeting will be attended by the Product Owner, the Project Manager, and the Development Team.

4.5.2 In the Review Meeting:

4.5.2.1 The Product Owner will provide Acceptance for any completed User Stories.

4.5.2.2 Any Targeted User Stories that are not Accepted will be added back into the Product Backlog.

4.5.2.3 The sprint will be reviewed and any Lessons Learnt will be added to the Lessons Learnt Register so that they can be implemented in future sprints.

For the Product Backlog, the contract should reflect what the Product Backlog will look like and who is responsible for what part of the Product Backlog. An example of this would be:

Clause 5: The Product Backlog

5.1 The Product Backlog is a prioritized list of all User Stories that will be developed to create the Product that includes the Business Value and Estimated Effort for each User Story.

5.2 The Product Owner has sole discretion to add or remove User Stories from the Product Backlog at any time subject to the following restrictions:

5.2.1 Any new User Story must meet the requirements specified in Clause 10.

5.2.2 No Targeted User Story can be removed from the Product Backlog.

5.3 The Product Owner has sole discretion to reprioritize User Stories in the Product Backlog at any time but cannot reprioritize Targeted User Stories.

5.4 The Product Owner has sole discretion to revalue the business value of any User Stories at any time.

THIRD ISSUE: WHAT IS THE SCHEDULE OF AN AGILE CONTRACT?

In Austech v Oz Wilde, Oz Wilde pleaded that Austech breached the contract between the parties by failing “to deliver the project within 38 weeks of commencement”. ⁷⁹

Again, as stated above, Agile methodology does not lend itself to a defined schedule because the Agile process is not about fixed requirements. Trying to use Agile methodology to complete development according to a strict schedule is always likely to create an issue for precisely this reason. However, a customer is unlikely to agree to an Agile contract that includes no ability to control the project timeframe, and this may make Agile methodology inappropriate for work that needs to be completed on a strict schedule.

The solution for allowing the customer some control of the timeframe is to allow either party to terminate for convenience. ⁸⁰ This termination right should be limited to allowing for termination at the end of a sprint -- not allowing an unlimited right to terminate for convenience. ⁸¹ This appears to be the optimal approach for controlling the timeframe of an Agile contract.

Using termination to control the timeframe of an Agile contract does raise the issue about what payments and rights are due on termination. The issue around payments after termination is also apparent in Austech v Oz Wilde. ⁸²

The Agile Contracts Primer suggests that a sliding scale of termination payments paid to the developer should be authorized based on how long the expected timeframe would be for the Agile contract and how many resources were committed to the Agile contract. ⁸³ Other sources reflect this view, for example Bird & Bird recommend termination by the customer resulting in payment of “some or all of the profit that the [Developer] may have made from future iterations”. ⁸⁴

However, some sources believe that the matter of termination fees should be agreed between the parties and not subject to a standard provision. ⁸⁵ This may be the outcome of a negotiation, but it should not be the starting point. A reasonable standard provision can reduce negotiation times by reducing the number of items that need negotiating. This is beneficial to all parties because quicker negotiations lead to more agreements and more work being completed and paid for.

A solution could be to include payment for all work completed no matter which party terminates and, on longer contracts, include some form of termination fee that reduces over time if the customer terminates for convenience. This solution would allow the developer to be paid for the work completed and for the expected income while minimizing the potential costs for the customer.

Another solution would be to include a termination fee that covers the losses the developer will receive after termination before it can reassign employees to other work if the contract is terminated for convenience by the customer. This solution would minimize losses for the developer and potentially be cheaper for the customer. However, the fee would not change over time so that is a potential risk for the customer and the fee would not cover the developer’s expected income.

The first solution appears better suited to developers for whom the potential income is of greater importance to the company and would prefer a guarantee of a specified income. The second solution is better suited to developers for whom the income would be a small fraction of their revenue stream and who may be more concerned with ensuring they would not make a loss out of termination rather than guaranteed amounts of income.

Any work completed as part of the Agile contract should be delivered to the customer after termination. ⁸⁶ This seems reasonable because Agile methodology is about developing software for the customer so the customer should keep ownership of that software. However, the parties may agree for a cost to be associated with providing completed work on termination. The developer would need to make an effort to transfer that work and it would be reasonable to pay the developer for that effort.

Contractual Drafting

If a drafted clause that mitigates the risk of the project timeframe becomes an issue, the clause must provide for termination for convenience at the end of any sprint and for the negotiated outcomes of that termination. It is likely that the negotiated outcomes would include the developed software being provided to the customer, payment for the work that’s been completed by the developer, and a termination fee paid to the developer if the customer terminates the contract.

An example of this would be:

Clause 6: Termination for Convenience

6.1 Either party may terminate the Agreement for convenience by providing written notice to the other party anytime from the start of the Review Meeting of a sprint and before the Planning Meeting of the next sprint that the party intends to terminate for convenience.

6.2 In the event of termination for convenience by either party or termination for cause by either party:

6.2.1 Any software completed as part of the Product will be delivered to Customer in the manner identified in Schedule 1 and for the costs identified in Schedule 1.

6.2.2 Customer shall pay Developer any Fees for work completed up to end of the last sprint.

6.3 In the event of termination for convenience by Customer then, in addition to the obligations in Clause 6.2:

6.3.1 Customer will pay the Termination Fee specified in Schedule 1.

6.3.2 The Termination Fee will be reduced by the Termination Fee Reduction specified in Schedule 1 for each completed sprint down to a minimum fee of $0.

Note: Clause 6.3.2 would be removed for the second termination option identified above.

FOURTH ISSUE - HOW DO YOU CONTROL THE COSTS OF AN AGILE CONTRACT?

The issue of how to control costs in an Agile contract was not explicitly raised in Austech v Oz Wilde, but is demonstrated, because the contract was for a fixed fee for completing all the work. ⁸⁷ The fact the parties entered an agreement for a fixed fee instead of using one of the methods listed below shows that OZ Wilde feared that they would not be able to control the costs of an Agile contract.

This is reinforced by the recommendation against using fixed fee for an entire project⁸⁸ unless the project “require[s] the supplier to be aligned with a predefined customer vision that is sufficiently well documented”. ⁸⁹ This may mean that Agile is not appropriate for development where the customer has a strict budget because price guarantees are not offered. The decision on which methodology to use in that case would have to be a commercial decision made by the customer for their individual situation.

Very Creatives, a digital product agency, recommended solving the variable costs of an Agile contract by fixing the cost but leaving the schedule and scope as variable.⁹⁰ This proposed solution can be done by pre-creating a product backlog and listing the items in that backlog that need to be completed and which are optional depending on budget.⁹¹ This solution does work but it removes the advantage Agile projects have in dealing with changing business requirements. As such, this solution can only be recommended for projects with a well-defined initial scope and not as being generally applicable to all Agile projects.

If a fixed fee is not used, an Agile contract will need to be charged in another way. The Agile Contracts Primer lists multiple ways that you can charge for an Agile contract that do not include a fixed fee. ⁹² The following focuses on:

1. Time and materials;
2. Fixed price per sprint;
3. Fixed price per unit of work; ⁹³

Time and materials costing can potentially cause an issue as it “leaves customers carrying all the risk rather than sharing it with their supplier”. ⁹⁴ It is recommended in multiple sources that this risk is overcome by providing a cap on time and material costs per sprint, ⁹⁵ which is a fairer way of dividing the risk between the parties because it caps the risk for the customer rather than the customer holding all the risk. However, there is still a risk that time and materials “result[s] in disincentives for the Supplier to create realistic estimates and to stick to them” ⁹⁶ so some sources recommend against using time and materials as a pricing model.

Charging on a fixed price per iteration leaves the developer with more of the risk than pure time and materials because the developer must cost out the sprints. ⁹⁷ However, it is potentially problematic for the customer because the developer is likely to want to include contingency in the fixed fee⁹⁸ and any “penalties for poor quality can encourage supplier to prioritize quality over velocity”. ⁹⁹ This can result in an overall increase in the cost of an Agile contract.

Charging on a fixed price per unit of work means that the customer pays a set amount either per user story or per estimate of effort applied to each user story. ¹⁰⁰ The issue with this pricing model is the ambiguity in defining how much effort is put into completing a user story or an estimate of effort.¹⁰¹ However, sources still recommend fixed price per unit of work because the “model is congruent with agile and lean themes of being delivery- and value-oriented… [the customer] pay proportional to value received”. ¹⁰² This model can be viewed as a compromise between the time and materials model and the fixed price per iteration model especially when costed on a fixed fee per estimate of effort.

It is important that if an Agile contract is charged based on effort estimated for each user story that there is a fair process for identifying that effort. This will be discussed below.

Ultimately the pricing model chosen is a financial decision that needs to be agreed between the parties, but the above should provide a guideline for selecting the best method for a specific situation.

Contractual Drafting

When drafting for any of the pricing models chosen above, it is important to clearly state the method and the rates being used. An example of this would be:

Clause 7: Charges

7.1 Customer will pay Developer to develop the Product on a time and materials basis at the rates specified in Schedule 3.

7.2 Developer will invoice in arrears at the end of every sprint for the hours worked and materials used during that sprint.

 

Clause 8: Charges

8.1 Customer will pay Developer to develop the Product at the fixed fee specified in Schedule 1 for each sprint completed.

8.2 Developer will invoice in arrears at the end of every sprint.

 

Clause 9: Charges

9.1 Customer will pay Developer to develop the Product the fixed fee specified in Schedule 1 for each point of Estimated Effort in every User Story that is Accepted as complete.

9.2 Developer will invoice in arrears at the end of every sprint.

FIFTH ISSUE - HOW ARE USER STORIES CREATED?

In Austech v Oz Wilde a “key dispute between the parties was whether Austech or Oz Wide was responsible for the functional design of the software”.¹⁰³ This is partly because “the requirements of the software develop as the project progresses”.¹⁰⁴

It is established above that user stories are the method through which the functional design of the software is expressed. User stories are often formatted like "as a user, I want the feature X, so I have the advantage Y" ¹⁰⁵ and the literature is unanimous that the customer is obligated to create user stories.¹⁰⁶

One issue with user stories is the functional requirement in the user story may be too complicated to be implemented in a sprint or the user story may be expressed in an unstructured way.¹⁰⁷ User stories communicated by the client then need to be broken down into functional user stories that are large enough to being meaningful when completed but discrete enough to be completed in a sprint.¹⁰⁸ This process is called decomposing. It is expected that 5-10% of each sprint will be spent on redefining the Product Backlog.¹⁰⁹

Klynveld Peat Marwick Goerdeler (KPMG) recommend not placing user stories in the product backlog until they have gone through decomposition.¹¹⁰ The issue with KPMG’s suggestion is that if the developer is paid per unit of work completed, then they would receive no pay for decomposing user stories as they would not be in the product backlog.

In contrast, Bird & Bird recommend placing all user stories in the product backlog and then decomposing the user stories afterwards.¹¹¹ The issue with Bird & Bird’s proposed alternative is that user stories could be inserted as high priority into the product backlog before they have been decomposed, potentially requiring the development team to begin developing software based on user stories that have not been decomposed.

The logical solution is to find the middle ground between the two alternatives. This means user stories can be suggested by the product owner and entered into the product backlog as a decomposition task but will not be subject to software development until they have been decomposed. There should also be a process that allows a user story to be subject to software development immediately if the project manager and development team decide that the user story does not need decomposition.

The advantage of this compromise is that it keeps all user stories on a single register so that the complete picture is apparent by looking at that register but also allows for decomposition to occur before software development to allow all development to meet the sprint timeframe.

Contractual Drafting

To allow user stories to be entered into the product backlog, the contract must reflect:

1. The format of the user stories;
2. What information needs to be entered into along with the user stories;
3. Who is responsible for what part of the information; and
4. The process for how user stories are generated into the product backlog and prepared for production.

An example of how this could look is:

Clause 10: User Stories

10.1 User Stories are how the functional requirements of the Product are communicated to Developer.

10.2 User Stories must be communicated by the Product Owner to Developer in the following format:

10.2.1 As a user, I want [insert feature], so that I have [insert advantage].

10.3 Product Owner communicates User Stories by entering a new User Story into the Product Backlog with the following restrictions:

10.3.1 The new User Story will be titled “Decomposing User Story: [insert User Story]”;

10.3.2 The Priority and Business Value of the new User Story will be provided by the Product Owner;

10.3.3 The new User Story will have an Estimated Effort of 1.

10.4 If a Decomposing User Story is a Targeted User Story, then the task during the sprint is for it to be decomposed by the Development Team. Decomposition will:

10.4.1 Identify the Estimated Effort of the User Story;

10.4.2 If the Estimated Effort is too large to be completed during a sprint, then breakdown the User Story into smaller User Stories that have an estimated effort that can be completed during a sprint.

10.4.2.1 Broken down User Stories must be given a Priority and Business Value by the Product Owner before they can be Accepted.

10.5 Once the decomposition of the User Story has been Accepted it can then be entered into the Product Backlog without the term “Decomposing User Story” and can become a Targeted User Story.

SIXTH ISSUE - HOW DOES ACCEPTANCE OCCUR?

To help determine how acceptance occurs in an Agile contract, Austech v Oz Wilde discussed how much work had been completed and which standard the completed work should meet.¹¹² Essentially this was also a discussion on whether or not the work was accepted.

The Agile Contracts Primer recommends requiring acceptance for each functional requirement that builds the entire product to acceptance after all functional requirements are accepted.¹¹³ In contrast, other sources recommend using a document listing all of the functionality in the product and comparing it to the product vision to get final acceptance.¹¹⁴ It should be noted, however, that the same source also presents acceptance criteria for each user story as a potential alternative.¹¹⁵

The first alternative appears to be more appropriate for Agile methodology, because it allows for iterative acceptance that reflects the way the project is running. However, parties could agree to use the second method if desired.

No matter which method is chosen, an underlying question exists: what level of defects are acceptable?¹¹⁶ Bird & Bird recommend drafting an appendix containing a definition of Acceptance that includes:

“[T]the scope of tests to be conducted and passed (e.g., user acceptance tests and non-functional tests);

that all code has been reviewed (or pair programmed);

that all coding standards have been met and code has been re-factored where necessary; and

any necessary documentation has been completed.” ¹¹⁷

(Outside the scope of this article is the technical issue of what testing should be done and which standards are necessary.)

It should be noted that some products will require go-live testing in production that may be left until a certain amount of development is complete. ¹¹⁸ The question of how this is implemented in the sprint process is an interesting one.  It will depend on other work that can be completed while this testing occurs or if the process needs to be paused for a sprint to test, which could be implemented as a task in the product backlog.

Contractual Drafting

When drafting an acceptance provision, it is important to identify if the final acceptance will be provided automatically once acceptance for all user stories is granted, and if the software is entered production or if there is a separate final acceptance document that needs to be completed. It is also important to identify the testing required and the standards to be used to provide acceptance.

An example of how this could look is:

Clause 11: Acceptance

11.1 The Product Owner will provide Acceptance at the Review Meeting for all User Stories that meet the testing standards set out in Schedule 4.

11.2 Acceptance for the Product will occur once all User Stories are Accepted and the product has either:

11.2.1 Met the testing standards set out in Schedule 4 in the production environment; or

11.2.2 Been deployed into the production environment for a period of two weeks of successful operation.

11.2.2.1 Successful operation occurs if there are no issues that prevent the Product from working but does allow for minor bugs to be present in the Product.

Austech v Oz Wilde demonstrated six issues inherent to Agile methodology especially when implemented with a traditional waterfall contract. These issues can be mitigated by changing our understanding of what a contract is meant to include and explain so that it better aligns with the realities of Agile methodology.  

Agile can be the appropriate methodology for a project but is not the appropriate methodology for every project. The specific requirements of the customer and the project should be considered before deciding if Agile methodology is appropriate. The Agile contract must then clearly state why the parties have chosen Agile methodology, what the risks of Agile methodology are, and that the parties agree that Agile methodology is appropriate to the project.

Agile methodology does not lend itself to traditional ideas of scope. The flexibility that makes Agile ideal to certain projects also means that it cannot be restricted without undercutting the advantages of the methodology. By instead focusing on the process and not the outcome this larger focus can be contracted for.

Likewise Agile methodology does not lend itself to a fixed schedule. However, the parties can still control the timeframe for a project through termination for convenience clauses that set a low barrier for exiting the arrangement.

Agile methodology is also difficult to cost in a commercially viable manner because it does not lend itself to a fixed price, but customers may be unwilling to agree to a time and materials project. This article identifies three alternatives that can control pricing while still allowing the flexibility of Agile methodology to be used.

There is also an issue in Agile methodology for how functional requirements are communicated and accepted. However, this issue is mitigated by giving adequate consideration in the contract to the process and understanding the reality of how the methodology will work.

Mitigating these issues is not a guarantee that we will be dispute free with  Agile contracts but mitigation does help place the parties in a better position to set realistic expectations and avoid these disputes from emerging.

END NOTES

1. Agile Contract Management (definition)
2. Bertrand Meyer, Agile! The Good, the Hype and the Ugly (Springer 2014) (‘Agile! The Good, the Hype and the Ugly’).
3. Ibid.
4. [2021] VCAT 345.
5. Austech v Oz Wilde [2021] VCAT 345, [76] (‘Austech v Oz Wilde’).
6. Ibid, [32].
7. Ibid.
8. Ibid.
9. Pekka Abrahamsson et al, ‘Agile software development methods: Review and analysis’ (2002) 478 VTT Publications 1, 7-8; Kent Beck et al, ‘Manifesto for Agile Software Development’, Manifesto for Agile Software Development (Web Page, 2001) < https://agilemanifesto.org/>.
10. Agile! The Good, the Hype and the Ugly, [3.2.2]; Thomas Hoeren, Stefan Pinelli, ‘Agile Programming – Introduction and Current Legal Challenges’ (2018) (eJournal) International Journal of IT Law, Forthcoming 1, 6-7 (‘Agile Programming – Introduction and Current Legal Challenges’).
11. Agile! The Good, the Hype and the Ugly, [3.2.3].
12. Agile! The Good, the Hype and the Ugly, [3.2.4]
13. Agile Programming – Introduction and Current Legal Challenges, 6.
14. Ibid.
15. Tom Arbogast, Craig Larman, Bas Vodde, ‘Agile Contracts Primer derived from Practices for Scaling Lean & Agile Development: Large, Multisite, & Offshore Product Development with Large-Scale Scrum version 5’, Agile Contracts (PDF Document) <http://agilecontracts.org/> (‘Agile Contracts Primer’).
16. Ibid p 11-12.
17. KPMG, ‘Contracting for Agile: Finding a better way’, KPMG (PDF Document, July 2019) <https://assets.kpmg/content/dam/kpmg/uk/pdf/2019/08/contracting-for-agile.pdf>, 2 (‘Contracting for Agile: Finding a better way’).
18. Dianne Rover et al, ‘Advantages of agile methodologies for software and product development in a capstone design project’ (Conference Paper, IEEE Frontiers in Education Conference (FIE) Proceedings, 22-25 October 2014).
19. Ibid, [V].
20. Ibid.
21. Ibid.
22. Ibid.
23. Ibid.
24. Ibid.
25. Ibid.
26. Ibid.
27. Ibid.
28. Ibid.
29. Radha Shankarmani et al, ‘Agile Methodology Adoption: Benefits and Constraints’ (2012) 58(5) International Journal of Computer Applications 31, 32 (‘Agile Methodology Adoption: Benefits and Constraints’).
30. Ibid.
31. Ibid, 33-34.
32. Ibid.
33. Ibid.
34. Agile! The Good, the Hype and the Ugly, [3.2.2]; Agile Programming – Introduction and Current Legal Challenges, 6-7.
35. Ibid.
36. Agile Methodology Adoption: Benefits and Constraints, 34.
37. Austech v Oz Wilde, [35].
38. Ibid, [89].
39. Ibid, [24].
40. Ibid, [75].
41. Ibid, [60].
42. Agile! The Good, the Hype and the Ugly, [3.2.2].
43. Davide Taibi et al, ‘Comparing Requirements Decomposition Within the Scrum, Scrum with Kanban, XP, and Banana Development Processes’ (Conference Paper, International Conference, 22-26 May 2017) (‘Comparing Requirements Decomposition Within the Scrum, Scrum with Kanban, XP, and Banana Development Processes’).
44. Agile Programming – Introduction and Current Legal Challenges, 4-6; Jy Millis, Angie Freeman, ‘Agile contracting for Australian Government agencies’, Clayton utz (Blog Post, 11 October 2018) < https://www.claytonutz.com/knowledge/2018/october/agile-contracting-for-australian-government-agencies>.https://www.claytonutz.com/knowledge/2018/october/agile-contracting-for-australian-government-agencies> (‘Agile contracting for Australian Government agencies’); Contracting for Agile: Finding a better way; Agile Methodology Adoption: Benefits and Constraints, 31.
45. Bird & Bird, ‘Bird & Bird & Contracting for agile software development projects’, Bird & Bird (PDF Document) < https://www.twobirds.com/-/media/pdfs/brochures/contracting-for-agile-software-development-projects.pdf?la=en&hash=6786F395B7120D84AE9D7A1417F682577ABFDA5A>, 10 (‘Bird & Bird & Contracting for agile software development projects’).
46. Agile Contracts Primer, 20.
47. Bearing Point, ‘The art of agile contracting’, Bearing Point (PDF Document, 2021) <https://www.bearingpoint.com/files/BearingPoint_Agile_Contracting.pdf?download=0&itemId=788359>.https://www.bearingpoint.com/files/BearingPoint_Agile_Contracting.pdf?download=0&itemId=788359>.
48. Ibid, 5.
49. Agile Programming – Introduction and Current Legal Challenges.
50. Agile Programming – Introduction and Current Legal Challenges, 4.
51. Agile contracting for Australian Government agencies; Contracting for Agile: Finding a better way, 7.
52. Agile Programming – Introduction and Current Legal Challenges, 4-6.
53. Ibid, 4-5.
54. Ibid.
55. Ibid.
56. Ibid.
57. Ibid, 8.
58. Ibid, 4-5.
59. Ibid.
60. Ibid, 6.
61. Ibid.
62. Agile! The Good, the Hype and the Ugly, [5.6].
63. Ibid.
64. Agile Programming – Introduction and Current Legal Challenges, 5.
65. bid.
66. Agile! The Good, the Hype and the Ugly, [4.2.2].
67. Agile contracting for Australian Government agencies.
68. Bird & Bird & Contracting for agile software development projects, 4.
69. Ibid, 12-14.
70. 70Ibid, 13; Agile Programming – Introduction and Current Legal Challenges, 8.
71. Bird & Bird & Contracting for agile software development projects, 7.
72. Ibid, 13.
73. Agile Programming – Introduction and Current Legal Challenges, 8.
74. Ibid.
75. Agile Programming – Introduction and Current Legal Challenges, 6.
76. Bird & Bird & Contracting for agile software development projects, 11.
77. Ibid, 12.
78. Ibid, 8-9.
79. Austech v Oz Wilde, [52].
80. Bird & Bird & Contracting for agile software development projects, 19; Agile Contracts Primer, 21-22.
81. Ibid.
82. Austech v Oz Wilde, [81]-[90].
83. Agile Contracts Primer, 22.
84. Bird & Bird & Contracting for agile software development projects, 19.
85. Agile Programming – Introduction and Current Legal Challenges, 12.
86. Bird & Bird & Contracting for agile software development projects, 19; Agile Contracts Primer, 21-22.
87. Austech v Oz Wilde, [85].
88. Agile Contracts Primer 29-31; Bird & Bird & Contracting for agile software development projects, 16.
89. Contracting for Agile: Finding a better way, 6.
90. Mảtẻ Vảrkonyi, ‘Is a Fixed-Price Contract Possible With Agile Development’, Very Creatives (Blog Post, 31 July 2020) <https://verycreatives.com/blog/is-a-fixed-price-contract-possible-with-agile-development>.
91. Ibid.
92. Agile Contracts Primer, 25-29.
93. Ibid.
94. Contracting for Agile: Finding a better way, 2.
95. Ibid, 6; Agile Contracts Primer, 26.
96. Bird & Bird & Contracting for agile software development projects, 16.
97. Agile Contracts Primer, 26.
98. Ibid.
99. Contracting for Agile: Finding a better way, 6.
100. Agile Contracts Primer, 27.
101. Agile Contracts Primer, 27; Bird & Bird & Contracting for agile software development projects, 16; Contracting for Agile: Finding a better way, 6.
102. Agile Contracts Primer, 27.
103. Austech v Oz Wilde, [35].
104. Ibid, [75].
105. Agile Programming – Introduction and Current Legal Challenges 6; Bird & Bird & Contracting for agile software development projects, 11.
106. Agile Programming – Introduction and Current Legal Challenges, 6.
107. Comparing Requirements Decomposition Within the Scrum, Scrum with Kanban, XP, and Banana Development Processes, 68.
108. Ibid, 69.
109. Bird & Bird & Contracting for agile software development projects, 11; Agile Programming – Introduction and Current Legal Challenges, 6.
110. Contracting for Agile: Finding a better way, 3.
111. Bird & Bird & Contracting for agile software development projects, 11.
112. Austech v Oz Wilde, [72]-[75].
113. Agile Contracts Primer, 22-23.
114. Agile Programming – Introduction and Current Legal Challenges, 7-8.
115. Ibid, 10.
116. Contracting for Agile: Finding a better way, 3.
117. Bird & Bird & Contracting for agile software development projects, 15.

Norton Rose Fulbright, ‘The art of the agile deal’, Norton Rose Fulbright (Blog Post, May 2018) <https://www.nortonrosefulbright.com/en-gb/knowledge/publications/82c726cc/the-art-of-the-agile-deal

Return