User:S0r47737/Agile contracts

= Agile contracts = From Wikipedia, the free encyclopedia Jump to navigationJump to search The Agile fixed price is a contractual model agreed upon by suppliers and customers of IT projects that develop software using Agile methods. The model introduces an initial test phase after which budget, due date, and the way of steering the scope within the framework is agreed upon.

This differs from traditional fixed-price contracts in that fixed-price contracts usually require a detailed and exact description of the subject matter of the contract in advance. Fixed price contracts aim at minimizing the potential risk caused by unpredictable, later changes. In contrast, Agile fixed price contracts simply require a broad description of the entire project instead of a detailed one.

In Agile contracts, the supplier and the customer together define their common assumptions in terms of the business value, implementation risks, expenses (effort) and costs. On the basis of these assumptions, an indicative fixed price scope is agreed upon which is not yet contractually binding. This is followed by the test phase (checkpoint phase), during which the actual implementation begins. At the end of this phase, both parties compare the empirical findings with their initial assumptions. Together, they then decide on the implementation of the entire project and fixate the conditions under which changes are allowed to happen.

Further aspects of an Agile contract are risk share (both parties divide the additional expenses for unexpected changes equally amongst themselves) or the option of either party leaving the contract at any stage (exit points).

Contents

 * 1Approaches to Agile Contracts
 * 1.1Capped Time and materials Contracts
 * 1.2Target Cost Contracts
 * 1.3Incremental Delivery Contracts
 * 2Criticism
 * 3Literature
 * 4References

Capped Time and materials Contracts[edit]
Capped T&M contracts work in the sense of traditional T&M contracts. However, there is an upper limit to how much customers will have to pay. In this way, suppliers benefit with early time-frame changes while customers only have to pay up until the capped cost limit is reached.

Target Cost Contracts[edit]
In target cost contracts, parties involved with the contracts agree on a final price during negotiation. These contracts allow cost savings for both parties if contracts run below budget, but also allows both parties to be faced with additional costs if contracts run above budget.

Incremental Delivery Contracts[edit]
Incremental Delivery Contracts allow customers to review contracts at designated points in the contract life cycle. These points are negotiated into contracts and allow customers to make changes, continue, or terminate the project.


 * The first step encompasses the content of the contract on a broad level. This includes the most important project goals, topics and epics as well as the legal framework.
 * One of the epics that best represents the entire project is chosen, specified in more detail and turned into several user stories. A well-chosen epic should turn into a good number of user stories, all of which are different and include a range of different features. Thus, they can be used as reference user stories.
 * Supplier and customer then come together in a workshop to define the expenses for the entire project based on these reference user stories and all other epics with the help of story points. Assumptions are also made in terms of implementation risk and business value. This information then leads to an indicative fixed price framework, which is not yet legally binding and only fixed at a later step (at the end of the so-called checkpoint phase).
 * Then the checkpoint phase is defined. It is the test phase for collaboration during which implementation is begun and initial empirical insight is achieved. It is recommended to make this phase last about two to five sprints (at a sprint length of two weeks). At the end of the checkpoint phase, the customer and supplier check their initial assumptions and decide whether they still want to realize the entire or part of the project. Only then, the indicative fixed price framework is formally agreed upon and becomes contractually binding. During the checkpoint phase, the risk share is also determined, which defines the extent to which additional expenses larger than the fixed price will be charged to the customer.
 * Furthermore, the roles in charge of steering the project have to be defined and filled. The customer provides the project manager, the supplier the Product Owner. It is recommended to involve an independent IT consultant selected by mutual agreement of both parties. Together, these roles form a steering committee (scope governance) with the mandate of a formal decision-making panel, which meets on a regular basis and ensures that the continuous specification process is adhered to including that the highest prioritized requirements are specified as user stories.
 * In contrast to traditional fixed-price projects, projects with an Agile contract can run out early if the customer believes to have gained the expected value through the already delivered features. This might happen before all agreed-upon functionalities have been implemented. In order for this contractual flexibility to be advantageous to customer and supplier alike, specific agreements must be reached i.e. the supplier could be paid a certain percentage of the budget left over for the undelivered functionality or the supplier could receive a new assignment of the scope of the left-over budget.

Criticism[edit]
The Agile fixed price is a contract framework most suitable for complex IT projects, where scope, progress and costs are difficult to determine in advance. For standard projects, which have already taken place in the same or a similar way in the past, the test phase and the assessment of the project progress may be skipped. In order for this contractual model to be successful, the supplier and customer should collaborate closely throughout the entire length of the project. Furthermore, a certain amount of mutual trust is imperative in order to be able to agree on the budget, expenses and range of features. It is also advisable to ensure that the broad requirements (epics) listed at the beginning of the project are turned into smaller, more detailed requirements (user stories) as soon as possible. Otherwise, the potential for uncertainty and its connected risks rises.

Literature[edit]

 * Andreas Opelt, Boris Gloger, Wolfgang Pfarl und Ralf Mittermayr: Agile Contracts: Creating and Managing Successful Projects with Scrum." 1st edition, Wiley Series in Systems Engineering and Management, 2013.
 * Michael Overly, James R. Kalyvas: Software Agreements Line by Line. How to Understand & Change Software Licenses & Contracts to Fit Your Needs. Aspatore Books, 2004, ISBN 978-1-58762-369-1.
 * Eckhart Hanser: Agile Prozesse. Von XP über Scrum bis MAP. Springer-Verlag, 2010, ISBN 978-3-642-12313-9.
 * Debbie Madden: "I'm Agile But My Contract Isn't" http://blog.stridenyc.com/blog/im-agile-but-my-contract-isnt-how-to-align-contracts-with-agile-software-development-teams/

References[edit]

 * 1) ^ Andreas Opelt et al.: Agile Contracts: Creating and Managing Successful Projects with Scrum. Wiley Series in Systems Engineering and Management. 45–46
 * 2) ^ Villanova University: Agile Contract Management. Agile Contract Management
 * 3) ^ Jump up to:a b c d e Andreas Opelt et al.: Agile Contracts: Creating and Managing Successful Projects with Scrum. Wiley Series in Systems Engineering and Management. 47-72
 * 4) ^ Michael Overly, James R. Kalyvas: Software Agreements Line by Line. How to Understand and Change Software Licenses and Contracts to Fit Your Needs. Aspatore Books. 278–279.

Lead [This section, needs to provide an overview of the article. Therefore, I suggest moving all this information to the body of the article and provide more of a synopsis on this section.]
The term Agile contracts refers to innovative contractual agreements which allow for price tailoring specific to a project's scope and needs by combining different types of contracts. Some contract types that are combined to create agile contractual agreements are: Firm-fixed-price contracts with time-and-materials (T&M), which can establish a cap (not-to-exceed a certain amount).

Article body
Approaches to Agile Contracts [I would add an introductory paragraph, such as:]

An Agile fixed price contract is a contractual model developed, using Agile methods, and mainly tailor to Information Technology (IT) projects, such as software development. Using Agile methodology concepts, an agile fixed price contract model, is established in a way that allows for the introduction of an initial test phase after which budget, due date, and the way of steering the scope within the framework. An agile contract is agreed upon by suppliers and customers.

[I would move the lead section here:]

This differs from traditional fixed-price contracts in that fixed-price contracts usually require a detailed and exact description of the subject matter of the contract in advance. Fixed price contracts aim at minimizing the potential risk caused by unpredictable, later changes. In contrast, Agile fixed price contracts simply require a broad description of the entire project instead of a detailed one.

In Agile contracts, the supplier and the customer define their common assumptions in terms of the business value, implementation risks, expenses (effort) and costs. On the basis of these assumptions, an indicative fixed price scope is agreed upon which is not yet contractually binding. This is followed by the test phase (checkpoint phase), during which the actual implementation begins. At the end of this phase, both parties compare the empirical findings with their initial assumptions. Together, they then decide on the implementation of the entire project and fixate the conditions under which changes are allowed to happen.

Types of contracts used to create agile contracts [edit]
The Agile fixed price contract is used in complex IT projects, where scope, progress and costs are difficult to determine in advance. Following agile methodology concepts, the supplier and customer collaborate closely throughout the entire length of the project, and mutual trust is imperative in order to be able to agree on the budget, expenses and range of features. In addition, broad requirements (epics) listed at the beginning of the project should be turned into smaller, more detailed requirements (user stories) as soon as possible, this will help minimize risk.

Capped Time and materials Contracts[edit]
Capped T&M contracts work in the sense of traditional T&M contracts. However, there is an upper limit to how much customers will have to pay. In this way, suppliers benefit with early time-frame changes while customers only have to pay up until the capped cost limit is reached.

Target Cost Contracts[edit]
In target cost contracts, parties involved with the contracts agree on a final price during negotiation. These contracts allow cost savings for both parties if contracts run below budget, but also allows both parties to be faced with additional costs if contracts run above budget.

Incremental Delivery Contracts[edit]
Incremental Delivery Contracts allow customers to review contracts at designated points in the contract's lifecycle. These points are negotiated into contracts and allow customers to make changes, continue, or terminate the project.


 * The first step encompasses the content of the contract on a broad level. This includes the most important project goals, topics and epics as well as the legal framework.
 * One of the epics that best represents the entire project is chosen, specified in more detail and turned into several user stories. A well-chosen epic should turn into a good number of user stories, all of which are different and include a range of different features. Thus, they can be used as reference user stories.
 * Supplier and customer then come together in a workshop to define the expenses for the entire project based on these reference user stories and all other epics with the help of story points. Assumptions are also made in terms of implementation risk and business value. This information then leads to an indicative fixed price framework, which is not yet legally binding and only fixed at a later step (at the end of the so-called checkpoint phase).
 * Then the checkpoint phase is defined. It is the test phase for collaboration during which implementation is begun and initial empirical insight is achieved. It is recommended to make this phase last about two to five sprints (at a sprint length of two weeks). At the end of the checkpoint phase, the customer and supplier check their initial assumptions and decide whether they still want to realize the entire or part of the project. Only then, the indicative fixed price framework is formally agreed upon and becomes contractually binding. During the checkpoint phase, the risk share is also determined, which defines the extent to which additional expenses larger than the fixed price will be charged to the customer.
 * Furthermore, the roles in charge of steering the project have to be defined and filled. The customer provides the project manager, the supplier the Product Owner. It is recommended to involve an independent IT consultant selected by mutual agreement of both parties. Together, these roles form a steering committee (scope governance) with the mandate of a formal decision-making panel, which meets on a regular basis and ensures that the continuous specification process is adhered to including that the highest prioritized requirements are specified as user stories.
 * In contrast to traditional fixed-price projects, projects with an Agile contract can run out early if the customer believes to have gained the expected value through the already delivered features. This might happen before all agreed-upon functionalities have been implemented. In order for this contractual flexibility to be advantageous to customer and supplier alike, specific agreements must be reached i.e. the supplier could be paid a certain percentage of the budget left over for the undelivered functionality or the supplier could receive a new assignment of the scope of the left-over budget.

Criticism [I would delete this title/section, delete some sentences, and move other sentences throughout the rest of the article.]
[I recommend adding this section] Challenges in Agile contracts

Legal disputes - the subjective language used in Agile contracts, such as "cooperate and trust one another and build upon each other's expertise," is problematic. As much as possible, legal advisors recommend that when it comes to contractual agreements, the contracts spell out, or define any terminology that could be left to interpretation. Therefore, the terms "cooperate and trust" need to be, as much as possible be defined as to what that means for the parties involved (i.e., customer and developer). Defining these terms will help define what is satisfactory among the parties and eliminate some of the ambiguity from contract language.

Risk share - in agile contracts both parties share the risk of: dividing the additional expenses for unexpected changes equally amongst themselves, and/or either party leaving the contract at any stage (exit points).

Literature[edit]
 * Andreas Opelt, Boris Gloger, Wolfgang Pfarl und Ralf Mittermayr: Agile Contracts: Creating and Managing Successful Projects with Scrum." 1st edition, Wiley Series in Systems Engineering and Management, 2013.
 * Michael Overly, James R. Kalyvas: Software Agreements Line by Line. How to Understand & Change Software Licenses & Contracts to Fit Your Needs. Aspatore Books, 2004, ISBN 978-1-58762-369-1.
 * Eckhart Hanser: Agile Prozesse. Von XP über Scrum bis MAP. Springer-Verlag, 2010, ISBN 978-3-642-12313-9.
 * Debbie Madden: "I'm Agile But My Contract Isn't" http://blog.stridenyc.com/blog/im-agile-but-my-contract-isnt-how-to-align-contracts-with-agile-software-development-teams/

References[edit]

 * 1) ^ Andreas Opelt et al.: Agile Contracts: Creating and Managing Successful Projects with Scrum. Wiley Series in Systems Engineering and Management. 45–46
 * 2) ^ Villanova University: Agile Contract Management. Agile Contract Management
 * 3) ^ Jump up to:a b c d e Andreas Opelt et al.: Agile Contracts: Creating and Managing Successful Projects with Scrum. Wiley Series in Systems Engineering and Management. 47-72
 * 4) ^ Michael Overly, James R. Kalyvas: Software Agreements Line by Line. How to Understand and Change Software Licenses and Contracts to Fit Your Needs. Aspatore Books. 278–279.

References (add the following references)
Pennington, R. (2018, August 1). Agile: A New Frontier for Contract Management. Magazine Details. National Contract Management Association. https://www.ncmahq.org/news/magazine-details/agile-a-new-frontier-for-contract-management

United States Government Federal Acquisition Regulation (2021, July) https://www.acquisition.gov/