Mike Lyons compares three contract types for agile work: fixed-price, cost-plus, and time-and-materials. Traditional contracts lock in requirements upfront, but agile needs iterative discovery and frequent delivery. He recommends buying team capacity instead of fixed scope and working with procurement to write contracts that allow collaboration.
Alright, I want to talk about the world of agile contracting, procurement and outsourcing. So first we're going to look at three common contract types and their implications for agile delivery. First, we have fixed price contracts. In these types of contracts, the seller agrees to deliver the product for a set price regardless of the actual costs incurred. Now, this type is beneficial when the scope and requirements are really well defined, well understood. Next, we have cost plus contracts. Here the buyer agrees to cover the seller's actual costs plus a fixed fee or percentage. This is usually useful when project scope is uncertain or likely to change. And then we have time and materials contracts. Here the buyer pays for the time spent and the materials used by the seller. This type is flexible and suitable for projects where the scope is really not well defined. Now, each of these contract types come with a certain amount of risks associated with them. For cost plus contracts, there is a risk of budget overruns and reduced incentive for the seller to control the costs. This can conflict with adle's focus on delivering value efficiently. Time and materials contracts offer flexibility, but they can lead to scope creep and difficulty in estimating the total project cost. This challenges our emphasis on predictable delivery and fixed price contracts. Well, they provide budget certainty, but they can limit flexibility and discourage changes. And that potentially can hinder our adaptive nature. So an effective agile contract aligns with agile principles by allowing for evolution in requirements, design and architecture as we learn throughout the project. So let's compare some traditional Agile contracting approaches. In thinking about traditional contracting, we have things like detailed fixed requirements, changes, closely controlled assumptions that the solution can be fully known. Upfront quality that's achieved through gates long big bang value delivery cycles. Customer involvement is limited and focused on inspection and compliance. Rigid change management processes. Work progressing in phases with compliance typically saved until the end. Okay, let's look at agile contracting for a moment. Requirements change frequently based on fast feedback. The ideal solution must be discovered through iteration. Quality is achieved through collaboration and automation. We have frequent value delivery cycles. The customer owns product management and is actively engaged daily. We have flexible change management processes that allow for ever evolving requirements. We address all work incrementally and we use technology to facilitate compliance. An effective agile contract should allow for requirements, design and architecture to evolve as we learn. It should incentivize partnership and collaboration. Collaboration. It should provide a balanced risk reward opportunity for both the buyer and the seller. It should offer cost predictability and provide the ability to ramp down or ramp up our capacity. I remember being part of a team working on a government project under a traditional fixed price contract, and we quickly realized that the contract structure was hindering our ability to respond to changing requirements and for us to deliver our value incrementally. And so, after several sprints of frustration, we approached the client and proposed a hybrid model that maintained overall budget constraints. Constraints that was important to them, but it allowed more flexibility in scope and delivery. And it took quite a bit of negotiation, but we eventually agreed on a structure that included regular checkpoints for reprioritization and a shared risk reward model. This experience taught me the importance of aligning contract structures with agile principles and the value of open communication. As delivery managers, we play a crucial role in promoting agile contracting approaches. We can start by educating stakeholders about the benefits of agile contracts, such as increased flexibility, faster value delivery, and improved collaboration. We can advocate for pilot projects that use agile contracts to demonstrate their effectiveness and build support for wider adoption. Additionally, consider fostering relationships with procurement teams and legal departments. I know you might not have thought you would do that, but that can help in developing contract templates that support agile practices. A couple of closing thoughts on traditional Fixed Price Contracts this is where the price is fixed and the scope is fixed. If you have the ability to influence your contract setup, consider shifting from buying requirements to buying team capacity. This approach gives you cost predictability while also retaining flexibility to adjust your scope as you learn. But if you don't have the ability to shape your contract and you're going to be running a traditional firm, fixed price firm, fixed scope project, you need to be laser focused on tracking and managing the changes to your scope. Remember our Agile Manifesto value of responding to change over following a plan? It's great and it's true, but it doesn't say we'll do it for free. Come on, come on, come on. How much? How much you got? No, no. I'm asking how much the repairs are. I'm asking you how much you got. If you accept new scope, it costs. You could descope something else or you could ask for more money. But don't miss this. Don't skip this step. Agile contracting it's not just about changing document templates. It's about shifting mindsets and fostering true partnerships. By aligning our contracts with agile principles, we can create an environment that supports innovation and flexibility and even continuous delivery of value to our customers.
