Agile fixed price

from Wikipedia, the free encyclopedia

The agile fixed price is a contract model for suppliers and customers in IT projects that are carried out with agile methods . The contract model provides that costs and deadlines are set after an initial test phase and a procedure to control the scope ("scope") is agreed within a fixed framework.

Classic fixed-price projects strive for an exact, detailed description of the subject of the contract right from the start of the project. This is intended to keep the risk of subsequent changes as low as possible. In contrast, the agile fixed price at the start of the project aims to provide a complete, but not yet detailed description of the subject of the contract.

Instead, the supplier and customer jointly make assumptions regarding business value, implementation risk, effort and costs. Based on these assumptions, an indicative fixed price range is agreed that is not yet binding. This is followed by a test phase (checkpoint phase) in which implementation begins. At the end of this phase, both sides compare their experiences with the assumptions made initially. You decide on the implementation of the overall project and set the conditions under which changes may take place. Further components of the agile fixed price are the sharing of risks, i.e. H. both parties bear the additional work for unplanned changes and the possibility for both parties to get off at any time (exit points).

Process steps with an agile fixed price

  • In the first step, the subject of the contract is described on a rough level. This includes the main project goals, topics, software requirements and epics . The legal framework is also negotiated and agreed here.
  • Then an epic representative of the project is selected and specified down to the level of user stories . In the case of a suitable epic, a sufficient number of user stories of different types and with different scope of functions is created, which can be used as reference user stories.
  • In the workshop, the supplier and customer then determine the effort for the entire project based on the reference user stories, the other epics and with the help of story points. Assumptions regarding implementation risk and business value are also estimated. This results in an indicative fixed price range that is not yet contractually binding and will only be fixed in a later step (namely at the end of the checkpoint phase).
  • In the fourth step, the checkpoint phase is defined, which is the test phase for the cooperation, as implementation begins there and the first empirical findings are obtained. A length of between two and five sprints is recommended (with a sprint length of two weeks). At the end of the checkpoint phase, the customer and supplier review the assumptions made at the beginning and decide whether they want to implement the overall project. The initially indicative fixed price framework will then also be set in a contractually binding manner. In the checkpoint phase, the distribution of the risks is also agreed, which determines the extent to which costs are charged to the customer if the maximum price range is exceeded.
  • In addition, the roles that are responsible for controlling the project must be named and filled. This includes the product owner on the customer side and the project manager or scrum master on the supplier side. It is also recommended that both parties choose an independent IT appraiser by mutual agreement. From these roles, a steering committee (scope governance) is formed as a decision-making body, which meets regularly and ensures that the continuous specification process works and that the highest prioritized requirements are defined as user stories.
  • In contrast to classic fixed-price projects, with agile fixed-price projects, the project is ended when the customer considers the expected benefits from the deliveries already made to have been fulfilled. This can happen before all the agreed functionalities have been delivered. Agreements must be made so that this flexibility is beneficial for customers and suppliers. For example, the supplier can receive a percentage of the price of the remaining volume or can be assured of a new order worth the remaining volume.

criticism

The success of this contract model stands or falls with the first and last process step:

  • The "Description of the main project objectives" and
  • the "termination of the project when the customer considers the expected benefit from the deliveries already made to have been fulfilled".

Usually the mistake is made of not defining the project goal by quantifiable quality characteristics (such as "reducing the costs of a certain workflow by a certain value" would be a quantifiable goal). Instead, vague definitions are used for the goal (e.g. "ideal and comprehensive support for a workflow"), which cannot be objectified. Or the goals defined in the first step only repeat the functionally assumed scope of the solution (e.g. "all functions must be implemented comprehensively"). This causes major problems, especially in the last process step, when the "expected benefit" is to be evaluated as a criterion for the end of the project. Since the goal cannot be quantified, only subjective ad-hoc assessments can take place, which almost always lead to disputes between the client and the supplier. It is also often forgotten to define what happens when the desired goal turns out to be unattainable, which is quite possible with complex IT projects.

Vaguely defined project goals lead to problems even before the planned end of the project: They prevent the ongoing prioritization of the functions according to expected benefit, since its achievement (= the project goal) cannot be quantified. The implementation of complex IT projects also requires so-called "safe-to-fail experiments" (e.g. spikes or releases of partial functionalities), for which quantifiable goals are also required as an evaluation criterion.

The agile fixed price is particularly suitable as a contract model for complex IT projects in which the scope, course and costs are difficult to predict. When it comes to standardized projects that have already taken place in the same or similar form, the test phase, which is common in the agile fixed price, and the joint review of the project progress may be superfluous. The success of the contract model presented here also requires that the supplier and customer are ready to cooperate closely over the entire duration of the project. A certain amount of mutual trust is also essential in order to be able to agree on costs, effort and functionality. It is also important to ensure that the very rough requirements (epics) that are worked with at the beginning are broken down into smaller, more manageable requirements (user stories) as soon as possible. Otherwise there is a risk of great uncertainty and the associated risks.

Web links

  • Alistair Cockburn : Agile Contracts. September 4, 2006, accessed on June 14, 2017 (English, quick overview of contract forms in agile projects).
  • Thomas Molitor: agile.agreement , accessed on July 3, 2020 (framework focuses on cooperation in agile contracts)

literature

  • Andreas Opelt, Boris Gloger, Wolfgang Pfarl and Ralf Mittermayr: The agile fixed price. Guide to really successful IT project contracts . 3. Edition. Hanser Verlag, 2017, ISBN 978-3-446-45436-1 .
  • 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 3-446-45436-5 .
  • Eckhart Hanser: Agile processes. From XP to Scrum to MAP . Springer-Verlag, 2010, ISBN 978-3-642-12313-9 .
  • Tom Gilb: Competitive Engineering . 1st edition. 2005, ISBN 0-7506-6507-6 .
  • Fritz-Ulli Pieper, Stefan Roock: Agile contracts: drafting contracts for agile development for those responsible for projects . dpunkt.verlag GmbH, 2017, ISBN 978-3-86490-400-4 (200 pages).

Individual evidence

  1. ↑ Andreas Opelt among others: The agile fixed price. Guide to really successful IT project contracts. Hanser Verlag, Munich. 43-46
  2. ^ Mike Cohn: User Stories, Epics, and Themes . Retrieved July 19, 2013
  3. ↑ Andreas Opelt among others: The agile fixed price. Guide to really successful IT project contracts. Hanser Verlag, Munich. 63-90.
  4. ↑ Andreas Opelt among others: The agile fixed price. Guide to really successful IT project contracts. Hanser Verlag, Munich. 48-51.
  5. ↑ Andreas Opelt among others: The agile fixed price. Guide to really successful IT project contracts. Hanser Verlag, Munich. 54-55.
  6. ↑ Andreas Opelt among others: The agile fixed price. Guide to really successful IT project contracts. Hanser Verlag, Munich. 57-60
  7. ↑ Eckhart Hanser: Agile processes. From XP to Scrum to MAP. Springer-Verlag, Berlin and Heidelberg 42.
  8. ^ Tom Gilb Competitive Engineering Butterworth-Heinemann, Oxford. 4-5
  9. ↑ 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.