Agile Contracts - Trond Åsheim - Agile SG 2013

Presented in Agile Singapore 2013 Conference

Most large projects are executed under a contract with commitments on both parties. Traditional contract standards and pricing mechanisms in agile projects is frequently a road to failure. Agile projects need an innovative approach to contracting, adapting contractual models to a world different from fixed scope and fixed price. In this lecture the presenter will walk through the essentials of "Agile Contracting" and give a broader understanding of the commercial sides of scrum projects.

Transcript

1. 12.11.2013 • © PROMIS AS 1 Agile Contracting «Agile contracts for agile projects» Agile Conference Singapore, November 7-8 2013 Trond Åsheim, PROMIS AS
2. 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)
3. 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.
4. 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
5. 12.11.2013 • © PROMIS AS 5 Agile contracts – contradictions and challenges
6. 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
7. 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
8. 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
9. 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
10. 12.11.2013 • © PROMIS AS 10 Contract models and the PS2000 contract standard
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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
18. 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
19. 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
20. 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
21. 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)
22. 12.11.2013 • © PROMIS AS 22 Part III Agile: Annexes to the Contract
23. 12.11.2013 • © PROMIS AS 23 Example of Annex A: Requirement analysis
24. 12.11.2013 • © PROMIS AS 24 Agile characteristics and central concepts in PS2000
25. 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
26. 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 <a role> I can <execute a certain activity or a step> such that <a certain objective is fulfilled>”
27. 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
28. 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
29. 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
30. 12.11.2013 • © PROMIS AS 30 Running agile projects under contract
31. 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
32. 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
33. 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
34. 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
35. 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
36. 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
37. 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
38. 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
39. 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
40. 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.
41. 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
42. 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
43. 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
44. 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
45. 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.
46. 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%
47. 12.11.2013 • © PROMIS AS 47 Conclusion: PS2000 agile contract works and is part of a “family of contract standards”
48. 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
49. 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
50. 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
51. 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
52. 12.11.2013 • © PROMIS AS 52 Thank you for your attention E-mail: trond.asheim@promis.no Web: http://www.promis.no LinkedIn: http://www.linkedin.com/pub/trond-asheim/3/1b4/3a2