SAFe Managed-Investment Contract

Le contrat d’investissement avec SAFe

In the first article of this series on agile contracts, we dove into the basics and evolution of contracts in software development. We talked about why it’s essential to adopt contract practices that encourage agility across the whole value stream. We also emphasized the importance of transforming the client-supplier relationship into dynamic partnerships that focus on maximizing value delivery. Plus, we looked at how software contracting approaches have evolved and the challenges of adapting traditional contracts to agile contexts, especially when it comes to flexibility and risk-sharing.

We wrapped up the previous article by introducing the SAFe Managed-Investment Contract, designed to balance risks and engage parties while keeping flexibility. Now, in this article, we’re going to share our deployment experiences and some handy tips for implementing agile contracts. We’ll walk you through a model we’ve successfully used multiple times in both the private and public sectors. Keep in mind, you’ll probably need to tweak it to fit your specific situation.


Implementing an agile contract helps tackle several major challenges we often see in supplier agreements:

  • Optimizing value delivery and controlling costs
  • Reducing decision-making delays
  • Adapting to changes
  • Equitably sharing risks between the client and supplier
  • Avoiding rigid and inappropriate contractual frameworks

These are common hurdles for project managers, but the SAFe Managed-Investment Contract offers innovative and effective solutions.

Implementing an Agile Contract with SAFe

Implementing a first agile contract is primarily a team effort that requires close collaboration among various stakeholders. The team is formed around the existing contractual governance. It typically includes key figures such as Enterprise architects, Business Owners, a subject matter expert related to the contract, procurement, and a representative from the legal department.

This team is not a new decision-making committee but a collaborative agile team that can work in concert with the LACE or the VMO. Its objective is to design the best agile contract tailored to the specific context of the company and its suppliers.

Here are the team’s main responsibilities:

  • Identifying needs and requirements, and establishing the timeline for the call for tenders
  • Integrating agile governance into the overall contracting strategy
  • Identifying the legal elements necessary for the execution of the Agile contract
  • Communicating the call for tenders, facilitating workshops, drafting the contract, and selecting the supplier
The Contract Governance Team

The Key Stages of the Agile Contract

The Key Stages of the Agile Contract

We’ve broken down the implementation of an agile contract into four stages:

  1. Pre-commitment
  2. Contract Definition
  3. Contract Execution
  4. Contract Closure

Pre-commitment

This stage covers everything leading up to the selection and engagement with the chosen supplier. It starts with a traditional call for tenders where the client defines the mission, scope, and commercial and legal framework.

After reviewing proposals, shortlisted suppliers are invited to individual workshops to:

  • Clarify the product vision
  • Discuss the desired Minimum Viable Product
  • Explore the agile methodology to be used for work execution
  • Validate the contract’s economic framework
Pre-commitment

These workshops aim to build mutual trust and assess the suppliers’ ability to meet all the clauses related to the methodology, which is crucial for choosing a collaboration partner.

If the context allows, there might be a negotiation phase. Suppliers can adjust and resubmit their offers based on the information gathered during the workshop.

The final selection of the supplier considers traditional criteria like cost, quality, and the supplier’s ability to deliver the solution, but also how well they can collaborate and adapt to the agile methodologies.

Contract Definition

Once the supplier is chosen, it’s time to agree on and sign the contract.

Contract Definition

The contract includes traditional clauses such as the vision and scope of the agreement and specifics related to the agile approach, such as the agile roles and responsibilities, the delivery methodology, and the terms for tracking deliverables and quality.

Optional clauses may include requirements for the supplier, such as training in the chosen delivery methodology, provisions for team maintenance post-delivery, or specific conditions for the contract’s conclusion.

Roles and Responsibilities

A central element of the agile contract is the definition of roles and responsibilities for both the client and the supplier. This can be done in two main ways:

Supplier as Agile Teams within an ART

In this setup, the supplier integrates into the client’s Train as agile teams, the client retains roles at the Train level such as RTE, Business Owners, Product Management, and System Architect. Train events like PI Planning preparation, PI Planning, team coach sync, PO sync, System demo, and Inspect and Adapt enable the ART to plan, execute, and validate the supplier’s value increments.

Agile Delivery Train events

Supplier as an ART within a Solution Train

When the supplier integrates as an autonomous ART within a Solution Train, they assume all ART roles except for the Business Owner. The client, on the other hand, provides the essential roles for the Solution Train, including the STE, Solution Management, Solution Architecture, and the Business Owners.

Solution Train events

The activities for planning, executing, and validating value increments can be initiated by the supplier Train’s events and by the Solution Train’s events. These events include the Pre-Plan Workshop, Solution Train PI Planning, Solution Train Synchronizations, Solution Demo, and Solution Train Inspect and Adapt. Selecting these events based on the context is crucial for clearly defining everyone’s responsibilities.

Obligations

An important aspect of the SAFe Managed-Investment Contract is that it establishes obligations for both parties, not just for the supplier.

For example, the supplier must form and maintain their teams, deliver according to the agreed methodology, and ensure the quality of their services. However, the client must also provide all required information, make competent resources such as Business Owners and other key roles available, and ensure access to the technical environment necessary to complete the work.

The respective responsibilities of the client and the supplier

Both parties commit to communicating openly about any issues encountered, maintaining transparency, and proactively seeking solutions. Collaboration, transparency, and risk sharing are essential for the success of an agile contract.

As with traditional contracts, it is also important to specify that there is no subordination relationship between the client’s staff and the supplier’s staff to avoid illegal subcontracting.

PI Planning

PI Planning is a critical moment demonstrating the agile contract’s full flexibility. Each PI Planning session is a mini-contract, a three-month addendum where the client and supplier agree on a set of PI Objectives. We recommend setting 15% to 25% of uncommitted PI Objectives and 75% to 85% of committed PI Objectives. The PI Planning facilitates alignment and adaptability, leveraging the context’s inherent variability. It also enables continuous adjustments to the overall agreement based on evolving needs, thus maximizing delivery value.

Focusing on PI Objectives shifts the evaluation towards tangible results, emphasizing outcomes over completing deliverables such as features or user stories or tracking throughput measures like velocity or hours worked. PI Objectives enable an outcome-based contract approach; they form the basis for performance evaluation and will impact billing.

Performance Evaluation

These objectives are evaluated not just on their statement; we’ve also added specific acceptance criteria to the PI Objectives to make them more precise. This ensures a clear and transparent assessment of the team’s performance.

Acceptance Criteria Should Be:

  • Clear and Specific: Formulated in a way that is easily understood by all stakeholders, including development team members and non-technical stakeholders.
  • Measurable: They should indicate expected results and how they will be measured.
  • Directly Linked to a Business or User Objective: Ensuring the effort contributes to the company’s overall strategy.
  • Realistic and Achievable: Within the scope of the PI, considering available resources and time constraints.

Example of Acceptance Criteria for a PI Objective

Context: Our goal is to launch a new service that allows users to track their daily expenses.

PI Objective: Implement and launch an expense-tracking service in the mobile application that should increase user engagement by 20% and reduce customer support requests related to app usage by 10%.

Acceptance Criteria for the Objective:

  1. The service must allow users to enter, view, and categorize expenses.
  2. The service must be integrated and functional on Android and iOS versions of the application.
  3. The service must pass all user acceptance tests, with at least 90% satisfaction in usability evaluations.
  4. User engagement data must show an increase of at least 20% compared to the month before the launch.
  5. Customer support requests related to app usage must decrease by 10% in the month following the launch.

The Three Phases of Execution

During the execution of the contract, we recommend that the client and supplier follow these three phases:

  1. Launch Phase: Initiating the work and setting up the initial framework and teams.
  2. Initial Phase: Start the first planning interval and establish workflow and collaboration.
  3. Nominal Phase: Regular operation, continuous improvement, and achieving planned objectives.
The Three Phases of Execution

Launch Phase: Preparation and Setup

The launch phase of the agile contract lasts only a few weeks. It is crucial for ensuring all necessary conditions for successful project execution are in place. This phase includes preparing the work environment, team building, introducing client and supplier teams to methodologies and tools, and clarifying roles and responsibilities. It’s a time for verification to ensure the contract’s foundations are solid and that both parties are ready to start the contract.

Initial Phase: Settling In and Learning

The client and supplier enter a mutual adaptation and learning period during the initial phase. This phase, typically covering one to three PIs, allows teams to gain practical experience working under the SAFe methodology and refine their collaboration. The focus is on adaptation and adjustment rather than achieving maximum performance, reflecting a flexible and realistic approach to initial challenges.

Nominal Phase: Full Execution and Performance

The nominal phase represents the core of contract execution, where teams operate fully within the SAFe framework to achieve the set objectives efficiently and precisely. This phase is characterized by a regular cycle of PI Planning, synchronization and coordination between teams, and release on-demand. It is the period during which performance is evaluated according to the standards established in the contract.

Billing

The client commits to paying the supplier based on achieving the PI objectives, incorporating a system of financial bonuses or penalties depending on performance.

Evaluating commitments with SAFe events

The agile contract includes various billing scenarios that reward performance beyond expectations and adjust compensation if objectives are not met. Here is an example:

  • Suppliers may receive a bonus if they exceed 100% of their objectives.
  • Achieving between 80% and 100% guarantees full payment of the billable amount.
  • Below the 80% threshold, the supplier receives a portion of the payment corresponding to the percentage of objectives met, potentially requiring renegotiation to deliver the missing objectives in subsequent PIs.
  • During the initial phase, achieving 60% to 100% of the objectives may be allowed instead of 80% to 100%.

Contract closure

Contract closure

An agile contract can end in two main ways:

  • a traditional conclusion where all planned scope or objectives are delivered, resulting in mutual satisfaction, or an early termination, where the client decides that the already delivered scope sufficiently meets their current needs, even if the initial backlog is not fully completed. This flexibility is inherent to the agile approach, allowing adaptation to changing priorities or market conditions without unnecessarily committing resources to less relevant features.
  • In the case of early termination, the agile contract can include specific clauses to ensure a smooth transition for both parties. These clauses typically provide sufficient notice and fair financial terms to compensate the supplier while respecting the client’s decision not to pursue the entire initial plan. This approach emphasizes the importance of collaboration and risk-sharing in an agile contract.

 


In this three-part series’s next and final article, we’ll summarize our approach and list the principles and pitfalls to avoid when establishing an agile contract. Finally, we’ll see how the investment contract managed with SAFe stands out compared to other approaches.


Enjoy this article? Stay informed when the next article is published by sharing your own experience of agile contracts with this short questionnaire : https://forms.gle/5mgc6rnA7HrR3cC68

Want to know more about establishing an agile contract in your company? Contact us at [email protected]

Reference :

 

Written by Etienne Laverdière, SPCT and Hélène MALO-WITTEMBERG, SPC