Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Agile contracts
open-in-new
<h2 id="approaches-to-agile-contracts">Approaches to Agile Contracts</h2> <h3>Capped Time and materials Contracts</h3> <p>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.<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a> </p> <h3>Target Cost Contracts</h3> <p>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. </p> <h3>Incremental Delivery Contracts</h3> <p>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. </p> <ul><li>The first step encompasses the content of the contract on a broad level. This includes the most important project goals, topics and <a href="/facts/User_story/UAoH2fI5">epics</a> as well as the legal framework.<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a></li> <li>One of the epics that best represents the entire project is chosen, specified in more detail and turned into several <a href="/facts/User_story/UAoH2fI5">user stories</a>. 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.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a></li> <li>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).</li> <li>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.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a></li> <li>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<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a>) 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.<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a></li> <li>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.</li></ul> <h2 id="criticism">Criticism</h2> <p>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.<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a> </p> <h2 id="literature">Literature</h2> <ul><li>Andreas Opelt, Boris Gloger, Wolfgang Pfarl und Ralf Mittermayr: <i>Agile Contracts: Creating and Managing Successful Projects with Scrum.</i> 1st edition, Wiley Series in Systems Engineering and Management, 2013.</li> <li>Michael Overly, James R. Kalyvas: <i>Software Agreements Line by Line. How to Understand & Change Software Licenses & Contracts to Fit Your Needs</i>. Aspatore Books, 2004, <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-1-58762-369-1.</li> <li>Eckhart Hanser:<i> Agile Prozesse. Von XP über Scrum bis MAP</i>. Springer-Verlag, 2010, <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-3-642-12313-9.</li> <li>Debbie Madden: "I'm Agile But My Contract Isn't" <a href="http://blog.stridenyc.com/blog/im-agile-but-my-contract-isnt-how-to-align-contracts-with-agile-software-development-teams/">http://blog.stridenyc.com/blog/im-agile-but-my-contract-isnt-how-to-align-contracts-with-agile-software-development-teams/</a></li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>Andreas Opelt et al.: Agile Contracts: Creating and Managing Successful Projects with Scrum. Wiley Series in Systems Engineering and Management. 45–46 <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>Villanova University: Agile Contract Management. Agile Contract Management <a href="http://www.villanovau.com/resources/contract-management/agile/" target="_blank">http://www.villanovau.com/resources/contract-management/agile/</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>Andreas Opelt et al.: Agile Contracts: Creating and Managing Successful Projects with Scrum. Wiley Series in Systems Engineering and Management. 47-72 <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>Andreas Opelt et al.: Agile Contracts: Creating and Managing Successful Projects with Scrum. Wiley Series in Systems Engineering and Management. 47-72 <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>Andreas Opelt et al.: Agile Contracts: Creating and Managing Successful Projects with Scrum. Wiley Series in Systems Engineering and Management. 47-72 <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>Andreas Opelt et al.: Agile Contracts: Creating and Managing Successful Projects with Scrum. Wiley Series in Systems Engineering and Management. 47-72 <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>Andreas Opelt et al.: Agile Contracts: Creating and Managing Successful Projects with Scrum. Wiley Series in Systems Engineering and Management. 47-72 <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> <li id="fn:8"><p>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. <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li> </ol>