Those using agile methodology first focus on the methods and becoming familiar with the agile roles, work practices and principles. Regardless of which rules you follow though, these rules don’t address the collaboration of cross-corporate teams. The following article fills this important gap. You’ll learn:
- How cross-corporate collaboration works
- The advantages and disadvantages of how the roles are distributed
- How to write an agile contract that protects everyone involved in this collaboration
Here you’ll find a collection of different contract models specifically for use in agile project environments.
How do agile teams work?
Let’s start with a quick review: an agile team – often a Scrum team – consists of a product owner, a scrum master and three to nine developers. The team uses iterations, called sprints, to focus on the development of a new product or the further development of an existing one. Each product increment should be ready to be demonstrated and potentially delivered by the end of each sprint.
Development cycles should last no longer than one month. The product owner defines the stakeholder expectations. The scrum master acts as team coach and process owner, and helps teams not yet familiar with the new rhythm of this type of development.
Special Download: Agile, Traditional or Hybrid Project Management? (PDF file)
Please fill in the form.
* Required Fields | Data Protection
What is a “product owner”?
An agile team doesn’t have to be a scrum team. It can simply be a group of people that work together using kanban. It can also be a team that employs hybrid elements and combines agile and traditional procedures.
In any case, there’s normally one person who bears responsibility for clarifying, documenting and communicating the requirements. This role is often called “product owner” even in non-scrum teams. However, “requirements engineers”, “business analysts” or simply “customers” can also assume this role. For simplicity’s sake, we will refer to this role as “product owner” in this article.
Contract Model for Agile Projects: Who Chooses the Product Owner?
Cross-corporate scrum teams are actually the norm and might even be considered more common than single-company teams. Many agile teams are therefore faced with the challenge of implementing the scrum team’s rules and ideals without having the corresponding guidelines.
The first step is to clarify which of the contracting parties chooses the product owner. This is important with regard to the customer collaboration over contract negotiation and involves asking the following questions:
- How good is the relationship between the client and the supplier? Will the product owner representing the customer be able to work closely enough with the development team and able to guarantee that he/she will be available as much as needed? And: Do the product owner and the developers trust each other, or is there an air of mistrust?
- Who knows the stakeholders well and understands their needs? Who really understands the market? This should generally be the company commissioning the work.
- On the other hand, who knows the development team well and is familiar with its methods?
- Who is best able to translate and prioritize the client’s requirements at the implementation level?
- How knowledgeable about agile methods are those involved? Is there someone on either side who has experience with being a product owner?
The arguments for having the product owner be someone on the supplier side are:
- Technical skills
- Proximity to the implementation team
- Familiarity with internal development processes
On the other hand, the arguments for having the product owner be someone on the client side are:
- Proximity to the market, the end customers / stakeholders, the requirements
- “Power” or authority through their position as a paying client
Our tip: The best strategy is to discuss the distribution of roles with the contractor and client already during the contract negotiations and then document this in the contract. It becomes even more essential to clearly define the distribution of roles if you decide that the product owner responsibilities should be divided between the contracting parties. We can’t emphasize this enough, because some of the most severe conflicts involving multiple companies occur in projects where the roles weren’t clearly defined. This can often have legal repercussions.
What is a “proxy product owner”?
In addition to selecting a product owner from only one of the contracting parties, there’s also the option of choosing a hybrid solution. This person would then be, for example, a “proxy product owner”. In this case, there’s a product owner from the contractor company and one person from the client company who acts as a liaison to the client.
However, the proxy product owner is generally in a weak position, and therefore has little decision-making authority. This person basically serves as a filter with regard to the requirements.
These and the other characteristics constituting the typical challenges facing a product owner are described by Roman Pichler in his blog article “Avoiding Common Product Owner Mistakes”.
Our tip: People finding themselves in the role of proxy product owner and facing problems should try to resolve the situation, as that’s the only solution. The person should be granted the authority needed to be a “true product owner”, including the authority to make product-related decisions and set priorities, or the role should be given to someone with that authority. At the very least, clearly describe the roles and delineate decision-making responsibilities for them, with an emphasis on communications and alignment between them. Role conflicts will otherwise endanger any efforts to set priorities in the product development.
Other factors you should consider in a contract involving agile projects
OK, you’ve now solved the challenge of who is the product owner? Great! Here are a few other things that should be considered in agile contract management:
- Shared interests and a partnership based on the principle of good faith should be documented in writing.
- It should be clear to everyone what assumptions and leadership principles will prevail in the project.
- Stakeholders at the client’s company should regularly participate in meetings to discuss the details.
- The development team should be able to organize itself within the given framework. The team members are the technical experts for the implementation.
Overview of agile contract models
The following sections describe the various contract models that can be used to write a contract for agile development services. It also discusses the billing practices for each type of agile contract.
Fixed-price models
For clients, fixed-price contracts minimize the risk that costs will exceed the budget. However, there are a number of problems with this model for agile projects. Some feel that fixed price contracts are not suitable for agile projects for the following reasons:
- Not being able to adequately alleviate the risk of missed deadlines or that a product is developed that proves useless for the client.
- The use of agile methods requires development that strongly focuses on the client’s needs. However, it’s very difficult to reach an agreement on the fixed price if the overall functionality hasn’t even yet been defined.
- A fixed-price agile contract often only defines the time frame in which the initial product will be developed. Everything that happens after that point (further development, maintenance and support) is initially ignored.
The following document workflows are often used in such contract processes:
Specifications normally contain important information for the client and are part of the call for bids available to possible bidders. As soon as the collaboration has been agreed, these bidders develop a detailed description of the content and scope (performance specifications or similar). Sometimes this is prepared using a template provided by the client. For agile projects in which the requirements are to be “discovered”, these descriptions can actually hinder innovation. In this case, a more “lightweight” document like a product backlog can be used.
Fixed price with several agile elements
To adapt a fixed-price model to be more suitable for agile projects, you’ll have to include several agile principles in it. The following factors can be considered:
- Functions are not completely defined in the beginning. Each of the contracting parties confirms to the others that they understand this fact.
- There is mutual agreement on the project goals, specifically that there’s a shared vision of the product and a roadmap. There’s a contractual obligation to continually share information via discussions, and not only by sending documents back and forth.
- If problems arise, cooperative approaches are used to solve the problem and the “agile mindset” is emphasized to reduce differences and find common ground. This demands trust and empowerment among all those involved. A reference to an existing approach can be contractually documented. For example, there can be a reference to a scrum guide if the team uses this as a framework.
- The completion criteria (Definition of Done) agreed upon by the implementation team together with the product owner and stakeholders can also be included in the contract. However, you should emphasize that these criteria might change during the course of the project. The contracting parties must understand what exactly a Definition of Done is, how this differs from acceptance criteria, and why this represents a team agreement. Acceptance criteria can also be defined in the contract and serve as a basis for the Definition of Done. Lastly, defined timeboxes for iterations (called “sprints” in scrums) and meetings (and their frequency) can be written into the contract as well.
- Clarification of Roles and Team Charters are other documents that can be included in fixed-price contracts adapted for agile projects.
- In lieu of a scope statement or performance specifications, there can be a contractual agreement on the necessity of a product backlog.
- Roles are clearly defined for the project and documented in the contract. Also documented is who should participate in which meetings. For example, the contractor and the client can each send a representative to the sprint planning meetings to prevent contractual and unpleasant surprises.
- Estimation methods can be used in the way that works best. You’re not required to use agile sizing and relative effort estimations. This is especially true when there are existing methods that have been proven effective. The parties can devote more time to agile estimates if they feel that these would benefit the project. Of course, the parties can also contractually agree to use product or release burndown charts to measure progress.
Prioritization in agile projects
If the estimates prove to be wrong and problems occur, you need to react. In the worst-case scenario, the project must be prematurely terminated. Otherwise, the service provider must make provisions and reevaluate the project portfolio’s priorities to compensate for any problems that affect the project in order to safeguard its own liquidity.
A good strategy is to evaluate the incoming requirements with regard to risk vs. benefit as follows:
Accordingly, more risky work should be completed earlier than other work. This gives you a greater range of options at a time when the incurred expenditures are lower.
Agile fixed-price
The examples described so far serve to gradually introduce agile principles in traditional environments and agreements. You also have the option to make the entire contract more “agile.”
With the “agile fixed-price” model, you first describe the contractually agreed project scope as based on the product vision and provide a very rough description of the features.
Those involved then estimate the overall effort using story points and translate these into person-days. This is done, for example, by simulating the first sprint-planning meeting to provide a reference point.
As a safety precaution, the project can still be canceled at this point if you determine that the effort required is too great. Agreements are also reached on the distribution of risk among those involved in the project. Contractors can obligate themselves to realize all the “must-haves” and only develop additional features if the budget permits it.
A special type of contract for agile projects in this context is the ”Money for Nothing, Change for Free” model of scrum co-inventor Jeff Sutherland. In this case, the client initially follows the traditional course by defining the requirements, and the bidder then responds by submitting a bid at a fixed price. As the implementation begins, the client assumes the role of product owner and manages the product backlog.
At each sprint review meeting in which the service provider presents the results of the previous iteration, the client − as is typical in scrums − provides feedback and revises the product backlog. However, the fact that this is a project with a fixed-price contract makes it special in that there is an agreement that: for each new requirement added to the backlog − in the form of a user story − a requirement with a comparable level of effort must be removed from the backlog. This is the “Change for Free” part of the contract model.
Another unique characteristic is the “Money-for-Nothing” principle. This applies to cases in which the bidder and service provider agree at some point to end further development of the product and terminate their collaboration on this topic. If there is money left in the original budget at this point, the contracting parties split this money in accordance with the percentages previously defined in the contract.
As innovative as this “Money-for-Nothing” principle is, and despite it being so compatible with the agile development environment, there’s still a problem in that the existing processes in most companies don’t allow any remaining budget to be distributed.
The “Change-for-Free” idea, on the other hand, has proven to be successful in actual projects.
Fixed price: payment per sprint
You can also make your basic contract more agile by reaching an agreement on a payment cycle aligned with the sprint rhythm − hence, a fixed-price per sprint. In this “fixed-price per sprint” model, the contracting parties essentially have many small fixed-price projects, whereby each iteration represents a mini-product. Each sprint plan leads to a new contract and each review represents an acceptance meeting. The time frame of each sprint is thereby clearly defined. Similar models are frequently used by U.S. regulatory authorities, where they are known as “Blanket Purchase Agreements” or also “Indefinite Delivery / Indefinite Quantity” (IDIQ) contracts.
Time & Materials (T&M)
In a Time & Materials contract, the client obligates itself to pay the contractor in accordance with the time spent on the work and the materials used. This type of contract is very suitable for agile project situations that lack very detailed information, especially initially.
However, it’s vital that the contractor not take unfair advantage of this situation, and remain honest and truthful in documenting the incurred expenses. The contractor also has less incentive to work effectively. If there is a dispute and the two contracting parties in a T&M project go to court, there’s another potential problem in that the relationship could be interpreted as a form of employee leasing.
One solution could be to adapt the T&M contract to create a “Design to Cost” or “Pay per Productivity” contract.
- “Design-to-Cost” contracts have a fixed budget but a more flexible project scope. This type of contract is especially well-suited to situations where the contractor is able to propose price amenable to them based on their prior experience with similar projects.
- In a “Pay per Productivity”contract, the contractor contractually obligates itself to a specific productivity rate based on the agreed criteria. The objective is to provide an incentive to maintain a high standard of product quality. A large portion of the paid productivity is otherwise spent on simple maintenance and rectifying problems. However, this model doesn’t really focus on the client benefit because the teams could theoretically be working very effectively on functionality that does little to benefit either the client or end-user.
T&M: payment per sprint
The “Pay what you get” model is similar to the “fixed-price per sprint” one. However, there is an explicit agreement that the client will only pay for the deliverables accepted in the sprint review. This works if there is a high degree of trust between the contracting parties.
Otherwise, it generally doesn’t work because the supplier is required to provide the goods and services in advance for the duration of the sprint before getting paid.
Other forms of hybrid and customized contracts for agile projects
There are numerous other hybrid and customized contracts in addition to the most common ones: fixed-price and time & materials. Past experience with agile projects has shown the following ideas to be among those feasible:
Benefit-oriented contract models
Developing a value-adding product is one of agile development’s key objectives. None of the contract models presented so far helps to ensure that this objective is achieved. Legal experts are therefore often relatively unfamiliar with these contract principles. However, these can hold the solution for dealing with the high degree of complexity and uncertainty in today’s software projects.
Cost-benefit relationships must be continually monitored when using such contractual agreements. It must be possible to ensure a reasonable balance between effort and result over a longer period of time.
Benefit-oriented award agreements
There are contract models in which the client pays a relatively small daily rate intended to cover the contractor’s costs. To enable the contractor to make a profit, an award is paid whenever an agreed value-in-use goal is reached.
In this case, it must be clear to all involved what the client considers “value” and how this is measured. This is done using impact maps.
“Pay per Use”
Value-based payment agreements, such as many of today’s SAAS solution licensing models, are also considered value-in-use contract models. These are also suitable for agile projects.
Handpicked Content: Read more about how agile methods can make resource management succeed: Resource Conflicts in Projects – Can Agile Planning Reduce Them?
Which contract type is most suitable?
| Contract type | Sub-type / variation | Characteristics | When suitable? |
| Traditional fixed-price | Rather inflexible: Less suitable if flexibility in the product development is needed | Suitable if the effort can be precisely determined beforehand | |
| Fixed price with agile elements | Still rather inflexible, but it generates an initial awareness of agile concepts | Hybrid project approach, new introduction of agile principles in a traditional environment | |
| Agile fixed-price | Product vision and a rough determination of the features are used to estimate a fixed price. This can work, but there’s a risk of problems occurring if the estimates are wrong. | Processes that require a fixed price but for which there’s a strong demand to use agile methodology | |
| “Money for Nothing, Change for Free” | Adds a high rate of change and budget responsibility to a fixed-price project | This model works if there is mutual trust between the contracting parties, a collaboration based on equality, the client is closely involved in the actual work, and the client’s procurement processes allow the use of this model. | |
| Fixed price per sprint | This emphasizes the iterative nature of a scrum team’s work − minimal flexibility broken down into sprints | Mutual trust between the contracting parties, empirical data should be available or quickly obtainable | |
| Time & Materials | Payment and invoicing based on expenses incurred The contractor is flexible as to the work to be performed, which is helpful for agile projects, but there is a risk that something can go wrong. | The client’s trust that the contractor will not abuse this relationship and assurance that this contract model won’t be legally skewed to its disadvantage. | |
| Pay what you get | The service provider performs the work in advance of getting paid, and the client only pays if it approves of the result when the sprint ends. | This demands a high degree of trust among the contracting parties so that there are no unpleasant surprises. | |
| Design to cost | Fixed budget, flexible scope, invoiced in accordance with expenses incurred | Applicable empirical data available | |
| Pay per productivity | Payment based on agreed criteria for the assessed productivity rate; content is flexible | Trust that the contractor will develop something actually useful to the client; strong client involvement | |
| Purely value-added contracts | A focus on the client’s needs is one of agile development’s core principles, and this contract model tries to take this into account. | Good metrics for defining, evaluating and then measuring the added value are available and understood. | |
| Benefit-oriented award agreements | The contractor is paid based on effort and receives an additional incentive for the added value produced. | Good metrics for defining, evaluating and then measuring the added value are available and understood − if possible, and there’s no unpleasant surprise if no award is paid. | |
| Pay per use | SAAS licensing model: the client only pays for the functionality actually used | A project to introduce a license-based software for the client and its subsequent regular use |
Summary and conclusion
Projects are unique, temporary endeavors. No single contract model is the best one for every possible project. The project manager and everyone else involved in the contract negotiations must work together to find the model best suited to the situation and environment of that particular project. This is especially true for agile projects, with all their uncertainty.
This article has presented you with a selection of suitable contract models to use as a framework. You now understand the advantages and disadvantages of designating a product owner from either the contractor’s or client’s side. In addition, you’ve gained an overview of the various agile contract models.
- Now you understand the advantages of setting a fixed price or invoicing based on expenses incurred or other metrics.
- You’ve become familiar with several contractual agreements that are well-suited to agile projects, but have also learned about their limitations.
- You’ve also learned about other substantive factors to consider in your cooperation agreements when using the selected contract model.
And a final tip: The fundamental importance of the “good faith” principle is even greater with agile projects than with other projects. Reaching the shared goals demands that the contracting parties cooperate and not try to take advantage of each other.
The motto should always be a focus on the project’s success. It this really done, then choosing the most suitable contract model is relegated to a mere necessary formality.
Do you have experience with agile contract models? What, in your opinion, requires particular attention? Please leave us a brief comment.
