Skip to content

CoreMedia campus talk: reconciling agile methods with fixed price contracts

by on June 3, 2012
We have been honoured to present and discuss various topics on nearby university campuses.  After a start this spring with a talk on CoreMedia’s experience with MongoDB for the “Distributed Systems” research group (VSIS) at the Hamburg University computer science campus, our “campus roadshow” continued on a completely different topic with a talk from  Lars Seebach and André Collet  at the University of the Applied Sciences in Elmshorn.
Lars and André presented a deeply operational topic from the realm of project management:

How can fixed-price contracts be reconciled with agile development?

Scouring the web for literature on this topic can lead to a confusing set of ideas, many of which are impractical when facing procurement and contracting processes common in large enterprises.Lars and André had exposed an interesting dilemma:Fixed-price, fixed scope contracts are readily mapped to classical software development processes such as the Waterfall model, however no such direct representation exists for Scrum.Processes requiring written sign-off for specifications, designs and other artifacts lead a clear-cut, unmistakable mutual understanding of progress, scope and achievement in the project, and typically have good representations in contract structures:

  1. 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.
  2. The route to acceptance of deliverables is mutually understood and defined beforehand, as it is captured in writing.
  3. 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.

  1. 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”.
  2. The augmenting project management structure allows fitting the project to a fixed-price contract structure. This again means:
    1. 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”.
    2. 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.
    3. 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.
    4. 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.
    5. 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.
  1. 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.

From → Agile, Dev

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s