A decade or so ago, Agile delivery came into its own as a best practice for executing complex application development projects in the federal space. While Agile had been in use for some time in the commercial arena, Federal agencies were still largely working within a more sequential or “big bang” approach, often labeled as “waterfall.” In some ways, Agile delivered on its promises, and in some ways, it functioned a bit as a Potemkin village. Exploring the big picture around the success or failure of Agile is outside the purview of this article; instead, the focus of this discussion will be on one of the many inherent conflicts between Agile best practices and the way the federal government issues contracts and does business.
The non-technical elevator pitch for Agile development relies in large part on the perceived (and real) shortfalls associated with doing software application development using waterfall techniques. Broadly speaking, the concept of waterfall development has its genesis in manufacturing, and in the context of the federal government, that primarily means building equipment for the military. When you build equipment, you need to have the specifications set before you start the work. For instance, if you are building a submarine, you better have the submarine fully spec’d out before you start building it. If two of the hundreds of thousands of components of a submarine don’t fit, it sinks. While you can ‘refit’ your submarine from time to time, fundamentally the submarine remains true to the specifications that were set out before the first build step. Rigidity in the specifications and the build is the point of the waterfall approach.
However, by definition, lifting and dropping a waterfall approach into complex software development projects results in a fixed set of deliverables. Given the pace of change in the IT world, software deliverables defined three years ago are often technically obsolete by the time they are delivered, and likely have not kept pace with the evolution of the government’s business requirements in the time between the flash of requirements being defined and the bang of delivery to the actual end users.
To the rescue came Agile development. Designed specifically to enable requirements to evolve with the actual development, Agile allows and encourages refinements in project requirements and priorities to adapt to new mission needs, the newest technologies available and evolving environmental factors.
Sounds good right? Done right, it is However, there is an inherent conflict between a certain type of an ever more popular federal contract structure and Agile: Firm Fixed Price contracts.
Put simply, a firm fixed price (FFP) contract is what it sounds like: for a set price a contractor will deliver a defined set of deliverables. The government can generally rely on the fact that it will get those deliverables at a price defined upfront as opposed to a time and materials (T&M) contract which, though providing more flexibility, ultimately only guarantees the customer that they will get a discrete level of effort, as opposed to a discrete set of outcomes.
The challenge with FFP is that in order for a contractor to price a project, the government’s requirements must be clear and explicit upfront. When Agile is introduced into this scenario, there is an inherent conflict between requirements defined upfront to enable fixed price contracting and one of the main benefits of Agile: ongoing adjustments through the releases and sprints and Agile best practices to modify requirements and priorities as needed or desired in light of emerging needs. Further complications ensue with the concept of short term and frequent requirements refinement. Often in the context of two week sprints, during which failing fast can sometimes be a virtue, the inability of the formal contracting process to keep up with the evolving nature of requirements in the context of Agile delivery can be a real conflict.
What to do? There are lot of FFP Agile application development contracts out there, aren’t there? There are indeed, and there are a number of ways to square the circle between Agile and FFP contracting. Perhaps the most popular approach is to tie the fixed price obligation to Agile capacity or team output. In the case of capacity, the fixed price might be for a discrete number of sprint teams delivering a certain number of sprints over a defined period of time. For output, the contractor may quote a fixed price for the delivery of a discrete number of function points or story points (both of which are essentially project defined incremental software delivery milestones).
Problem solved? To some degree but not entirely. Unfortunately, the above solutions are often viewed as the end solution to the conflict between FFP and Agile, when in fact those solution are only an interim step, and sometimes they present another challenge. In the Agile capacity model, fixing the team size or composition, as many agencies have in recent Agile FFP procurements, may or may not be the right solution for a given contractor. Those that are more disciplined and efficient may, in fact, be able to propose a team composition or team size that would be more cost effective or more productive. So, allowing some flexibility in team size is often a good option that benefits the government. In the latter case with output based on story points, the strategy reveals a misconception about Agile that all story points are equal. Fundamentally, story point estimation is part art and part science – and will differ from team to team within an Agile program, let alone across programs. Thus, each strategy to pre-define the team sizes or output may limit the contractors from providing the best value solution in a competitive procurement.
The last step in solving these contradictions is one that only disciplined Agile contractors adhere to. Across the Federal space, there is unfortunately all too often a lack of that discipline.
Regardless of contract type, almost all government contracts will have the government’s requirements laid out in the award documentation. The variability in how specific those requirements will be set forth is wide (SOW vs SOO, for instance), but regardless, the award document will be a key artifact during the course of the contract, and that artifact in most circumstances will not change.
However, we know that by definition the requirements in an Agile delivery project will change. Therefore, there is a real risk, particularly if the award document is very specific as to requirements, that at the end of the Agile project you will have deliverables that don’t match with the requirements set forth in the award documentation. While a contractor may have met its output or capacity obligations, if the requirements set forth in the contract aren’t met, your customer: 1) may be under potential duress if there is an audit of the final deliverables and the contractual requirements; and/or 2) may not have what they originally said they needed (regardless of what they need today); and/or 3) may say the requirements were not hit and require re-work at the contractor’s expense. While the associated project leader may have great relationships with their mission sponsor and/or their COR, how often do those folks transition to new positions during the course of a three or five year engagement? If a new sponsor comes in, the ‘understanding’ as to current requirements the contractor may have had with the previous regime may not convey to the new sponsor, leaving the contractor holding the bag.
This is where disciplined Agile delivery practices come into play. While important in the context of any Agile delivery, this discipline is particularly key for FFP. Specifically, at the conclusion of each sprint, the government and the contractor go through a documentation process, identifying myriad factors such as team velocities and the like, but also two other key things: 1) memorializing that both the government and the contractor signed off on the current sprint deliverables; and 2) identifying the development focus for the next sprint. In both cases, it is absolutely crucial to document both of these aspects of the sprint process, looking at the evolution of the requirement in both the rearview mirror and prospectively. In that way, through the inherent Agile process, a contractor creates a living and evolving set of documented requirements that, crucially, establishes that what was being delivered is in fact what was directed. Documentation of this type can seem a bit tedious and must be coordinated with the contracting officer, but having seen both disciplined documented Agile delivery as well as its evil twin, in this case an ounce of prevention is absolutely worth a pound of cure.