Agile contracts

Last updated January 13, 2024

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.^[1]

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

Approaches to Agile Contracts

Capped Time and materials Contracts

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.^[2]

Target Cost Contracts

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

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.^[3]
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.^[3]
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.^[3]
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^[3]) 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.^[3]
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

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.^[4]

Literature

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/

Related Research Articles

In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests.

A software company is an organisation — owned either by the state or private — established for profit whose primary products are various forms of software, software technology, distribution, and software product development. They make up the software industry.

The rational unified process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

Rapid application development (RAD), also called rapid application building (RAB), is both a general term for adaptive software development approaches, and the name for James Martin's method of rapid development. In general, RAD approaches to software development put less emphasis on planning and more emphasis on an adaptive process. Prototypes are often used in addition to or sometimes even instead of design specifications.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

In software development, agile practices include requirements, discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s). Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from, and underpin, a broad range of software development frameworks, including Scrum and Kanban.

Dynamic systems development method (DSDM) is an agile project delivery framework, initially used as a software development method. First released in 1994, DSDM originally sought to provide some discipline to the rapid application development (RAD) method. In later versions the DSDM Agile Project Framework was revised and became a generic approach to project management and solution delivery rather than being focused specifically on software development and code creation and could be used for non-IT projects. The DSDM Agile Project Framework covers a wide range of activities across the whole project lifecycle and includes strong foundations and governance, which set it apart from some other Agile methods. The DSDM Agile Project Framework is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement.

Capability Maturity Model Integration (CMMI) is a process level improvement training and appraisal program. Administered by the CMMI Institute, a subsidiary of ISACA, it was developed at Carnegie Mellon University (CMU). It is required by many U.S. Government contracts, especially in software development. CMU claims CMMI can be used to guide process improvement across a project, division, or an entire organization. CMMI defines the following maturity levels for processes: Initial, Managed, Defined, Quantitatively Managed, and Optimizing. Version 2.0 was published in 2018. CMMI is registered in the U.S. Patent and Trademark Office by CMU.

In agile principles, timeboxing allocates a maximum unit of time to an activity, called a timebox, within which a planned activity takes place. It is used by agile principles-based project management approaches and for personal time management.

Construction management (CM) aims to control the quality of a project's scope, time, and cost to maximize the project owner's satisfaction. It uses project management techniques and software to oversee the planning, design, construction and closeout of a construction safely, on time, on budget and within specifications.

In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an end user or user of a system, and may be recorded on index cards, Post-it notes, or digitally in specific management software. Depending on the product, user stories may be written by different stakeholders like client, user, manager, or development team.

The project initiation documentation (PID) is one of the most significant artifacts in project management, which provides the foundation for the business project.

Scrum is an agile team collaboration framework commonly used in software development and other industries.

<span class="mw-page-title-main">Unified Process</span> Object oriented software development process framework

The unified software development process or unified process is an iterative and incremental software development process framework. The best-known and extensively documented refinement of the unified process is the rational unified process (RUP). Other examples are OpenUP and agile unified process.

Strategic planning software is a category of software that covers a wide range of strategic topics, methodologies, modeling and reporting.

A glossary of terms relating to project management and consulting.

In software engineering, a software development process is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

ScrumEdge is a collaborative web-based scrum tool that allows agile development teams, ScrumMasters, and stakeholders to manage the Scrum lifecycle at the product and sprint levels.

Small-scale project management is the specific type of project management of small-scale projects. These projects are characterised by factors such as short duration; low person hours; small team; size of the budget and the balance between the time committed to delivering the project itself and the time committed to managing the project. They are otherwise unique, time delineated and require the delivery of a final output in the same way as large-scale projects.

Disciplined agile delivery (DAD) is the software development portion of the Disciplined Agile Toolkit. DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of agile software development, including scrum, agile modeling, lean software development, and others.

References

↑ Andreas Opelt et al.: Agile Contracts: Creating and Managing Successful Projects with Scrum. Wiley Series in Systems Engineering and Management. 45–46
↑ Villanova University: Agile Contract Management. Agile Contract Management
1 2 3 4 5 Andreas Opelt et al.: Agile Contracts: Creating and Managing Successful Projects with Scrum. Wiley Series in Systems Engineering and Management. 47-72
↑ 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.

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[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

[:0-3] 1 2 3 4 5 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.

[1]

[2]

[3]

[4]