EAS Recommended Practices - Agile Contracting
EAS Recommended Practices - Agile Contracting
EAS Recommended Practices - Agile Contracting
Waterfall Agile
Value /
Vision
Driven
Plan
Driven
Planned
Actual
Business value
STOP
Business value
Plan Execute
STOP
Business value
Planned
Actual
Business value
Architecture
Business value
Plan Execute Plan Execute Plan Execute Plan Execute Plan Execute
Traditional Agile
• 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)
Low
Agility
Medium
Delivery Risk Vs Agility / Agile Maturity
High
Internal
O
rg
an
iza
tio
n
le
ve
l
15
Agile Business Maturity
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.)
Validation /
Delivery Scope / Specs Develop
Acceptance
Governance
Validation /
Scope /
Delivery Specs
Develop Acceptanc
e
Dashboard
Governance
• 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.
Contractual agreements
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
Contractual agreements
• Controlling specifications
• Governance and dispute resolution
• Budget and Payment Terms
• Reporting / KPIs
• Acceptance
• Changes to supply (change process)
• Intellectual property
• Warranties and Indemnities
• Liability
• Termination
© 2020 CGI Inc. Internal 25
Agile Contract
Legal Aspects
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
Contractual agreements
• 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
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
Contractual agreements
• 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
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
Contractual agreements
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
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
Contractual agreements
• 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
Contractual agreements
• 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
Characteristics
Acceptance based on intermediate products (Sprint or Program Increment)
Accounting for acceptance with continuous iterations is a challenge
Contractual agreements
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
• 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
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
Contractual agreements
The contract will address limitation of liability using similar concepts as a traditional
development contract (waterfall)
BEMF CMF
Complexity
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
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
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
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
Capacity
Estimates are required to determine the optimum team size
• Can the team deliver the requested functionality in a certain time
Performance indicators
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
Controlling specifications
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
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
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
Controlling specification
A rough scope has been provided (Epics, Features)
Termination
• Clearly define points in time where CGI and the client may terminate the contract
Performance indicators
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
Responsibilities
• 2-5 sprints initiation phase is required to achieve a stable situation
Contractual agreements
• 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
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
© 2020 CGI Inc. Internal 61
Contract and Proposal Aspects
(2)
Contract Element P or TC Notes
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
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
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.
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)!
Change Management Describe what is allowed within the adopted process framework and what is part of the governance process/contract change process
Dependencies Describe which supplier services are dependent on associated client activities/obligations.
Terms and Conditions Link to existing framework agreement with Client / contract or to CGI standard Terms and Conditions
A set of minimum criteria before it’s ready for inclusion in the work of the next sprint, agreed by the Scrum team
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
© 2020 CGI Inc. Internal 68
Additional Frequently
Used Terms and
Definitions
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).
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.
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 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.
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.
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.
Velocity: Metric that predicts how much work a team can complete within a sprint
References
Click icon to add picture Click icon to add picture
cgi.com