Three fundamental and independent decisions
When designing contracts for the manufacture of products with the help of Scrum, there are three fundamentally independent decisions to be made:
- Is the work of the product owner completely taken over by the client or is a significant part of the work of the product owner and thus the definition of the product features carried out by the contractor?
- Is a fixed price agreed or is billing based on time and effort?
- Is it a contract for work or a contract for services?
1) Who is the product owner?
In line with the Scrum values (close collaboration), the ideal form is for the client to take on the role of product owner; this also corresponds to their role as payer. In this case, the client formulates and details the requirements for the work to be created themselves and adapts the requirements in accordance with the Scrum rules. This gives the client a great deal of flexibility. During the creation of the product, he gains an increasingly precise idea of the product through the increments and sprint reviews and can adapt the requirements.
On average, around 50% of the requirements of a product are adapted during production. Scrum offers the client a pragmatic procedure for such changes. Alternatively, the contractor can also formulate or detail the requirements instead of the client, thus making the client's work easier and partially relieving them of it. In this case, the contractor takes on a significant part of the product owner's work. However, this has the disadvantage that the customer is much less involved in the concrete design of the product, has much less influence on this and there is a risk that the product will not meet the customer's expectations.
Experience shows that many clients initially find it difficult to be closely involved in the project as a product owner, but after a few sprints they fill the role and see Scrum as a very good approach. The advantages cited by clients include: the continuous creation of requirements instead of a large amount of work in advance, the ability to refine requirements and the regular, visible progress that provides confidence and motivation.
2) Fixed price or billing on a time and material basis?
With a fixed price (also known as a flat rate), a fixed price is agreed and charged for a service, regardless of the actual (time) expenditure incurred. With time-based billing, the actual time required for a service is invoiced.
By using timeboxes, a Scrum project naturally works with fixed efforts and fixed teams. This applies to both a sprint and a release. Requirements and results are adapted to the timeboxes. The fixed price is therefore the "natural" form of billing for a Scrum project.
3) Contract for work or contract for services?
In a contract for work and services, a contract is concluded with the contractor for the delivery of a predefined work. The contract for work and services aims to achieve a result that has already been defined when the order is placed. The contractor undertakes to produce this work in return for remuneration (fixed price or billing according to time and effort). Whereas in the case of a service contract, only the provision of an average quality service as such is owed without guarantee of the hoped-for or intended result, in the case of a contract for work and services, success is owed in the form of delivery of the agreed work. Accordingly, in the case of a contract for work and services, the contractor only receives his money once he has delivered the work and the customer has approved it (acceptance). A contract for work and services therefore requires a clear agreement on comprehensible and clearly verifiable acceptance criteria. The client has a two-year warranty on the delivered work if it has defects, i.e. if it does not meet the agreed requirements.
In contrast, in the case of a service contract, payment is owed upon provision of the services, regardless of whether the service has produced any result, in particular a result that the client can use. Consequently, there is no warranty for errors in the result, as no result is owed. However, a so-called poor performance, i.e. a performance below average, can result in claims for damages on the part of the client.
There are a number of options when selecting and structuring the type of contract. These are characterized by the flexibility that the client has or needs in order to sharpen and improve the benefits of the product during development. When drafting the contract, the question therefore arises as to how flexibility and improvement of the product are weighed up against the security that firmly defined requirements entail. In the first case, there is a risk that the contractor will not deliver the desired results due to poor skills and still have to be paid for it. In the second case, there is the risk that the client receives a work that meets the requirements but is still not optimal, as the possibilities for improvements are stalled "along the way" and the product then either does not fulfill what the client actually imagined despite adhering to the original specifications or in any case does not reach the optimal, actually possible level.
Three approaches for agile contracts
Option 1: The client formulates a contract for work and services with the help of a specification sheet that defines the work to be carried out.
The contractor uses Scrum to produce the defined work and assumes the role of product owner. This form of contract makes sense if the client is certain that there will be no changes to the requirements and that the work will deliver the benefits if it is produced exactly as specified. Statistics show that this situation is very rare and only occurs in very small projects. This type of contract structure therefore only makes (economic) sense in a few cases. In principle, Scrum is not visible to the client in this contract structure. The benefits of Scrum are essentially limited to the contractor. The contractor uses Scrum to ensure that the predefined work is produced effectively and efficiently. The benefits of Scrum for the client, i.e. being able to refine the product and its benefits during production, are foregone with this form of contract.
Option 2: A contract for work and services is agreed that only roughly defines the work and its characteristics.
At the same time, the contractual partners agree that the details will only be jointly defined during the course of development as part of the sprints. In this case, the product target and the release targets (possibly with corresponding acceptance criteria) specify the trade - the detailed requirements for the product, on the other hand, are not part of the specifications to be made to the trade.
The risk for the client in this case is that the contractor does not provide the expected service and ultimately does not deliver the desired work with the contractually agreed benefits. The client may then not have to pay, but will have lost a lot of time (and possibly money). Overall, this form of contract offers plenty of room for ambiguities and misunderstandings and therefore also for subsequent disputes. Also, there are probably only a few contractors who are prepared to guarantee the delivery of a final work if they cannot determine or foresee how they can/must achieve the goal.
These risks can be limited:
- Use of Sprint Reviews & Refinements:
One solution is built into Scrum: Sprint Reviews and Product Backlog Refinements with the client. Based on usable increments, the client can see that - and how - progress is being made. In the product backlog refinements, the client is closely involved in detailing the objectives from the work contract. If the client is granted the right to terminate after a sprint review and only pay for the working time up to this point, then there is also a "ripcord". Experience shows that it is very unlikely that a team that reliably delivers increments in every sprint will suddenly fail.
- Partial products as a trade:
Instead of agreeing the entire trade, the contract only refers to a release or a sprint (e.g. agreement of the sprint goal as success). Initially, contracts can also be concluded for sprints until the client has sufficient confidence to order larger trades (release, overall result).
- Scrum artifacts with as a trade:
The Scrum artifacts are included in the contract as deliverables. This ensures that Scrum is carried out properly. As the proper implementation of Scrum is the key success factor, the success of the project is ensured by agreeing the Scrum artifacts.
During the production of the work, the client works as the product owner and continuously specifies or details the requirements for the product, checks the increments and uses the findings from the sprint reviews to refine the requirements and the product.
The client may not have the skills to work as a product owner at the start of a Scrum project. In this case, he can be supported by the contractor in defining the requirements. However, the client remains responsible for the detailed requirements in this type of contract.
Option 3: The client agrees a service contract with a fixed price.
This is typically done for a sprint. Here too, the client works as the product owner. This form of contract reduces the contractual effort.
Advantages and disadvantages of the solutions:
The simplest contract option is the service contract with a fixed price (approach 3). It makes sense if there is a good level of trust between the client and contractor. In principle, this is the most "natural" contract structure, which also corresponds most closely to the Scrum principles (collaboration before contract negotiation). Such a contract has a limited risk for the client (maximum one sprint) and is easy to implement. The contractor has the advantage of receiving his money even if the client's expectations are not met due to the initially vague specification.
A work contract for the use of a sprint, a release or the entire product, which gives the client the control options as product owner, is an alternative form of contract (solution approach 2). This form also implements the Scrum principles and emphasizes the benefits of Scrum (punctual delivery, maximum return on investment of the product).
A traditional contract for work with detailed requirements in a specification sheet (option 1) effectively deprives the client of the benefits offered by the Scrum framework. The use of Scrum in this contractual context primarily helps the contractor team, not the client.
Comments
Write a comment