CoreMedia campus talk: reconciling agile methods with fixed price contracts
How can fixed-price contracts be reconciled with agile development?
- Change control is clearly defined: if a specification/deliverable has achieved sign-off, it is a clear-cut change request. While there is no panacea for the “Surely you understand that this feature is part of what we asked for” problem, the document-centric Waterfall model gives both the customer and the vendor mutually agreed mechanisms to resolve these differences.
- The route to acceptance of deliverables is mutually understood and defined beforehand, as it is captured in writing.
- Diversions from this pre-defined route are captured clearly with provisions for delay, poor quality, etc.
Agile methods such as Scrum, on the other hand, address many operational shortcomings of the Waterfall model. By focussing on regular increments of working software and feedback early in the project lifecycle, the risk of getting the wrong result at the end of a long project is mitigated. “It works according to the specification but does not solve our problems fully and we realized this too late to make changes as this was too expensive” is a common theme in many software project reviews.
Unfortunately, fixed-price, fixed-scope contracts and pure Scrum intrinsically do not fit together. Agile methods explicitly embrace the uncertainty evident in every software project by conceding the immense challenge of predicting accurate outcomes in software projects. Thus “fixed price, fixed scope”, driven by the budgeting and planning constraints of business stakeholders, turns into “fixed price, variable scope” when adopting an agile method. While the latter may be acceptable if the degree of variability is in the +-10% range, the variability becomes a real problem for the business if it drifts towards -30% or worse, i.e. leaving the customer with a spent budget and without usable software.
While the Waterfall model (shortcomings and all) expressly attempts to avoid this problem by its focus on thorough analysis, design and planning, Scrum only provides a baseline that “every iteration produces working software” (note that “working” is not necessarily “usable” or “useful to the business”). Scrum does not have the project steering and governance mechanisms required for overall project integration management, with standardized, commonly understood representations in contract structures.
Nevertheless the adoption of agile software development is growing (59% of US enterprises expect increasing numbers of agile projects in the future, according to this survey). This also means an increasing demand for fixed-price agile projects. Thus the question remains on how to reconcile the obvious gaps?
CoreMedia makes intensive use of Scrum in our internal R&D – thus its operational processes are our bread and butter. After several fixed-price agile customer projects, each with its own set of challenges, we have settled on the following principles for such external customer projects.
- Combining fixed-price with agile approaches leads to fixed-price, “largely fixed scope”. At the end of the project, customers have the right to expect fully usable software, with an acceptable degree of variations in functionality. Therefore such a project absolutely requires standard project management mechanisms augmenting the purely iterative perspective of “backlog/sprint planning/sprint/sprint review/repeat”.
- The augmenting project management structure allows fitting the project to a fixed-price contract structure. This again means:
- Defining the deliverables and their nature clearly, whilst acknowledging the functional variability. “Software installed on a test system” is a different beast from “Website migrated and relaunched under high traffic with a newsroom of 100 concurrent editors working 24/7 on the new system”.
- Exposing milestones for sign-off. For example, a functional specification phase with sign-off as a prerequisite before the development sprints begin is a Good Idea.
- Planning the overall project from an end-to-end perspective. We simply acknowledge and accept the challenge of estimating the overall work and duration from day one, even if this estimate has to start with poorly detailed requirements.
- Putting solid reporting and steering into place. A fixed-price project requires reporting and steering mechanisms in a traditional fashion, not just the burn-down report per sprint. Tracking overall progress against an end-to-end plan is vital.
- Balancing the risk of uncertain, vague requirements and fluid backlogs in contractual clauses. The most important contract clause for a fixed-price, agile project is a mutual termination clause. Whilst this is different from typical fixed-price, fixed scope contract practice, I believe this to be the most important element to absorb the risks of uncertainty for both parties. The customer is protected from continuing to spend inappropriate amounts on a vendor who repeatedly fails to achieve sprint goals. Vice versa, a vendor is protected from the unavoidable changing scope contained in high-level backlogs and sprint reviews. Lastly, and perhaps most importantly, a mutual termination clause is a powerful disciplining element driving constructive conflict resolution.
- We neither rely on “fully understood” Scrum roles nor on its practice “in absolute purity” in the collaboration with customers. The potential for confusion and grief down the road of “you are just not applying Scrum right, it would all be ok if you would” is simply too great. The interpretation and application of the method has to take too many facets unique to the project into account (people, technology, requirements, etc.) to allow such simplification and debate on method purity.
While these principles violate some of the the literature on agile methods, I believe they are fundamental when embarking on fixed-price, agile projects, especially of medium to large scale.