EAS Recommended Practices - Agile Contracting

Agile contracting
Engagement Assessment Services

Recommended Practice
© 2020 CGI Inc.
Agenda
• Introduction
• Agile contracting must do’s
• Agile contract and proposal aspects
• Agile contract - Legal aspects
• Agile contract types
© 2020 CGI Inc. Internal 2

Agile
“When building an Agile business

you need digital interventions to give
your business purpose”
Agile software development is an approach

under which requirements and solutions evolve
through the collaborative effort of self-organizing
and cross-functional teams and their
customer(s)/end user(s) (Wikipedia)
The term agile was popularized by the Manifesto for

Agile Software Development. The values and
principles espoused in this manifesto were derived
from and underpin a broad range of software
development frameworks, including Scrum and
Kanban (Wikipedia)
The term Agile can be applied on business, portfolio,

program or teams level

Contracting
“If we can continuously ensure we

are delivering on our promises, the
client is successful, and we’re going
to be successful too.”
The contract is a legally binding agreement

which recognizes and governs the rights and the
duties of the parties to the agreement
The contract describes the terms and conditions

defined for both the client and supplier to enable a
successful delivery
The contract describes the scope of supply based on

the client demand translated by the supplier in a
proposed solution

Contracting …for Agile Deliveries
“A good understanding of Agile is

essential to support Agile
contracting”
The legal aspect elements of agile contracts are

the same as for contracts of more traditional
development styles. The key difference is the
approach to and understanding of operational
process that impact the description of these
aspects
An understanding of agile and lean principles is

essential to be able to reduce the risk and exposure
by defining relevant statements in the contract
Successful projects are not ultimately born from

contracts, but from relationships based on
collaboration, transparency, and trust. ‘Successful’
contracts contain mechanisms that support the building
of collaboration, transparency, and trust

Why Agile?
Agile deliveries are value driven
Waterfall Agile
Fixed Scope Costs Deadline
Value /
Vision
Driven
Plan
Driven
Estimate Costs Deadline Scope

Traditional Lifecycles
In waterfall projects, the time to document the
requirements and to create the plan takes a long
Added value after planning phase duration. When finally the development starts and
business value will be shown, often the moment is
there that the client will stop the project.
Planned
Actual
Business value
STOP
Business value
Plan Execute

Agile Lifecycle In an Agile context, the plan phase and execution phase
are short and repeatable activities. Business value will
be delivered on a short term and the client will see
Added Value From The First Execution benefits of the investment. Still we need to manage the
scope and take care that the focus is not only on
business value but also on quality and architecture. A
lack of focus on architecture can result in technical debt
and high refactory costs later in the process.
Planned
Actual
Business value
STOP
Business value
Plan Execute Plan Execute Plan Execute Plan Plan Execute

Execute

Agile Lifecycle
Except on functionality the focus must be on the (right) architectural decisions
Planned
Actual
Business value
Architecture
Business value
Plan Execute Plan Execute Plan Execute Plan Execute Plan Execute

Traditional Vs Agile
Traditional Agile
• Strong dependency between phases • Change inherent to the process

• Changing requirement are difficult to address • Regular insight on measureable progress
• Progress is measured in artifacts • Progress demonstrated through tangible results
• Critical design flaws may be discovered too late • Risks can be identified and remediated early on
• Value is delivered at the end of the project • Customers are involved throughout the project
• Value may not meet expectations • Requirements are prioritized based on value
• Longer project timeframes • Breaks a complex problem in manageable units of work

Agile Contract
Must do’s
© 2020 CGI Inc. 11

What Is The Need For an Agile Contract?
• Agile teams can do their work according to the applied Agile method
• The applied method will be agreed upon in the contract / proposal
• The contract is essential in case of a dispute with the customer
• The customer is not happy with the result but there is no budget to make changes
• The intended result can’t be delivered within the available budget
• The customer is not taking the responsibility as agreed upon (e.g. product owner role)
• Agreed KPI’s are not achieved (e.g. velocity, quality criteria)
• The team doesn’t receive the facilities that are required to do their job (e.g. infrastructure)

Agile Must Do’s
• Proposed CGI Best Practice
Assess client’s level of Agile readiness Hold client kick-off workshop to re-
01 04 confirm alignment with Agile approach &
before commitment
Client role
Adapt contractual model to align with Agile
Implement effective governance (with
(refer to Management Foundation before
05 Client, other projects, and internally);
02 considering fixed price, changes to scope
follow the CPMF
mean more sprints—each sprint has a
cost); follow the Management Foundation,
including BEMF and CMF principles Strong & disciplined Project Management
06
leveraging CPMF principles is required
• No fixed price commitments for non-fixed
scope agile projects;
•
Validate key assumptions with client after
Fixed price commitments must be for one
milestone at a time and have clearly first 2-5 Sprints (plan longer sprints for
07
defined (i.e. fixed) scope and be limited to Government and Large Commercial
short/contained milestones not to exceed 3 clients)
months of effort.
Assign Co-located Agile, experienced,
Establish robust and versatile development
03 capable, and motivated team members 08
and testing environments
with good communication and versatile
skills The CGI Best practices 1, 2 and 5 are worked out in
more detail in this deck as these are Contract related
Assess Client’s Level of
Agile Readiness Before
Commitment (1.)
© 2020 CGI Inc. 14

Agile Business Maturity
© 2020 CGI Inc.

Agile Portfolio Maturity
Agile Program Maturity
Agile Team Maturity
Low Medium High
Low
Agility
Medium
Delivery Risk Vs Agility / Agile Maturity
High
Internal
O
rg
an
iza
tio
n
le
ve
l
15
Agile Business Maturity
Agile Portfolio Maturity
© 2020 CGI Inc.

Agile Program Maturity
Agile Team Maturity
Low Medium High
Low
Agility
Medium
Delivery Risk Vs Agility / Agile Maturity
High
Internal
O
rg
an
iz
a t io
n
le
ve
l
16
Implement Effective
Governance
(With Client, Other Projects,
and Internally); Follow the
CPMF (5.)
© 2020 CGI Inc. 17

Communication
Validation /
Delivery Scope / Specs Develop
Acceptance
Client business team Supplier delivery team
Governance
Business owner Engagement manager

Collaboration & Interaction
Validation /
Scope /
Delivery Specs
Develop Acceptanc
e
Dashboard
Client business team Supplier delivery team
Governance
Business owner Engagement manager

Adapt Contractual Model to
Align With Agile (Avoid
Fixed Price Terms,
Changes to Scope Mean
More Sprints - Each Sprint
Has a Cost.) (2.)
© 2020 CGI Inc. 20

Adapting Contractual Models For Agile
• In Agile development, there are two types of pricing models: time and material or fixed-price
• Time and material: pricing are based on daily rates
• Fixed price:
– The financial model is designed in consideration that the client, being the Product
Owner, has full control in managing scope. As a consequence, and not otherwise, within
a given project, CGI can commit to a fixed-price model, one milestone (release, sprint or
collection of stories) at a time, by defining this milestone’s size in scope and effort to be
small and never to exceed three months of elapsed duration.
– This way to proceed offers both our clients and CGI to mitigate deviation risks. For our
clients, since the milestones are smaller and fixed-priced, this requires appropriate
project governance including ongoing oversight and frequent project reviews. For CGI,
this contains and limits the financial exposure.
– Payment mode: billing, at a minimum, on a monthly basis; however, holdback could be
negotiated but not exceeding 15% of revenue for the committed milestone.

Agile Contract
and
Proposal Aspects
© 2020 CGI Inc. 22

Contract and Proposal Aspects
Contractual agreements
• Controlling specifications Delivery objectives

• Governance and dispute resolution
• Budget and Payment Terms • Business value
• Reporting / KPIs • Client satisfaction
• Acceptance • Financial health
• Changes to supply (changes process)
• Intellectual property
• Warranties and Indemnities
• Liability
• Termination
Client demand Supplier abilities and skills

• Domain expertise
• Scope • Solution
• Budget • Resources
• Schedule • Delivery strategy
• Quality • Planning
• Cost estimation
Risks
Scope Schedule Staffing Financial Quality
Agile Proposal Vs Agile Contract
The proposal describes the way of working of the The contract contains the terms and conditions
team and the agreed results: that are relevant for the delivery:
• Payment Schedule • Acceptance
• Reporting / KPIs • Budget and Payment Terms
• Acceptance • Governance and dispute resolution
• Changes to supply (change process) • Warranties and Indemnities
• Client demands • Intellectual property
• Staffing • Liability
• Termination

The Goals Of an Agile Contract
• Define the conditions to work together in an Agile manner
• Stimulate trust and ownership through transparency and visibility
• Balance economic interests of both parties (short term & long term)
• Motivate to build the best solution possible (within the economic boundaries of the contract)
• Minimize waste and delay
• Controlling specifications
• Budget and Payment Terms
• Reporting / KPIs
• Acceptance
• Changes to supply (change process)
• Liability
• Termination
Agile Contract
Legal Aspects
© 2020 CGI Inc. 26

Controlling Specifications
Characteristics
• Specifications often on a high level (Epics; Features)
• Specifications will be refined during the delivery (user stories)
• Specifications can change during the refinement process
• Specification acceptance criteria must be based on a Definition of Ready (DoR)
• The DoR should contain the level of detail required to accept the specifications for delivery
• Definition of Done (DoD): where possible need to be detailed/strictly defined
• Quality DoD determines outcomes in case of conflicts (in case of conflicts fall back on DoD)
• In a scope-based contract if specifications are added during the term while these don’t
replace other specifications or can’t be delivered within the available sprints, this will need
to be accommodated through additional sprints and managed through an established
contractual Change Request process

Controlling Specifications
Contract type characteristics

• Scope-based contract: scope largely fixed, budget indicative. A highly detailed DoD is
mandatory
• Outcome-based contract: share risk if results are not achieved, different kind of controlling
specifications (result obligation)

Governance and Dispute Resolution
Characteristics
• Agile development relies heavily on governance-type structures
• Agile delivery requires a stronger collaboration and interaction between client and supplier
• Due to the strong client interaction and involvement in the project, the need for escalation is often less
frequent in Agile engagements, but the applicable escalation and dispute resolution procedure should
still be well defined as part of the established governance regime.
• A fast and effective dispute resolution procedure is important given the collaborative nature of Agile
projects
• The role and responsibilities of the product owner must be defined
• Who is responsible for the backlog for the development must be defined
• The collaboration between the product owner and the delivery team must be defined
• Define governance and responsibility on multiple levels (SAFe: Portfolio/Program/Team)
• The contract should encourage informal discussions by the parties with clear and realistic escalation
procedures

Budget and Payment Terms
Characteristics
Budget in Agile deliveries is often defined
A defined budget means that the scope should be variable
Scope management must support both change and variability
It’s often an accepted principle that Agile development will not provide certainty as to outcomes
With a defined budget the acceptable variability of the scope or schedule should be agreed
A defined scope is only possible if the schedule is limited (max. 3 months)
Payment structure should be flexible enough to line up with (uncertain) outcomes which are achieved
• Could be: hourly rate, per sprint or PI, by unit, per achievement, per milestone, per fixed unit.
Depending on the contract type (see 40), the measure/payment structure is determined
Payment terms is independent from milestones and payment is per sprint
Invoicing on a fixed time, payment per milestone no longer applicable

Reporting / Performance Indicators
Characteristics
• Performance indicators are based on the defined objectives for the Agile delivery
• Performance indicators in Agile are often evaluated over a short period (sprint, increment)
• Achievement of performance indicators is not always measurable for a short term delivery
(e.g. sprint)
• Performance indicators are shown on a dashboard for transparency
• Performance indicators can have a target depending on the contract type
• Performance indicators should be based on objective measurements such as ‘direct’
business value, velocity, quality
• Performance indicators only should have a contractual target if that target can be
managed/controlled from a delivery perspective

Reporting / Performance Indicators
• Flexible contract model: No performance indicators required
• Defined team performance: Dashboard used to show the team performance; no contractual
targets
• Other contract models: Performance indicator used to report on agreed upon targets

Acceptance
Characteristics
Acceptance based on intermediate products (Sprint or Program Increment)
Accounting for acceptance with continuous iterations is a challenge
For the acceptance, a Definition of Done (DoD) must be defined
Once deliverables are accepted, they are not to be reassessed in later acceptance processes
Final acceptance is a formality based on previously accepted increments:
• Continuous integration across streams (share same cadence)
To control acceptance:
• Define a minimal viable product (“MVP”)
• Cap costs at specific stages or Sprints or link payment to the MVP
• Include a longstop date for the project

Changes To Supply (Change Control)
Characteristics
• Making changes along the way is part of Agile methodologies
Changes that influence the agreed boundaries need to be managed
Changes are primarily initiated by the client
Boundaries agreed upon with the client need to be defined
• Budget; Time; Business Value; Quality; Scope; Capacity
(Ex)changes can be for ‘free’ if the change doesn’t influence the boundaries (e.g. scope size):
• Every change must be agreed upon and managed / recorded (including changes to the backlog of
a sprint)
• A change must be defined that avoids scope creep / complexity expansion
• Definitions of contractual agreed sizes (e.g. Story Points, Function Points) must be included
• Define how size is determined during the development must be included to be able to determine
the impact of (ex)changes or changes in size during the delivery (e.g. sprints, program increments,
MVP)
• Define how the impact of (ex)changes on the complexity is determined during the delivery
Changes To Supply (Change Control)
Two different types of changes:

• Backlog change: operational changes, approval on lower level
• Contract change: changes on the outcome of the contract, approval on higher level
Change within the boundaries = backlog change. Outside the boundaries = contract change
For changes that impact the boundaries of the delivery, a change process should apply
• Increased size of the scope
• Increased timeline

Intellectual Property
Characteristics Contractual agreements
• The issues are generally similar to traditional • Establish rules for the source of pre-
software contracts (ownership and licensing existing IP
rights) • Establish rules concerning creating new IP:
• The regime will need to reflect the delivery of license or ownership…
product in increments • Retain know-how, templates, processes,
• An additional concern is how to practically protect tools and methodologies
IP in the context of Agile – i.e. when it is “done”
• The collaborative nature of agile may limit the
ability of Suppliers to give comprehensive IP reps
• Lack of up-front documentation also makes
protecting IP difficult

Warranties and Indemnities
Characteristics
Because Customer personnel are involved, there will be difficulty discerning the allocation of
risk and liability between Customer and Supplier
Warranty kicks in on final release or on intermediate deliveries (in longer or more complex
engagements)
Since the functional specifications are not completed at the outset as in traditional software
development, a description of the completed product will need to be created that can be used
as the basis for Supplier warranties:
• Only warranty on the (final) product which originate from the final sprint
• Combining different streams: Joint acceptance process on (final) product or integrated
product

Warranties and Indemnities
Defects as found at the end of a sprint are added to the backlog and will be resolved in the
next sprint
• This conforms to the scrum methodology: defect resolution is built in the project costs
Warranty applies when defects occur after final acceptance (depending on the contract)
• Agreements on the responsibility and payment for warranties should be defined
• If warranty is the responsibility of CGI, it’s advised to add a "premium" to each man day
rate to accrue budget for warranty

Liability
Characteristics
If an overall project timetable is agreed to, in addition to timetables used for iterations (and it
is possible to allocate responsibility for delays), then liability regime (liq. damages) may apply
for missing one or more key milestones or for failing to meet KPI’s (velocity, quality)
• One or more key milestones in time, not in product
However, the Agile methodology and iterative nature of Sprints make it less critical to focus
on legal remedies than on following the process
• The process: meaning the governance and dispute resolution process
The contract will address limitation of liability using similar concepts as a traditional
development contract (waterfall)

Termination
Characteristics Contractual agreements
• Ability to cancel the project • Contract addresses the delivery of work-in-

progress
• Termination of agreement
• Termination for convenience is permissible (e.g.
business value achieved; environmental changes),
providing it is with reasonable notice and any
associated compensation obligations are specified.
• The termination agreement can result in an
intermediate termination of a contract after each
sprint or a specified group of sprints.
• Conditions for a notice period should be explicitly
mentioned (e.g. period of 2-3 sprints)
• Make clear if and when any compensation will be
payable to the Supplier if the contract is terminated
earlier than the agreed notice period and how this
compensation will be determined

Agile and Contracting Models
BEMF & CMF Reference
BEMF CMF
GOV02 LEG02 (2)

Major Processes Applicable Delivery Model
SOL02 Scope LEG02 (6) Pricing and LEG04 (5)

and Responsibility No Fixed price Without Fixed Scope
SOL12 LEG04 (6) Shared Management

Agile / DevOps of Scope and Budget
LEG04 (10) Acceptance

of Deliverable

Agile Contract Types
Characteristics and
Aspects
© 2020 CGI Inc. 42

Characteristics
Flexible contract based on team size
• No defined and detailed scope and time or budget
A constraints
• Flexibility until the end of the project on a time
boxed sprint level
• Basically time & Materials work
Contract based on a defined team performance
• A defined team performance will be agreed upon in
B the contract
• Focus on velocity improvement (after an initiation
phase of 2-5 sprints)
• Basically secondment (effort obligation)
Unit / Output based contract
C • Contract based on performance (e.g. velocity
based)
• Including KPI’s (result obligation)
• Team managed, based on contract criteria
Characteristics
Scope based contract

D • Defined and detailed scope
• Agile delivery
• Budget is indicative (risk sharing option)
Outcome based contract

• Risk share if results are not achieved
• Short term scope
E • Agile delivery part of business process (result
obligation)
• Requires extensive control and cooperation (higher
Agile maturity)
• Not recommended in scenarios requiring multiple
other vendors/suppliers

Agile Contract Matrix
Contract types vs Contract aspects
Complexity
Complexity

Commercial Pros and Cons
Contract type Pros Cons
• Low risk for supplier • Low competitiveness

Model A:
• Clarity about what is contracted (resources) • Focus on rate instead of value
Flexible contract based on team size
• Ability for the customer to stop the contract on a • Risk not shared equally
short term • No insight in longer term revenue
Model B:
• Stability in the team
Contract based on a defined team • Focus on performance instead of on value
• Transparency in performance for the customer
performance
Model C: • Lower risk for customer • Focus on output instead of value

Unit / Output based contract • Higher competitiveness • Difficulty to deliver output in case of team changes
• Defined output in contract • Risk not shared equally
• Detailed controlling specifications

Model D: • Defined and detailed scope
• Extensive reporting/KPIs
Scope based contract • Risk sharing option
• Acceptance based on acceptance criteria
• Result/Outcome based obligation(s)

Model E: • Risk share • Short term scope
Outcome based contract • Maximize delivery of business value • Extensive control and cooperation
• Acceptance based on outcome

A. Flexible Contract Based On a Defined Team Size
Time and Material
Delivery model
An agile team will deliver output based on an hourly rate
The more sprints will be agreed upon the lower the costs (efficiency improvement)
• This efficiency improvement requires a stable team (forming, storming, norming,
performing)
• Determine the options for efficiency improvement if it’s a mixed team (multiple vendors)
Performance indicators
Iterations will deliver a workable product
• This provides clear results for the client after an initiation phase of 2-5 sprints
• The team can report performance indicators (e.g. velocity) but this is not included in the
agreement

A. Flexible Contract Based On a Defined Team Size
Changes to supply (change control)
The contract will be flexible with respect to (ex)changes of specifications
• (Ex)changes in the specifications should be ‘free’
• This implies that one ‘feature’ can be replaced by another ‘feature’ without impact (scope
size must remain the same)
Termination
Clear agreements should be made on when and how the contract can be stopped
• It provides the option to stop with the contract after each iteration
• There must be a notice 1-2 sprints before the contract will be stopped

B. Contract Based On a Defined Team (Cost) Rate
Time and Material with performance monitoring
Delivery model
Defined team with a defined cost rate (P*Q) for 1 or 2 Program Increment (PIs of 3 months
each)
• Focus on velocity improvement (e.g. SP’s / Sprint)
• Improvement can be linked to a bonus system
Responsibilities / Performance indicators

Team should be ‘stable’
• A stable team will guarantee a stable velocity
• A stable velocity is not always possible if a team needs to work on different or new
services

B. Contract Based On a Defined Team (Cost) Rate
Controlling specifications
Product owner determines the functionality
• Measure the satisfaction of the product owner
• Don’t include objectives based on this satisfaction
Capacity
Estimates are required to determine the optimum team size
• Can the team deliver the requested functionality in a certain time

C. Unit / Output Based Contract
Defined Unit /Output Used to Measure Delivery Results
Unit based pricing (price / size unit)
• Size units can be: Function Points, (Advice: do not use Story Points for a Unit / Output
based contract due to the relativity of the size)
• 2-5 sprints initiation phase is required to stabilize the velocity
Delivered functionality is agreed upon with the client (product owner)
• The unit that is used for the pricing is agreed upon with the client
• Unit prices can vary depending on the technology, complexity
• Clear appointments should be made what is included in the agreed unit pricing (e.g.
activities)
• There must be continuity of the delivery

C. Unit / Output Based Contract
Responsibilities
Intention is to maximize the efficiency of the delivery
• The contract must be based on 80% of the expected team velocity
• A delivery manager must manage the overall contract on output (based on metrics)
• A scrum master must focus on the quality of the delivered releases

Fees are paid based on the units realized (after stabilization)

D-1. Scope Based Contract (Defined Budget)
Scope Defined With a Level of Flexibility
Client provides a ‘defined’ scope that meets a mutually agreed quality
It’s recommended to apply the 60-40-20 rule
• Give commitment for 60-80% of the ‘defined’ scope (must have)
• Make 20-40% of the scope flexible (would have)
• Define 20% of the scope as stretch objectives (nice to have; can result in a >100%
scope; can be combined with a reward program)

Budget based on the defined scope (defined budget)
The scope should be concrete enough (detailed DoR and DoD) to be able to provide a defined
budget
Conduct an inspection on the quality of the backlog

D-1. Scope Based Contract (Defined Budget)
Acceptance
Delivery based on acceptance testing
Except the scope also the acceptance criteria should be defined (detailed DoR)
Change
Although the scope is ‘defined’, it must be flexible. An option is to make (ex)changes ‘free’
• Epics or Features can be changed or actually replaced by others (without impact on the
scope size)
• Clear appointments need to be made about this (ex)change process

D-2. Scope Based Contract (Indicative Budget)
Scope Defined With A Level Of Flexibility In The Budget
Controlling specification
A rough scope has been provided (Epics, Features)

Indicative budget can be provided for the defined scope
• An indicative budget is estimated
• Not contractually binding
Risk share on shorter terms only (e.g. 3 months)
• Agreed price based on the defined scope (Epics, Features)
• If maximum price can’t be avoided (after possible actions are taken)
Only x% of the additional costs is charged to the client
The x value could lie between 30% and 70% (less than 30% is not reasonable for
Customer, but preferable for CGI)

D-2. Scope Based Contract (Indicative Budget)
Delivery model
• At the start of the contract a period of 2-5 sprint initiation phase is agreed upon as test
• Final milestone is a checkpoint to decide about further implementation of the project
Termination
• Clearly define points in time where CGI and the client may terminate the contract

E. Outcome Based Contract
Contract Managed Based On Delivered Outcome
Intention is to maximize the delivery of business value
Focuses on outcome (business value) instead of output (e.g. SPs, FPs)
Outcome should be directly related to activities/responsibilities of the supplier
The contract focus is on which value is delivered
The challenge is how to measure the outcome?
• The client has to come up with how the outcome will be measured
• An option is to assign Value Points to Features and prioritize features
• The output required need to be estimated to determine if this can be achieved
• Outcome based is better suited to maintenance than new development

The fees are paid based on the achievement of target outcomes
Risk is that you can’t control the client
• An option is a bonus / malus agreement based on the achieved business value

E. Outcome Based Contract
• Assumption is that features will be delivered based on the defined prioritization and assigned
business values
• Objective is that 80% of the output is achieved
• An incentive system can be applied if:
• More output is delivered (e.g. more than 85%)
• Less output is delivered (e.g. less than 75%)
Changes to supply (change control)

• Changes that will have direct impact on the outcome fall under change control
• (Ex)changes that will not influence the outcome can be managed within the delivery
Responsibilities
• 2-5 sprints initiation phase is required to achieve a stable situation

Contract and
Proposal Aspects
Suggestions
© 2020 CGI Inc. 59

• Controlling specifications Delivery objectives

• Budget and Payment Terms • Business value
• Reporting / KPIs • Client satisfaction
• Acceptance • Financial health
• Changes to supply (changes process)
• Liability
• Termination
Client demand Supplier abilities and skills

• Domain expertise
• Scope • Solution
• Budget • Resources
• Schedule • Delivery strategy
• Quality • Planning
• Cost estimation
Risks
Scope Schedule Staffing Financial Quality
(1)
Contract Element P or TC Notes
1. Definitions P / TC It’s important to define a common vocabulary
Will consist at least of

• Product vision
• Product roadmap
• Initial Product backlog
• If a product vision or product roadmap and backlog does not exist then propose to build it together
2. Controlling Specification P • Agree on / Describe the process and the responsibilities for describing the specifications
• If specifications do exist then determine the quality (intake) and initiate initial refinement when necessary
• Determine if required Domain and Agile expertise is available
• Determine if there is a Product Owner who maintains the product backlog
• The Product Owner must participate in the events to gather the specifications
• The Product Owner must have mandate from senior management
• The Product Owner must promptly answer questions from the Development Team
Reporting structure must be part of the Governance section of the proposal

3. Progress reports and meetings P Describe the minimal required reporting to govern the project
This is about governance but in terms of Agile also about creating the transparency towards stakeholders
Both formal (contractual) and informal (project management) change management processes should be defined; describe what is
normal in terms of the process adopted and what should be part of a formal change management process.
4. Changes to the Supply P / TC When using Scrum as process framework, changes to product backlog is normal as long as this doesn’t influence the scope of the
product. Changes to the Sprint Backlog should be an exception which is part of governance process / formal change management
process.
P = Proposal, TC = Terms & Conditions
(2)
Describe how acceptance works in terms of the adopted Agile/Scrum process:

• Who, what, when, where, how;
P / TC • Interim products, final products;
5. Acceptance
• Acceptance criteria (i.e. DoR, DoD, performance, quality, etc.).
Note: In agile, development will change (parts of) already accepted increments
Describe how to deal with warranties.

This depends on the responsibilities contracted.
Note that in Agile the Client is strongly involved in the process (Product backlog, Sprint review)
6. Warranties TC
Warranties can be given on product quality, bugs etc.; however, warranty on functionality is less common
Warranty requires adherence to project and company guidelines/standards and the use of tools to monitor for example the product
quality
Depends on what accountability/responsibility is contracted.

7. Budget and Payment Terms P / TC
Define what can be invoiced when, and the associated payment terms, etc.
Except the responsibilities as part of process and roles, other client responsibilities should be defined such as providing infrastructure,
8. Client responsibilities P
software licenses, Workplace, etc.. This is part of the proposal but described in a separate section
This is part of regular terms and conditions.

9. Staff TC When we commit to guarantee a staff availability, team stability, no-replacement of key team members etc. this will be part of the
proposal (Also applicable for Client staff)

(3)
10. Confidentiality and publicity TC This is part of regular terms and conditions, not really specific to Agile contracts
Intellectual Property Rights depends on third parties involved in the engagement and are solution specific
11. Intellectual property rights P/TC Contract should protect ownership of CGI tools, processes and methodologies that are pre-existing or intended to be retained by CGI.
To the extent that is appropriate, a license can be provided in respect of these items under an agile contract
12. Infringement TC Not specific to Agile contracts
13. Limitation of Liability P/TC Not specific to Agile contracts
Due to the Agile process it is common to allow for a termination of the contract based on clearly defined conditions.
14. Termination TC Agree on the specific terms and the compensation (i.e. fees payable upon termination).
It’s possible that only a number of sprints are contracted.
15. Export control TC Not specific to Agile contracts
16. General provisions TC Not specific to Agile contracts
17. Disputes and Law TC Not specific to Agile contracts

Suggested Proposal Contents for Agile
(1)
Proposal Element Notes
Executive Summary Not specific to Agile
Vision document, Product backlog, Product Roadmap

Commitments requested (time, budget, scope, quality)
Scope of Supply

Objectives regarding development of Client’s Agile way of working (culture, people, process, tools,)
Delivery process:
• What agile process framework is adopted
• The collaboration between client and supplier
• Roles and responsibilities
• Location of the project activities
• The required development infrastructure
How do we deliver
Governance process:
• Meetings and frequency
• Communications
• Escalation

Specific conditions for key staff should be documented (both for supplier and client)!

Suggested Proposal Contents for Agile
(2)
Proposal Element Notes
Change Management Describe what is allowed within the adopted process framework and what is part of the governance process/contract change process
What is required with respect to quality criteria?

What are the performance indicators?
Quality Assurance Targets for the performance indicators
How do we assure that we are compliant with the quality criteria?
What do we require to comply with the quality criteria (tools, infrastructure)?
What is it that the client needs to provide to be able to do the job
Specific to Agile:
Client responsibilities
• The product owner is not removed from project without agreement from both parties
• Availability of the Product Owner for the Dev Team
When is the delivery successful? E.g.:
• Adherence of client to process framework (also senior management, stakeholders)
Success factors • Availability and active involvement of client representatives
• Product Owner with mandate
• Product Owner communicates with Business owner
Dependencies Describe which supplier services are dependent on associated client activities/obligations.
The number of sprints, increments

Schedule The duration of sprints, increments
Dependencies of the schedule on the product backlog
Depends on what responsibility is contracted.
Buidget and Payment Terms
What can be invoiced, when can it be invoiced, the associated payment terms, etc.
Terms and Conditions Link to existing framework agreement with Client / contract or to CGI standard Terms and Conditions

Definition of Ready (DoR)
Definition of Done (DoD)
© 2020 CGI Inc. 66

Definition of Ready
Ready for Realisation by the Team
Example of Definition of Ready:

• Description clearly articulates the role, action and benefit
• Acceptance criteria clearly defined
• User Experience requirements and artifacts (e.g. wire frames) included
• Supporting documents (e.g. business rules) referenced and/or included
• User Permissions defined (if applicable)
• Performance criteria defined (if applicable)
• Mapped to a Feature and classified as parity or enhancement
• Product Owner identified and has approved the user story
• Development team has reviewed and confirmed they understand
• Includes initial estimation (in story points ) of complexity
• Can be finished in a single sprint
• Sprint Review demonstration expectations defined
A set of minimum criteria before it’s ready for inclusion in the work of the next sprint, agreed by the Scrum team

Definition of Done
Ready for UAT or Production
Example of Definition of Done:

• Code is peer-reviewed and refactored
• Code is deployed to test environment
• Feature is tested against acceptance criteria
• Feature passes regression testing
• Feature passes smoke test
• Feature passes performance test
• Minor defects logged within product backlog for prioritization
• Feature is documented / Product backlog updated with notes and documentation
• Feature okayed by UX designer
• Feature demonstrated in Sprint review
• Feature/Stories accepted and signed off by Product Owner
A shared understanding of which (acceptance) criteria a feature must satisfy to be releasable. They have to provide value
and they have to meet a certain quality standard
Additional Frequently
Used Terms and
Definitions
© 2020 CGI Inc. 69

Frequently Used Definitions
Agile Definitions - 1
Acceptance criteria: Criteria that are added to a Backlog Item to indicate what requirements the
deliverable of a Backlog Item must meet in order to be approved by the (Chief) Product Owner. Acceptance
criteria are specific for only one Backlog Item as defined in the Sprint Backlog or Product Backlog
Backlog: Prioritized feature list, containing descriptions of all functionality desired in the product.
Backlog Item: Description of an specific requirement of the development, consisting of at least: - the
desired outcome, function, performance or other characteristics of the requirement; - the estimated
business value of the requirement; - the estimated development effort (if desired in number of story points)
of the requirement; - the acceptance criteria that determine whether the requirement has satisfactorily been
developed.
Chief Product Owner: the person who creates maximum added value across the various client products
with the available capacity within the Scrum Teams. He is responsible for making the prioritization across
the products in regard to the client’s vision and portfolio product (s) roadmap. The role of Chief Product
Owner is filled by or on behalf of the client and is not part of the Scrum Team.

Definition of Done (DoD): Set of clearly defined criteria that indicate when a Backlog Item (or
set of Backlog Items) is 'finished', including but not limited to the relevant test criteria, product
quality, documentation and other (technical) parameters. In addition to a general DoD, which
applies to each Backlog Item, specific Acceptance Criteria can be agreed per Backlog Item.
Definition of Ready (DoR): Set of clearly defined criteria that indicate when a Backlog item is
ready for implementation in a sprint.
Deliverables: All output from the Scrum Team that is generated in the realization of Backlog
Items (see also the definition of DoD).

Feature: Chunk of functionality that delivers business value
Impediment: Blockade that prevents the Scrum Team or its members from completing an
agreed task, regardless of its nature.
Increment: The product that the Scrum team delivers at the end of a sprint. The product meets
the agreed Definition of Done. It must be in a usable condition, regardless of whether the
Product Owner actually decides to put the product in production.
KPI: Key Performance Indicator
MVP: Minimum Viable Product
Requirement: Service, function or feature that a user needs

Frequently used definitions
Product Backlog: the latest version of the list of all Backlog Items that are necessary to realize the product
visions of the different products, which is prepared and maintained by the Chief Product Owner in
consultation with the Product Managers, consisting of at
least:
The Backlog Items still to be complementing, prioritized by the Chief Product Owner on business value
and development effort;
• the already developed Increments;
• the Done Backlog Items;
• other items, such as risk mitigating actions, reducing technical debt or delivering architectural items.
Scrum: one of the Agile frameworks that can be used to develop software in an effective, flexible way as a
team.
Scrum Master: the person who facilitates the other members within the Scrum Team in carrying out the
work, in supervising the uninterrupted progress of the work of the Scrum Team and the removal of
Impediments. The role of Scrum Master is fulfilled by one of the members of the Scrum Team.

Product Backlog: the latest version of the list of all Backlog Items that are necessary to realize the
product visions of the different products, which is prepared and maintained by the Chief Product Owner in
consultation with the Product Managers, consisting of at least:
• the Backlog Items still to be complementing, prioritized by the Chief Product Owner on business value
and development effort;
• the already developed Increments;
• the Done Backlog Items;
• other items, such as risk mitigating actions, reducing technical debt or delivering architectural items.
Scrum: one of the Agile frameworks that can be used to develop software in an effective, flexible way as a
team.

Scrum Team: a group of people consisting of members with multidisciplinary skills, working from within the
Scrum framework, who are responsible for software development and are fully responsible for delivering the
intended end result or the Deliverables.

Sprint: a time block of one month or less in which Backlog Items are realized that are 'finished' (comply with
the DoD).
Sprint Backlog: the list of Backlog Items that the Scrum Team must realize during a Sprint.
Sprint Review: is held at the end of the Sprint to inspect the Increment and adjust the Product Backlog if
necessary. During the Sprint Review, the Scrum Team and stakeholders together review what has been
achieved during the Sprint.

User stories/Epics: High level definition of requirement
Velocity: Metric that predicts how much work a team can complete within a sprint

This presentation was created by the reference(s) listed below.
For additional information regarding this topic, please reach out to them or a member of
Engagement Assessment Services
References
Click icon to add picture Click icon to add picture

About CGI
Founded in 1976, CGI is among the largest IT and business consulting

services firms in the world. Operating in hundreds of locations across the
globe, CGI delivers end-to-end services and solutions, including strategic IT
and business consulting, systems integration, intellectual property, and
managed IT and business process services.
CGI works with clients through a local relationship model complemented by

a global delivery network to help clients achieve their goals, including
becoming customer-centric digital enterprises.
cgi.com
© 2020 CGI Inc. Internal

Revision History
Version Date Comments

V1.0 02/2020 Published version
V1.1 10/2020 Updated template
© 2020 CGI Inc. Internal

EAS Recommended Practices - Agile Contracting

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EAS Recommended Practices - Agile Contracting

Uploaded by

Copyright:

Available Formats

Agile contracting

Engagement Assessment Services

© 2020 CGI Inc. Internal 2

“When building an Agile business

Agile software development is an approach

The term agile was popularized by the Manifesto for

The term Agile can be applied on business, portfolio,

© 2020 CGI Inc. Internal 3

“If we can continuously ensure we

The contract is a legally binding agreement

The contract describes the terms and conditions

The contract describes the scope of supply based on

© 2020 CGI Inc. Internal 4

“A good understanding of Agile is

The legal aspect elements of agile contracts are

An understanding of agile and lean principles is

Successful projects are not ultimately born from

© 2020 CGI Inc. Internal 5

Agile deliveries are value driven

Fixed Scope Costs Deadline

Estimate Costs Deadline Scope

© 2020 CGI Inc. Internal 6

© 2020 CGI Inc. Internal 7

Plan Execute Plan Execute Plan Execute Plan Plan Execute

© 2020 CGI Inc. Internal 8

Except on functionality the focus must be on the (right) architectural decisions

© 2020 CGI Inc. Internal 9

• Strong dependency between phases • Change inherent to the process

© 2020 CGI Inc. Internal 10

© 2020 CGI Inc. 11

© 2020 CGI Inc. Internal 12

© 2020 CGI Inc. 14

© 2020 CGI Inc.

Agile Program Maturity

Agile Team Maturity

Low Medium High

Agile Portfolio Maturity

© 2020 CGI Inc.

Agile Team Maturity

Low Medium High

© 2020 CGI Inc. 17

Client business team Supplier delivery team

Business owner Engagement manager

© 2020 CGI Inc. Internal 18

Client business team Supplier delivery team

Business owner Engagement manager

© 2020 CGI Inc. Internal 19

© 2020 CGI Inc. 20

© 2020 CGI Inc. Internal 21

© 2020 CGI Inc. 22

• Controlling specifications Delivery objectives

Client demand Supplier abilities and skills

© 2020 CGI Inc. Internal 24

© 2020 CGI Inc. 26

© 2020 CGI Inc. Internal 27

Contract type characteristics

© 2020 CGI Inc. Internal 28

© 2020 CGI Inc. Internal 29

© 2020 CGI Inc. Internal 30

© 2020 CGI Inc. Internal 31

© 2020 CGI Inc. Internal 32

© 2020 CGI Inc. Internal 33

Two different types of changes:

© 2020 CGI Inc. Internal 35