Agile Contracts - Trond Åsheim - Agile SG 2013

12.11.2013 • © PROMIS AS 1
Agile Contracting
«Agile contracts for agile projects»
Agile Conference Singapore, November 7-8 2013
Trond Åsheim, PROMIS AS

View Slide

12.11.2013 • © PROMIS AS 2
The Presenter – Trond Åsheim
• MSc in Economics and Industrial Management
• 18 years experience from the IT Consulting business
• Early years as a system developer
• Primarily project manager and advisor / Business Consultant
on strategic projects in both private and public sector
• Certified Project Management Professional (PMP) and
IT Project Professional (ITPP)
• Senior Project Manager at PROMIS, a leading provider of agile project
management services in Norway (www.promis.no)

View Slide

12.11.2013 • © PROMIS AS 3
PROMIS is an independent Norwegian management
consulting company offering:
Management consulting
Management of large IT-projects and IT-programs
Procurement consulting
Procurement strategies, contract management, management of RFPs
Quality management consulting
Quality assurance processes, uncertainty analysis, risk management, change
management and business management
In 2012 PROMIS AS was awarded the prize as the best consulting company in
Norway based on the contributions to the agile IT-contract PS2000 and the
launching of the certification program related to agile project management
(ITPP) was especially mentioned.

View Slide

12.11.2013 • © PROMIS AS 4
The essence of this lesson
 Challenges regarding agile projects and contracts
 An example of a Norwegian contract standard that works:
PS2000 agile contract standard
 Important elements, principles and processes in the PS2000
contract standard

View Slide

12.11.2013 • © PROMIS AS 5
Agile contracts – contradictions and challenges

View Slide

12.11.2013 • © PROMIS AS 6
Agile is OK – but what about contracts?
• The use of traditional contract standards
and pricing mechanisms in agile projects
is frequently a road to failure
• Experience (from Norway) has shown that
IT development projects are more
successful using balanced contracts
• Customers want to share project risks
and opportunities with suppliers
• Sharing risks and opportunities (“Being in
the same boat”) increases the chances for
project success
• Public sector is engineered for cost
control – «must» have a contract with
supplier obligations to have cost limits

View Slide

12.11.2013 • © PROMIS AS 7
Agile delivery contracts – a contradiction?
• Some people claim that you could only run agile in integrated
projects based on time & material, and that it is impossible to
run agile based on a delivery contract
• The most serious objections to a delivery contract go like this:
1. It is not possible nor convenient to
specify deliveries sufficiently precise for a
whole contracting period
2. It is not possible nor convenient to
estimate deliveries in advance with
sufficient degree of certainty

View Slide

12.11.2013 • © PROMIS AS 8
Why not use a fixed price contract standard?
• Agile projects need an innovative approach to contracting, adapting
contractual models to a world different from fixed scope and fixed price
• Handling changes are often tedious and time consuming – changes
need to be handled smoothly throughout the project period
• Improvements (learning by doing) often neglected – too much focus on
scope, time and cost
• Need incentives both for the supplier and customer to cooperate, take
on risk and work towards the same goal

View Slide

12.11.2013 • © PROMIS AS 9
To attack these challenges and contradictions, the idea
is to …
• Get the suppliers commit to
• Resources / competence
• Methodology and processes
• A reference estimate on a defined case
• An estimation model
• Hourly rates pr. resource category
• Implement a compensation format that invites the parties to sign contract under
a certain degree of uncertainty
• Target Price contracts with 50% sharing of up- and downsides
• Sign contracting scope in a situation where the parties have obtained a
maximum of experience, combined with a minimum of development horizon
• The concept of Continuous Solution Description and signing of target prices on the
User Story level
… rather than focusing on either scope, time and cost OR purely time & material

View Slide

12.11.2013 • © PROMIS AS 10
Contract models and the PS2000 contract standard

View Slide

12.11.2013 • © PROMIS AS 11
Contracting price models – three main alternatives
• Time & Material:
• The Customer pays for all worked hours, disregarding productivity
and quality – the risk is on the Customer
• Fixed Price:
• The Customer pays the same amount, disregarding the hours
needed to produce the scope with agreed quality – the risk is on the
Supplier
• Target Price:
• Customer and Supplier share benefits or losses in an agreed ratio –
if this ratio is 50%, the risk is evenly distributed between the parties

View Slide

12.11.2013 • © PROMIS AS 12
The hourly rate curves – target price invite the
suppliers to share risk
0
200
400
600
800
1000
1200
1400
1600
700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900
Fixed price hourly rate
Target price hourly rate
Time&material hourly rate
Actual spending
1500 hours
Budget 1000
hours
Hours spent
Hourly rate
NOK 666
NOK 833

View Slide

12.11.2013 • © PROMIS AS 13
Why use target price as contract price model?
Target price contracting price model is well suited because:
• Agile is a close and mutual co-operation between customer and supplier
• 50/50 sharing of incentives and sanctions ensure the customer and
supplier works towards the same goal
• It encourages the supplier to take on risk due to the sharing of downside

View Slide

12.11.2013 • © PROMIS AS 14
Effects of Target price contract model
• The risk is evenly distributed between Customer and Supplier
• The Supplier is invited to commit to estimates with a higher degree of
uncertainty than in traditional fixed price contracts
• The Customer may produce tender documents with high level
requirements
• The Suppliers produce solution descriptions, estimated with a
significant degree of uncertainty
• Both parties reduce work load and resource spending in the initial
bidding phases of the project as well as the initial specification, detailed
design and planning

View Slide

12.11.2013 • © PROMIS AS 15
Introducing PS2000 – A Target Price Contract
standard
• A Norwegian contract standard for the IT industry
• A result of a research programme during the years 1997 –
2000
• Frequently used in large system development projects both
in the Norwegian public and private sector
• Also used abroad
• Referred to in Mary and Tom Poppendieck:
’Implementing Lean Software Development:
From Concept to Cash’ Addison-Wesley 2007

View Slide

12.11.2013 • © PROMIS AS 16
PS2000 Standard project model
http://www.dataforeningen.no/it-contract-standards.146223.no.html
Requirement
Analysis
Acceptance and
-
Completion phase
Detailed planning
Analysis and design
Testing Development
Progression
Iterative
construction phase
CG1
CGn
C
CG2
PMS 0
Contract Signing
Solution
Description
PMS 1
Approved Solution
Description
PMS 2
Delivery ready
for Acceptance
PMS 3
Accepted
Delivery

View Slide

12.11.2013 • © PROMIS AS 17
The need for an agile delivery contract standard
• Iterative and agile project methods have settled as the most common
development processes compared to the traditional waterfall process in
the IT industry
• IT industry wanted to move into agile projects
• No contract standard existed that regulated agile methods
• The agile method itself seemed too loose to be based on time and
material contract
• Public sector had the need for formalities in relation to procurement
processes
• Business management wanted agreements with suppliers that
regulated some kind of scope, time and cost

View Slide

12.11.2013 • © PROMIS AS 18
Expected benefits of an agile contract standard
• Handle the customer’s changing business surroundings and impact on
the project during the contract period
• Handle change in initial scope more flexible during implementation
• Push for early benefit realisation by continuously prioritising based on
experiences and changes through the project
• Get more dedicated customer involvement
• Minimize overhead - make planning, control and follow up more
efficient
• Reduce uncertainty by continuously follow up progress and general
status through short daily status meetings
• The idea of self organising teams tend to be give more motivated
workers which potentially leads to better quality and project results

View Slide

12.11.2013 • © PROMIS AS 19
Scrum as the leading agile
method at the time, was
chosen as the agile method
to support the agile PS2000
contract standard
Demonstrate
Evaluate
Specify
Prioritise
Product owner Plan
Implement
Sprint team
Scrum fits the work process in PS2000

View Slide

12.11.2013 • © PROMIS AS 20
The solution: PS2000 Agile!
• 2008: A guideline on how to run agile projects with
PS2000 (mapping Scrum sprints to PS2000 iterations,
making use of the control gate after each sprint, the
Product Owner role on the Customer side, etc)
• 2009: A new part III to the PS2000 contracting
standard was released – agile annexes (balanced
requirements, specifying the responsibility of the
Product Owner role on the Customer side, a dynamic
product backlog defining the scope, a revised formula
for target price incentives and sanctions)
• 2008 – 2011: PS2000 Agile applied to a 100 mill €
project in SPK: The PERFORM project
• The Contract standards are owned by the Norwegian
Computer Society

View Slide

12.11.2013 • © PROMIS AS 21
Structure of the PS2000 agile contract standard
 Part I: Contract document
Defining the contract parties, main content and the structure of the contract
 Part II: General provisions
The general provisions in part II is not subject to change
 Part III Agile: Annexes to the Contract
Specifying the delivery and elaborates the general provisions
 In addition there is a general guidance on how to use the contract (a
supplement to the contract - not part of the contract structure)

View Slide

12.11.2013 • © PROMIS AS 22
Part III Agile: Annexes to the Contract

View Slide

12.11.2013 • © PROMIS AS 23
Example of Annex A: Requirement analysis

View Slide

12.11.2013 • © PROMIS AS 24
Agile characteristics and central concepts in PS2000

View Slide

12.11.2013 • © PROMIS AS 25
Agile characteristics in the PS2000 agile concept
• Quality measure no 1: Fitness for business purposes!
• Continuous prioritisation according to benefit/cost
• Short development cycles resulting in shippable code
• Frequent releases
• Tight interaction between business people and developers
• Rolling wave planning: Late decisions
• Autonomy: Self-organising teams
• Evaluation and continuous learning
• Elimination of waste, creating flow

View Slide

12.11.2013 • © PROMIS AS 26
Product breakdown structure
• Product breakdown structure (PBS) in this context is taken from PRINCE2
• PBS focuses on products (working software) and has user stories as leaf
nodes rather than tasks - as in more traditional Work Breakdown Structure
• Project plans, budgets, reporting and management concentrate on bringing
forward working software of high quality
• PBS will look like this in an agile software development project
• “As I can such that objective is fulfilled>”

View Slide

12.11.2013 • © PROMIS AS 27
Flow
• The user stories from the product breakdown structure pass through 5 stages
• Might remind of waterfall method, but in this context it is regarded as the Flow
(or similar “calving ice berg”)
• The Flow principle is essential in explaining the contract model, the measuring
of earned value (EV) and the reporting regime of project progress in th Control
gate
Open In analysis In construction In approval In production

View Slide

12.11.2013 • © PROMIS AS 28
Continuous Solution Description
• Defer commitments
• Target price for user stories are signed off
as late as possible
• All parties have gained as much experience
as possible
• The time from signing off to “go live” for the
user story is minimal
• Rolling wave planning and continuous
solution description phases
• Target price is signed off for user stories for
the next 1-3 sprints
• Analysis, estimation, negotiations and
signing is conducted in parallel to the
construction of code

View Slide

12.11.2013 • © PROMIS AS 29
The control gate
• Verifying that delivered user stories meet the “Definition of Done”
• Evaluate sprint, prepare next sprint, report to Project board
• Important event in the relationship between Project board and project
management and between the customer and the supplier
Construction phase
Solution description
phase
Blue line: Sprint team
Red line: Product Owner
Yellow line: Verification, Control gate and Definition of Done

View Slide

12.11.2013 • © PROMIS AS 30
Running agile projects under contract

View Slide

12.11.2013 • © PROMIS AS 31
Initiating the project – The business case
• No project should be released without a business case
• The project is a proposal for a strategic initiative to meet the overall goals and
the strategy of the business unit
• Baseline epics in the product
backlog are connected to the
business goals
• Elements in the business
case should be closely
followed up during the
project, for instance
• Return on investment
• Uncertainty analysis (Risks
and opportunities)
• Benefit realisation and
fitness for purposes

View Slide

12.11.2013 • © PROMIS AS 32
Analysis of needs – Product Breakdown Structure
• Baseline epics are documented in
the Product backlog
• User stories are derived from the
business objective and epics and
documented in the product backlog
• Acceptance criterion is an important
part if the user story
• User stories are the base for
estimation
• Benefits are analysed in the same
way as needs and can also be
estimated

View Slide

12.11.2013 • © PROMIS AS 33
Element
number
Description of
element
Customer’s
evaluation
Supplier’s
evaluation
Mea-
sures
Respo-
nsible
Proba-
billity
Conseq
uence
Proba-
billity
Conseq
uence
1 The supplier does not
know the customer’s
business
3 3 2 4 …. Supplier
2 The customer’s IT
infrastructure can not
handle the expected
amount of transactions
3 4 4 4 …. Custome
r
n
Uncertainty analysis
• Important part of the risk management is the uncertainty analysis
• In PS2000 this is part of the contract and encourages both customer
and supplier to take an active part
• The suppliers will have there saying in the procurement process and
can give a justification and a price for the uncertainty in the project

View Slide

12.11.2013 • © PROMIS AS 34
Procurement process – contract strategy
• Based in the business case, product backlog and project budget –
choose correct sourcing strategy
• Important for agile delivery contract strategy:
• Mature product backlog, i.e. queue of epics rooted in a solid business case
• Mature customer organisation, i.e. ready to take responsibility of the product owner

View Slide

12.11.2013 • © PROMIS AS 35
Procurement process – choosing supplier
• The customer presents a broad outline of the organisation, the goals
for the project, enterprise architecture, important milestones, etc. to the
bidders as part of the Tender documents
• Tender’s meeting with a presentation of the customer, visions for the
project, the main goals, etc.
• Information is to be distributed evenly amongst the tenders during the
process
• The customer should have a predefined evaluation model where the
criteria for the competition are weighted according to their priorities, to
make sure the evaluation of the bidders is performed objectively
• To eliminate waste the bidders will fill out the appendixes in the
contract as part of the tender process – this will make the comparison
easier and reduce the workload when preparing the final contract

View Slide

12.11.2013 • © PROMIS AS 36
Evaluations of the tenders
• Presentation of the conceptual approach to the software architecture
and solution to meet Customer’s needs according to the Product
backlog
• A guarantee of provided capacity during the project period
• A list of committed resources, with CVs, expected roles, allocations and
hourly rates, including a mean hourly rate to be used for target pricing
• A written commitment to comply to the Customer organization’s
methodology and processes
• An estimation model
• A reference estimate for the selected epics
• The supplier is chosen based on a the predefined evaluation criteria
not a cost for a set of requirements

View Slide

12.11.2013 • © PROMIS AS 37
Supplier chosen – Joint Solution description phase next
• The PS2000 agile process starts with a joint solution description phase
where the customer shares the work on the product backlog items with
the highest priority
• Baseline release plan is established with a hypothesis of what epics
will be released in the first release
• Common Product backlog is established. This is the fifth iteration on
the product backlog, where the previous iterations being
1. Initial analysis of needs, resulting in the authorization of the project
2. The establishment of tender documents
3. The Supplier’s bid
4. The negotiations
• The common project organization is ready for Construction phase

View Slide

12.11.2013 • © PROMIS AS 38
Continuous solution description
• Solution description phases on time &
material under the Customer’s
governance
• The parties negotiate the target price on
each new element in the product backlog
• An estimated product backlog is an
enclosure to the agreement
• The product backlog is dynamically
updated throughout the construction
phase, as new backlog items are
defined, solution described, estimated,
negotiated and signed
• This is repeated throughout the project!
• With some experience, these processes
are strongly streamlined
Product
backlog from
analysis of
needs
Initiel
Product
backlog
Dynamic
Product
backlog
Ikke påbegynt Under arbeid Til test Ferdig

View Slide

12.11.2013 • © PROMIS AS 39
Continuous processes throughout the project
• Continuous Analysis of Needs – postponing analysis of epics to the last
possible moment
• Continuous Approval – head-starting integration and system testing of
the release
• Continuous Delivery – putting into production whatever is in agreed
quality and ready to be absorbed by the receiving organization
• These mechanisms gives the flow, satisfying the main lean and agile
principles, still combined with contracting and sharing of risk between
Customer and Supplier
Construction Approval Production
Needs Solutions Construction Approval Production
Approval Production Maintenance
Maintenance
Maintenance

View Slide

12.11.2013 • © PROMIS AS 40
The Anatomy of the Sprint in PS2000 agile
• The Product Owner prepares a set of detailed and prioritised User Stories with
acceptance criteria, together high level design decisions
• During the sprint, the Development team finishes User Stories according to the
‘Definition of done’, performing
• Detailed planning, analysis and design
• Further development of acceptance criteria and test conditions
• Code testing and bug fixing
• Development, build and documentation
• By the end of the Sprint the project performs a Control Gate.

View Slide

12.11.2013 • © PROMIS AS 41
Detailed planning,
analysis and
design
Testing
Development
The Anatomy of the Sprint in PS2000 Agile
-What did you do?
-What will you do?
-Any obstacles?
24 h
Sprint Backlog
Spint Planning Sprint backlog
decomposed
by the team
The delivery in the Control gate –
running software and definition of done
Prioritised Product Backlog
Cg

View Slide

12.11.2013 • © PROMIS AS 42
The Control gate
Sprint demo Sprint X
Sprint planning Sprint X+1 starts with decomposition
Sprint backlog for Sprint X+1 ready
Control gate:
1. Evaluation of Sprint X
2. Approval of sprint plan for Sprint X+1
3. Updating the risk matrix
4. Change control
5. Repatriation of agreed outstanding issues to the
product backlog

View Slide

12.11.2013 • © PROMIS AS 43
The Control gate - Contractual milestone
• By the end of the sprint, the teams
demonstrate running software to the
product owner(s) - demo
• Furthermore, to check if a user story
meets Definition of done, it must pass
a Control gate
The sprint
Cg
• The Control gate meeting is usually executed 2-4 working days after sprint
demo (by this time, the teams have already executed sprint planning for the
next sprint)
• In the Control gate process and the Control gate meeting a lot of
representatives from the Customer side are participating: Product Owners,
Test, Architecture, Operations, and Project Management
• In the Control gate meeting the Customer gives feedback on all parameters
of ‘Done’ to the Supplier

View Slide

12.11.2013 • © PROMIS AS 44
Definition of Done
• The user stories are verified on a
stable test environment
• Do the user stories meet the
acceptance criteria?
• Is the software well documented (user
documentation, system documentation,
installation and operations
documentation)?
• Are the tests documented?
• Is the code of good quality?
• Are other architectural constraints and guidelines met?
• All these requirements should be fulfilled to meet the definition of done
• The control gate meeting itself may handle a number of delivered user
stories in a relatively short time (e.g., 30 user stories in 15 minutes)
• The Control gate meeting does not replace the sprint demo or the sprint
retrospective

View Slide

12.11.2013 • © PROMIS AS 45
Planning and controlling considerations in the Control
Gate
• What was the productivity of the last sprint?
• How is the total project risk evolving?
• What can we improve – i.e. learning and continuous improvements?
• Should we take corrective actions to improve project progress?
• Report to Project Board in matters like project progress, cost, schedule,
risk, validity of the business case, etc.

View Slide

12.11.2013 • © PROMIS AS 46
Earned Value management - reporting
• Earned Value Management is essential in PS2000 agile
• Cost Performance Index (CPI) is the main KPI in any software development
project, comprising the agile concept of velocity
• Uses the principles described in Flow and “cash in” earned value (EV) based
on the status in Flow
• Compute the CPI by using the fraction EV/AC (where AC being the actual cost
in the period)
• Budget forecast is calculated EAC = BAC / CPI
Open In analysis In construction In approval In production
10% 30% 85% 100%

View Slide

12.11.2013 • © PROMIS AS 47
Conclusion: PS2000 agile contract works and is part
of a “family of contract standards”

View Slide

12.11.2013 • © PROMIS AS 48
Advantages with PS2000 Agile
• Corresponds to the main principles in Agile and Lean
• Describes how the project phases should be executed
• Loyal to the principles in Scrum regarding roles, ceremonies and
artefacts
• Change control becomes lean – a signed Product Backlog after each
sprint documents the agreed changes
• The main success factor is that the parties agree on the process
managing the Product Backlog, Continuous solution descriptions
Sprints and Control Gates
• Target price model, with a large variety of configurations reflecting
project risks
• Incentives for the supplier to deliver more functionality within agreed
time limits, but with satisfactory quality

View Slide

12.11.2013 • © PROMIS AS 49
Status for the PS2000 contract standard today
 The PS2000 contract standard is the first and leading contract standard
in Norway that is based on iterative and agile processes
 The PS2000 contract standard is developed in cooperation between
suppliers and customers which balances the interests to the suppliers
and the customers
 The PS2000 contract standard is developed for use in both private and
public sector
 The PS2000 contract standard is especially suited for large software
projects with a high degree of uncertainty and high level requirement
specification
 The contract standards are continuously updated and improved – a new
version of the agile contract has recently been released

View Slide

12.11.2013 • © PROMIS AS 50
PS2000 contract standards in a lifecycle perspective
Delivery of initial project
The PS2000 Standard Contract for
Software Development
Scope for initial
procurement
PS2000 contract standard for maintenance
(Bug fixing, support, contingency and general maintenance)
PS2000 frame agreement regarding software development
(Supplements and changes)
Lifecycle
Development
contract 1
Development
contract 2
Development
contract n
….
Development/implementation of
IT project
Software lifecycle management
PS2000 contract standard for IT service operation
The PS2000 Agile Contract for
Software Development

View Slide

12.11.2013 • © PROMIS AS 51
ITPP – IT Project Professional
• PROMIS has developed a certification program related to agile IT projects
called ITPP – IT Project Professional
• The certification program is based on
• PRINCE2 Foundation
• Scrum
• PS2000 agile contract standard
• The certification program consists of
• online training courses
• classroom workshops
• lecture notes (compendiums)
• Other contributors to the program are Simula Research Laboratory and
Metier AS
• PROMIS is also planning to releasing a text book regarding the ITPP

View Slide

12.11.2013 • © PROMIS AS 52
Thank you for your attention
E-mail: [email protected]
Web: http://www.promis.no
LinkedIn: http://www.linkedin.com/pub/trond-asheim/3/1b4/3a2

View Slide

Agile Contracts - Trond Åsheim - Agile SG 2013

Agile Contracts - Trond Åsheim - Agile SG 2013

Agile Singapore

More Decks by Agile Singapore

Other Decks in Business

Featured

Transcript