If you are a project manager, project director, business manager or delivery manager, and you intend to conclude an agile contract with your customer, this guide will become your companion and show you how to draw up this contract professionally.
It will be of great help to you to successfully conduct this agile pre-sales phase. Other articles will follow where you will discover everything you need, from understanding the client’s needs to signing the contract, including estimates. It’s really the essential tool for you!
Can the agile methodology be applied to all projects? This question will be explored in this article. We will mainly cover the following points:
- The various agile contracting approaches.
- The fundamentals embedded in an agile contract.
- The use of an assessment tool for the agile approach
- The contractual phases of the project.
By the end of this article, you’ll have significant tools to work with your client to make important decisions about the type of contract to make, whether it’s in time and materials (T&M) or fixed-price, as well as the methodology to be followed, whether it is an approach to sequential (V-Cycle) or Iterative Agile.
“Collaboration with customers rather than contract negotiation.”
Excerpt from the Agile Manifesto
Agile Contracting Approaches
In an Agile project, the CLIENT and SERVICE PROVIDER teams work closely together to bring the development teams closer to the business teams. The roles and responsibilities of the CLIENT and the SERVICE PROVIDER evolve according to the context. Nevertheless, the contract remains an essential element in establishing the relationship between the CLIENT and the SERVICE PROVIDER:- The commitment of resources (on a time-of-sale) remains the simplest contractual form to initiate an Agile project. The responsibility for demonstrating non-compliance with the commitment lies with the CLIENT.
- The commitment to results (in a fixed price) responds to the need to guarantee a specific result within a predefined budget. The responsibility for demonstrating compliance with the commitment rests with the SERVICE PROVIDER.
- The goal is to design an Agile contract that inspires confidence in BOTH PARTIES in their ability to deliver on each other’s commitments while respecting the values and principles of the Agile Manifesto.
- It’s hard to say exactly what’s going to change along the way.
- It’s hard to fully commit to collaboration.
- A contract under time and materials (T&M) (where the CLIENT takes the risks by committing to the means).
- A fixed-price contract (where it is the SERVICE PROVIDER who takes the risks by guaranteeing results).
In both situations: The product is not the focal point of the project, and mutual interest is not preserved in the absence of a fair distribution of risk.The Agile contract should be designed so that the benefits and risks are better shared when we work together to create the product. This is done by breaking down the work into small steps called sprints and quickly validating what we are doing.
Here is a list of criteria to consider when deciding which project management method is best for your situation, whether you opt for a time and materials (T&M) contract, a fixed-price contract, or an agile approach.
| Possibility of | Time and materials (T&M) | Fixed Price | Agile |
|---|---|---|---|
| Budget modification | Yes | No | Yes |
| Changing the Scope | Yes | Via Amendment | Yes |
| Intermediate product | No | No | Yes |
| Resource Selection | Yes | No | Yes |
| Collaboration | Limited | Average | Strong |
| Risk carried by | Customer | Provider | Client and Service Provider |
| Constraints | Cost | Cost + Time + Scope | Cost + Time |
Finally, the contract is first and foremost a partnership, an alliance, a mutual agreement between the client and the service provider that lasts throughout the project. Here is a list of commitments that each party should consider very carefully:
THE SERVICE PROVIDER
Time Commitment & Budget
Product requirements are defined (granularity, limits, cost) for a fixed budget and timeframe At the end of each sprint:- Evaluate the adequacy of the product increment with your challenges
- Encourage the incorporation of new requirements, replacing others that are of lower priority.
Frequent & Quality Deliveries
Each iteration creates a high-quality interim version, which can be put into production if necessary. No compromise on quality.Visibility & Collaboration
Joint sharing in full transparency of the project’s progress: deadline, functional coverage, risks, tests, etc.THE CLIENT
Perpetual Challenge of Need
Give yourself the ability to identify and prioritize requirements (if everything is a priority, nothing is a priority) Agree to postpone secondary or unclear requirements to future versions.Maximum uptime
Ensure a strong presence throughout iterations:- Prepare iterations (content, acceptance scenarios)
- Get involved in design workshops
- Provide business support during development
- Quick acceptance (5 days) reiterate each iteration
Decision-making ability
Product Owner and Product Owner Proxy (Client) in permanent collaboration to facilitate daily and strategic decision-making.Fundamentals of an Agile Contract
After orchestrating the completion of more than 30 projects by adopting the agile methodology, we distilled a series of essential points that should be integrated into every agile contract:- Putting the product at the heart of the project
- Empowering teams
- Collaborating effectively
- Managing change
- Sharing the risks
NB: The word Unit of Work (UW) means one day of development + unit tests
1. Put the product at the heart of the project
Share the Product Backlog at the beginning of the project
Description:
Advantages of updating the Backlog and costing with the CLIENT:
- Be sure to have a shared initial vision of the software.
- To give the CLIENT confidence when bartering requirements.
- Have a prioritization that takes into account the true business value.
- Have a backlog that uses business vocabulary.
- Product Backlog : The scope of the project is defined by the project’s priorities within the budget.
- Product Backlog Review: Ability to review the Product Backlog during the course of the project.
Sharing the Product Vision
Description:
In product and release planning, favor a horizontal rather than a vertical approach. If possible, provide a V1 and V2 for each feature. Keeping the schedule is more important than the complexity of the features to be onboarded.
Means:
- Roadmap Committee: before each Release (agile framing if necessary), review the vision and the means to achieve it.
- Product Backlog Review: Adjustment of the current Release.
Simplification at the centre of concerns
Description:
The Product Owner must propose simplifications and challenge those proposed by the development team. Simplifying the product allows you to arrive at a satisfactory result more quickly and leaves enough room to accommodate new features that are higher priority.
Means:
- Technical-functional workshops: The development team should propose simplifications of features or ways to stay in the native of the product.
- Product Backlog Review: Adjust costs if necessary.
Deliver at each sprint
Description:
Each sprint ends with a Sprint Review that is demoted to get feedback from STAKEHOLDERS and see progress (Done).
Means:
A delivery report is issued at each Sprint that mentions the delivered features and associated unit of work (UW).
Temporary acceptance for each Sprint
Description:
The acceptance must start as soon as possible: inside the Sprint for the team, as soon as the Sprint is received for the CLIENT. Quality is non-negotiable.
Means:
- It is the Product Owner’s responsibility to check the quality of the product even in the event that he delegates a PART of the verification to a Quality Analyst of the SERVICE PROVIDER.
- Obligation of the CLIENT to test each Sprint delivered and to pronounce the acceptance before the next Sprint.
- A provisional acceptance report is issued for each Sprint acceptance.
- Follow-up of the default rate (included in the Project Plan).
2. Empower teams
Importance of the Product Owner
Description:
The Product Owner is the main decision-maker on the project and a success factor:
- Mastery of the product’s challenges and the specificities of the business.
- To the delegation of decision-making.
- Is available to be able to arbitrate, to decide in a short time (< 1 day on average)
- Knows how to relinquish demands (accepts the principle of barter)
- Product Owner: The CLIENT commits to provide a Product Owner with the required qualities.
Team Excellence
Description:
The SERVICE PROVIDER’s team must be heavily involved in the project. Depending on the CLIENT’s experience on Agile projects, the SERVICE PROVIDER’s Scrum Master can quickly become essential to the smooth running of the project. Generally, 1 or 2 engineers on the SERVICE PROVIDER side are also essential to the technical success of the project.
Means:
- Indicate in the special conditions, the key members of the team necessary for the success of the project: these members cannot be replaced without the approval of the CLIENT on the new profile (plus long notice period)
- To be contracted only at the request of the CLIENT with a reciprocal clause on the CLIENT’s key players.
Availability of the CLIENT
Description:
An Agile project requires a significant human investment from the CLIENT – especially the Product Owner and the actors of the acceptance. The CLIENT must provide resources, preferably on a full-time basis.
Means:
- Indicate, under the special conditions, the estimated load of the typical profiles required for the proper execution of the project.
Service Levels
Description:
Service level indicators are measured throughout the project, such as velocity, quality, etc. Certain service levels can be defined to measure the quality and cohesion of all teams (SERVICE PROVIDER and CLIENT)
Means:
- The SERVICE PROVIDER commits to carry out the services in compliance with the Service Levels defined in the Project Plan.
- Service levels are defined during Sprint Zero and then validated in the calibration phase of the project.
- Service levels can mainly be used to measure the performance of the SERVICE PROVIDER’s and CLIENT’s teams.
3. Collaborate effectively
Duty of transparency
Description:
All IT projects are susceptible to difficulties that were not identified at the time of contract conclusion. Each of the PARTIES commits to be as transparent as possible vis-à-vis the other PARTY with regard to the difficulties it may encounter, whether technical, financial, human, organizational or logistical.
Means:
- Each PARTY commits to inform the other PARTY of any difficulty it may encounter, and which is likely to disrupt the proper performance of the services, as soon as possible from the knowledge of this difficulty
- In the event of a difficulty, the PARTIES will seek in good faith a solution to overcome this difficulty while respecting the balance of the Contract or to share the related risks equitably
Proximity of team members
Description:
Teams should be close to each other – and if possible in the same premises. In the case of a remote site (Offshore, Nearshore), the Product Owner must meet with the SERVICE PROVIDER teams at each Sprint.
Means:
- Indicate the place of service under special conditions
- Plan to set up a dedicated space for the project team
- If this is not possible, provide enough meeting points, and travel should be made to the Development team
- If possible, take travel expenses out of the budget and re-invoice them at the actual level
Just-in-time specifications
Description:
To be effective, the development team needs quality inputs to cover the team’s velocity.
Means:
- Define a Specification template that is most suitable for the project at the beginning of the project and the expected degree of depth
- The Product Owner is responsible for providing the development team with validated specifications, even in the event that he delegates a PART of this writing to a Business Analyst of the SERVICE PROVIDER
- To avoid any break in loads, the Sprint specifications are considered validated during the Sprint Planning. Any subsequent changes will be the subject of a new Product Backlog item
Continuous Improvement in Retrospect
Description:
A key success factor of an Agile project is the joint progress of the CLIENT and the SERVICE PROVIDER teams.
The Retrospective is ONE of the essential bodies of the project where all the operational stakeholders must be brought together.
Means:
- The action plans resulting from these retrospectives must be taken care of jointly by the SERVICE PROVIDER and the CLIENT
- The retrospective report must be presented to the Steering Committee. Recurring problems will be dealt with in the Steering Committee.
4. Manage change
Commitment in units of work
Description:
The CLIENT may add or modify functionalities by renouncing other functionalities deemed less important in order to keep its project budget unchanged.
Means:
- Commitment of the SERVICE PROVIDER to a number of Units of Works to be produced within a given period.
- Unit of Work barter system based on Product Backlog priorities.
Commitment to Sprint Planning
Description:
The team, the SERVICE PROVIDER and the CLIENT have the possibility to regularly challenge the estimates,either by comparison with existing charts or by proposing simplifications.
Means:
- The Sprint Planning is the commitment to the costing in unit of work of the items selected for the Sprint .
- Only completed items count towards the Sprint Velocity.
- Any subsequent changes concerning an item embedded in Sprint Planning will be considered as a new item in the Product Backlog to be prioritized and costed.
Estimating requests
Description:
The SERVICE PROVIDER’s team is responsible for costing the requests in the Product Backlog, which must be justified to the Product Owner. The encryption method must be defined transparently with the CLIENT.
Means:
- Define in sprint 0 the method of estimating the elements of the Product Backlog (included in the Project Plan)
- In the case of additions or changes, the initial Product Backlog serves as an abacus by comparing features of similar complexity.
- 1 Unit of Work corresponds to 1 day of coding and unit testing by default.
5. Share risk
Early Exit Clauses
Description:
An agile project must be carried out in a collaboration of the 2 PARTIES throughout the project in the interest of the Product. The CLIENT may decide at any time that the project has achieved sufficient objectives to meet its needs. The SERVICE PROVIDER may decide to terminate the CONTRACT in the event of economic breakdown.
Means:
- Exit upon early achievement of objectives, the CLIENT must have the possibility to exit the project with a win/win share of the unused unit of work (UW) (several cases are provided)
- Economic termination clause for the SERVICE PROVIDER based on the Projected Profitability (Velocity / days consumed): threshold to be defined.
- Early Exit Warning Period = 2 sprints.
Outbound reversibility
Description:
At the end of the project or in the case of an early exit, the CLIENT or a third-party buyer must be able to continue developing the product
Means:
- Commitment of the SERVICE PROVIDER to offer a reversibility quote at the request of the CLIENT
Exit clause at the end of the launch
Description:
The scoping phase (sprint 0) is an essential phase to prepare for development and ensure that the project is on track. If the product vision is not conclusive or if the teams do not share agile values, the project exit at the end of the launch is considered.
Means:
- Define Sprint 0 (Launch) Acceptance Criteria
- In the event that the criteria are not met, it is possible to extend sprint 0 or exit the contract
Service Level Calibration
Description:
The velocity of the development team stabilizes at the end of the first 3 sprints after continuous improvement
Means:
- Final commitment of the SERVICE PROVIDER on service levels (including velocity) at the end of the first 3 sprints
Solidarity performance
Description:
Principle of sharing gains/losses between the CLIENT and the SERVICE PROVIDER in relation to service level objectives
Means:
- Defined Service Level Objectives in the Project Plan
- Product-Specific Objectives
- Clause de Bonus/Malus
Invoicing
Description:
To support the Agile process, it’s worth establishing a payment schedule only on features that have been delivered compliant
Means:
- On a flat-fee basis, invoicing is done per sprint in proportion to the unit of work delivered
- For time and materials (T&M) , billing is based on time spent
Agile Assessment Tool
Not all projects lend themselves to agile methodology, and sometimes it’s best not to approach them in agile mode. In many cases, it is better to maintain a more traditional approach, such as the sequential V-cycle. In this approach, we start by defining the product in detail, then move on to the development phase, followed by the validation phase. The table below presents a series of criteria: if the cursor is on the right-hand side, it suggests that an agile approach can be considered, while if it is on the left-hand side, a classic sequential approach is preferable.| Criterion | V-Cycle (Waterfall) | Weight Methodology | Iterative Agile |
|---|---|---|---|
| Vision | Clear / Shared |  |
Blurred |
| Scope | Detailed / Accurate |  |
Moving / Blurred |
| Requirements | Stable |  |
Informal |
| Decision-Making | Long / Collective |  |
Fast / Centralized |
| Customer Availability | Limited |  |
Strong / Dedicated |
| Project size | < 200md |  |
> 1000md |
| Schedule | Flexible |  |
Time to Market |
| Budget | Editable |  |
Fixed “Design to cost” |
| Approach | Sequential / V-Model |  |
Agile / Iterative |
Contractual Phases of an Agile Project
This table summarizes the five stages of an agile project, namely the pre-sales phase, the initial launch sprint, the adjustment phase, the execution phase, and finally reversibility.Pre-sales
- Define the project budget and schedule from the initial Product Backlog based on the product vision and roadmap.
- If the inputs are not sufficient, propose an agile framework to define the vision and roadmap of the product.
1
Launch (Sprint Zero)
- Ensure that all the predefined criteria are met to start development in good conditions, otherwise postpone or cancel the development.
2
Calibration (sprints 1 to 3)
- Calibrate the development team’s service levels for continuous operational improvement.
- Make a definitive commitment to service levels.
3
Operational (sprints 4 to N)
- Ensure that commitments will be kept.
- If not, take the necessary steps to meet the commitments.
4
Reversibility
- If requested by the CLIENT, transfer the acquired skills to a third party in charge of taking over the corrective and evolutionary maintenance of the Product.
5
Pre-sales
- Define the project budget and schedule from the initial Product Backlog based on the Product vision and roadmap
- If the inputs are not sufficient, propose an agile framework to define the vision and roadmap of the product
1
Launch (Sprint Zero)
- Ensure that all the predefined criteria are met to start development in good conditions
- Otherwise, postpon or cancel the development
2
Calibration (sprints 1 to 3)
- Calibrate development team service levels for continuous operational improvement
- Make a definitive commitment to service levels
3
Operational (sprints 4 to N)
- Ensuring Commitments Will Be Met
- If not, take the necessary steps to meet the commitments
4
Reversibility
- At the request of the CLIENT, transfer the acquired skills to a third party in charge of taking over the corrective and evolutionary maintenance of the Product
5
Conclusion
In this article, we explored the two main contracting approaches, namely “time and materials” and “fixed-price“, as well as how an agile contract intervenes to put the final product at the center of the project while managing and sharing the risks between the client and the provider. An agile contract requires a strong commitment from both sides, team accountability, effective collaboration, and the ability to manage changes. After presenting the fundamental principles of an agile contract in detail, we have provided you with a project evaluation table to assist you in deciding on the methodology to adopt: sequential (waterfall) or iterative agile. Finally, for optimal management of an agile project, we have developed a chronological plan covering the period from pre-sales to reversibility.
Complement
Selected reading:
0 Comments