Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Agile Contracts - Trond Åsheim - Agile SG 2013

Agile Singapore
November 07, 2013

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.

Agile Singapore

November 07, 2013
Tweet

More Decks by Agile Singapore

Other Decks in Business

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

    View Slide

  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)

    View Slide

  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.

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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 I can such that objective is fulfilled>”

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  30. 12.11.2013 • © PROMIS AS 30
    Running agile projects under contract

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  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%

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  52. 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