Agile fixed price project and contract

Can an Agile project be fixed price? How to deliver Agile development in a fixed price contract? Besides that, how to mix Agile, Scrum and the Waterfall method?

Indeed, there are many questions on the web about how to deliver Agile in a fixed price project. As a matter a fact, there are still many software development projects that are conducted as fixed price and time contracts. If fixed price contract perfectly mixes with the Waterfall method, trying to mix fixed price contract with Agile is like mixing water and oil. Undoubtedly, whatever hard you shake, it never totally mixes.

So how to leverage Agile in fixed price projects?

Introducing the 3 type of projects compared for fixed price contract

First let’s review the 3 types of project that we will compare to highlight the different options. Their representation is based on the project steps (in blue) with the Waterfall software development steps displayed over (in pink). Indeed, all projects go through the same phases with some of them shorter. But the development steps may be sequential or iterative depending on how far the projects go with the implementation of Agile.

Waterfall project

The first type of project is the traditional Waterfall project. Truly, here, we are fully in the Waterfall project standard.

Agile project

Totally at the opposite is the Agile project. In this case also, we are in the market standard but this time Agile. Furthermore, the full Agile project uses Time-and-material contract. We will principally referred to the Agile framework Scrum based on iteration: sprint. Review my introduction to Scrum if you are not familiar with it.

Agile augmented Waterfall

In the middle is what I will call Agile augmented Waterfall. For sure, it is still a Waterfall project but leveraging the power of Agile within the limitations of the Waterfall. Yet, some of these limitations adapt to provide a little bit of flexibility and enable part of agility.

Water-scrum-fall project

Nevertheless, it is different from the market term “water-scrum-fall“. You can find other synonyms for like “water scrum fall”, “waterscrum” or “scrumfall”. In fact, in “waterscrumfall”, at least the requirements, part of the testing phases (acceptance) and implementation remain strictly sequential and with the same level of detail than in the traditional Waterfall project. But, even if Agile empowers only design, development phases and most of test, it is still a progress in comparison to the standard Waterfall approach.

GAO Agile Assessment Guide

For the Agile augmented Waterfall, we will leverage the GAO Agile Assessment Guide as main reference source, in addition to my personal experience. Indeed, the GAO is “watchdog” of the US government congress. Therefore, one on its mission is to audit agency operations to enforce that they spend efficiently and effectively federal funds. And the federal government of the USA invests at least $90 billion annually on Information Technology. As a consequence, the GAO issued a guide to make sure that agencies properly leverage Agile best practices especially in the context of fixed price project. Really, it is the best source I know on how to improve Waterfall projects with Agile.

---

Prerequisites to deliver Agile in a fixed price project

The first step, is of course, to have all stakeholders know what is Agile. Therefore all teams, business stakeholders, in particular POs and PMO should be trained to Agile. Furthermore, for contractors, the best way to address the topic is by requiring a certification for all staff, one of the main market framework like Scrum.

Then the project stakeholders should select the type of contract to deliver the Agile project: either in full Agile in a time-and-material contract or as an Agile augmented Waterfall project in a fixed price contract. They should consider characteristics of the project notably the constraints, the risks and the level of uncertainty to make their choice.

---

Initiating Agile fixed price project

Scope

Waterfall

In Waterfall, the scope is on the “what” and expectations are fully detailed since the beginning.

Agile

On the contrary, a time-and-material Agile project has an emerging scope covering “what” and with the support of “why” defined at high level and being refined as the project goes.

Agile augmented Waterfall

In the middle is the Agile augmented Waterfall project. Like traditional Waterfall, there is a full description of the scope, the “what” but it is at a higher level either Epic (big topics of the project) or Feature (macro functionalities). And it includes the “why” for each to provide a direction. Detail is discovered as the project goes.

Deliverables

Waterfall

Waterfall project has a Statement of Work. In other words, it is the detail of all the work to be done. Undoubtedly, all the requirements are to be captured in detail before starting the project.

Agile

At the opposite, in the Agile time-and-material project, the business sets its ambition based on how much it is ready to invest on the opportunity or better how much it is ready to bet. This investment is a partial investment to have a better understanding on the potential of the opportunity. The first step is a Proof of Concept (POC) that will give a first validation of the outcomes and confirm the velocity of the contracted teams.

Agile augmented Waterfall

In between, the Agile augmented Waterfall project comes with a Statement of Objectives that is:

• A high level description of work (Epic or Feature level),
• A collection of overall objectives as a vision, a purpose,
• Acceptance criteria like expected performance standards and operating constraints,
• Committed people and related organization to achieve desired outcomes.

Truly, the measure is on the outcomes not on specific tasks that contractors should perform.

The Agile augmented Waterfall project tries to find a balance between making sure that an initial high level scope is delivered and enabling:

• Continuous discovery of requirements,
• Flexibility with multiple options,
• Delivery of value iteratively.

Backlog

The backlog is the key artifact supporting these objectives. Actually, it plays the role of the Requirements Traceability Matrix with a strict connection of emerging User Stories to Feature and Epics. Definitively, this makes it possible to prevent scope creep and to enforce high level scope defined at the beginning of the project. And at the same time, it allows flexibility as User Stories emerge while the project goes.

The Waterfall hierarchy of works may become in Agile augmented Waterfall project as follows:

• Epic/Capability may stand for Control account,
• Feature may stand for Work package,
• User Story may stand for Quantifiable back-up data.

---

Planning Agile fixed price project

Cadence

Waterfall

Waterfall project traditionally comes with milestones.

Agile

On the contrary, Agile is time-boxed: the end of each iteration is an opportunity to deliver to production. If there is an important deadline to meet, then additional refinement of the backlog will clarify if the scope can be delivered within the time frame. Mandatory and arbitrable Features will be clearly identified to confirm that it will be possible to deliver the minimum expected before the deadline.

Agile augmented Waterfall

In the middle, the Agile augmented Waterfall project still has the same milestones as the Waterfall project. But these milestones fully leveraged the Agile cadence.

The Agile augmented Waterfall project leverages modular contracting and adapt technical review to build the roadmap.

Modular contracting

Modular contracting is the idea of designing the project, therefore the contract, in delivery batches. Indeed, all delivery batches are independent and consist of the delivery of an increment to production. Furthermore, there should be no need to commit when contracting a delivery batch, to contract the others with the same vendor. As a consequence, when deliverables are properly tested and documented, the project avoids vendor lock-in.

Truly, this is enabled by the state of art of Agile practices as described in Lean Startup where delivery and early exploration of opportunities are delivered with Minimum Viable Product (MVP). All these MVPs onboard the minimum Features to be relevant to the market but also to learn and confirm hypotheses.

Technical Review

Technical Reviews, in Waterfall project, are a control gate on quality and risks to move from one sequential phase to the next. With the delivery of fully operational Features by the flow, Agile allows early validation and quality and risk management. As a result, problems are discovered and fixed early before they become to big. Therefore, Technical review evolves to become a kind of retrospective on the achievements of the past time period and to take a step back.

Schedule

Waterfall

Waterfall project has a detailed planning or roadmap. In a point of fact, it is a reference roadmap, the baseline from which to measure schedule deviation to the initial plan. Definitively, it is not supposed to change and if so, changes are validated by all the project stakeholders.

Agile

Agile comes also with a roadmap. But it is to support the vision where the project goes. It is not a reference or a plan mandatory to follow. In fact, it is living and it evolves with the project.

Agile augmented Waterfall

In between, the Agile augmented Waterfall has a planning or roadmap, but at a higher level (Epic or Feature level) to enable flexibility at User Story level. Similarly to Waterfall project, it has a critical path, but at Epic or Feature level. It integrates a reasonable float or slack at this level to secure this critical path, especially if non-agile teams contribute. In other words, in this approach, the roadmap is also a baseline to measure schedule variances.

Nevertheless, the roadmap is more open to change even if like for the Waterfall, all stakeholders validate the updates. At last, teams should be fully aware of the dependencies, so they can take them into account to self-organize their work.

Estimate work effort and contingency

Waterfall

Waterfall project, based on fully detailed scope, totally estimates the work effort. Without a doubt, Waterfall project dedicates a lot of time and workload to estimation. In addition, the project computes a contingency budget.

Agile

Instead, as we have seen before, Agile proposes a different approach where the estimation of the project starts with how much the business is ready to bet. Nevertheless, a high level estimation at macro level (Epic or Feature) may help with a bottom-up confirmation of the sizing. Still, the real confirmation comes with the early phases and outcomes of the project.

Agile augmented Waterfall

Similarly to Waterfall, the Agile augmented Waterfall project performs estimation but at higher level (Epic or Feature). In addition, there is still a need for a contingency budget. Usually, as there are other means of control and early validation with “by the flow” delivery, the contingency is lower than traditional Waterfall project.

Management of contributions and risks

Note that for all type of project, a special concern is required to secure contributions outside the project teams in time and capacity. Furthermore, risk management should remain a key practice in all projects. Actually, in Agile, backlog is prioritized regarding value and risk management.

---

Executing Agile fixed price project

Collaboration between business and IT

Collaboration over the software development steps are directly connected to the type of project and how deeply Agile is implemented.

Waterfall

First, in Waterfall project, with full sequential steps, collaboration is only during requirements collection and design, then after the build of the solution, during testing and implementing (training).

Agile

Second, in Agile, all steps happen at the same time even if there may be an early step of collection of high level requirements to decide to trigger the project. Collaboration is intensive during all the phases.

Agile augmented Waterfall

At last, in Agile augmented Waterfall project, only the collection of high level requirements is a sequential phase. Indeed, all the other steps happen at the same time even. Therefore collaboration is intensive during all the phases.

Documentation and Data

Waterfall

In Waterfall project, the Statement of Work fully describes the expected documentation and data. Actually, many of them are by products to support sequential phases.

Agile

On the contrary in Agile, the development team limits the documentation to what last, not by products. For instance, there are still specification, in particular when business is complex, but they should be designed to be the technical documentation of the solution. In other word, Agile builds the minimum level of documentation to allow opt-out and for knowledge management. The team and the software generate Data and the Agile metrics iteration after iteration.

Agile augmented Waterfall

In between, the Agile augmented Waterfall project follows here the Agile approach. Documentation is just enough to allow opt-out and for knowledge management. Regarding Data, traditional contract’s data requirement is adapted to align and leverage Agile metrics and related process and artifacts. In addition, there are many moments throughout the Agile development life cycle where project can capture data about the quality.

---

Monitoring and controlling Agile fixed price project

Metrics

If Waterfall project and Agile, either as project or not, have their usually metrics, Agile augmented Waterfall has a mix of metrics coming from both approaches:

• Project Management with metrics coming from:
  • Waterfall, like earn and burn on delivery of Epics or Feature, and deviance from budget and schedule,
  • Agile velocity based on User Stories and at level of iteration, at sprint level, like burn down,
• Technical management of quality for instance on the technical debt and the quality of code,
• Agile maturity and how well the project masters Agile.

Requirements Traceability Matrix

As reviewed before, Waterfall and Agile augmented Waterfall projects enforce initial scope all project long. But the difference is that for the second, the requirement are managed at a higher level (Epic or Feature).

In addition, in Agile augmented Waterfall, this is the backlog that plays the role of Requirements Traceability Matrix. As a consequence, the backlog needs to strictly enforce the hierarchy between User Story, Feature and Epic. This is the prerequisite to prevent scope creep.

Scope change

Waterfall

In Waterfall project, each change triggers a change request and is validated by the project stakeholders. It is financed either by scope arbitration or extra budget.

Agile

On the contrary, in Agile, all changes are welcome except during the iteration, the sprint. The is no need to enforce the scope. But the Product Owner has the responsibility to maximize value at each sprint.

Agile augmented Waterfall

Similarly to Waterfall project, Agile augmented Waterfall, closely manages the scope’s changes and enforces delivery within scope, but at a higher level (Epic or Feature). On the contrary, All changes and emerging needs are welcome at the level of User Story. They should be, like in pure Agile, strictly prioritized to make sure that if an Epic or a Feature runs out of budget, arbitrated User Stories are optional.

---

Closing Agile fixed price project

There is not much to say here as the same closing step is relevant whatever the type of project. Indeed, it is about having a final project review to take a step back on the whole project and capture learning. In Agile, the closing will happen with the switch from project to product mode as the build of new features will keep going until the end of the life of the product.

---

Reassessing to type of your Agile fixed price project

If Agile augmented Waterfall makes it possible to bring some Agile to a project, it remains a compromise with average benefits. Once the project has started and is in a cruse mode, with the contractor delivering the expected value in a stable velocity, it is a good idea to go further. Thanks to the POs fully playing their role and maximizing value iteration after iteration, consider for the next batch of delivery, the next MVP, to switch to time-and-material, so the POs will have full ability to adapt if need be.

---

What’s next? Learn more about Agile at Scale

Check my other posts about Agile at Scale:

• Review my posts on Agile at Scale foundations:
  • What are
    • Agile Squad?
    • Chapter and Guild?
    • Tribe?
    • Product Management Team?
  • What are the team topologies?
  • How to synchronize Agile Squads in Agile at Scale when there are dependencies?
  • Check another of my posts introducing Agile at Scale that leverages the book “Doing Agile Right”.
  • Review my post on the Agile best practices from the GAO the Government Accountability Office from the USA.
• Read my posts on advanced topics around Agile at Scale:
  • What are Leagues in Agile at Scale?
  • How to design Agile Squads so they are aligned on the Value Chains.
  • Why going for horizontal management? What does it mean and what is the value?
  • How roles are reallocated with Agile at Scale?
• Check my posts on project management in Agile at Scale
  • What is the impact of Agile on Project Management?
  • How does Project Portfolio Management change with Agile at Scale?
  • Then, how does Cost of Delay Divided by Duration (CD3) contribute to Agile at Scale?
  • How does Beyond Budgeting support Agile at Scale?
  • Can an Agile Project be fixed price?
  • How to manage Release Management in Agile?
• Review my posts on how to forge a good strategy:
  • What are competition and competitive advantage?
  • What is a good strategy?

Do you want to learn more about Agile fixed price project? Here are some valuable references

Traditional project

• Project Management basics
• Waterfall project basics
• Recommended Project Artifacts by Phase
• What is SDLC Waterfall Model?

GAO, the main inspiration source of this post

• Presentation of the Government Accountability Office
• The GAO Agile Assessment Guide used for this post.
• The web page introducing the GAO Agile Assessment Guide.

Scrum alliance and PMI collaboration, to have an idea what the best of classes propose on the topic

• Agile Practice Guide for project

Some web posts on Agile fixed price project, to have an idea on what is on the web

• PMI
  • Agile versus Waterfall from PMI
  • Fixed price agile projects, making the impossible possible from PMI
• InfoQ
  • Agile Team Meets a Fixed Price Contract (how to move from Waterfall)
• Other sources
  • Agile or Waterfall: Choose the Right Approach to Your Software Project Management
  • Agile Vs Waterfall: Which Is The Best Methodology For Your Project?
  • Case Study: How to Eliminate Flaws of Waterfall and Agile Development Processes Using a Hybrid Model
  • Waterfall vs. Agile: Which is the Right Development Methodology for Your Project?

Some web posts on scrum-water-fall as anti-pattern to Agile

• The insidious institutionalization of “water-Scrum-fall” from Medium
• Analyst Watch: Water-Scrum-fall is the reality of agile
• Delivering Software with Water-Scrum-Fall from InfoQ