I’ve been thinking about contracts recently. That’s not surprising, given the amount of time I’ve been spending in contract negotiations with a very large new client. I’m excited to get started working with them, and I believe that they are genuinely excited to begin working with us. But we’re having trouble getting started, and it’s a familiar kind of trouble: although the principals in the deal all agree on the terms of the deal, the client’s procurement department has sent us a contract that makes no sense for the kind of work we want to do together.
* * *
When my colleague and co-author Jeff Gothelf started talking about Lean UX, his rallying cry for the idea was, “Getting Out of The Deliverables Business.” The key idea here is simple: designers in the old economy are in the business of making deliverables: they are hired to produce a thing–a Photoshop file, a wireframe drawing, a magazine layout, etc. But evidence keeps piling up that this approach doesn’t work. Modern software teams can have more success with an approach that is less about deliverables and more about doing whatever it takes: it’s about working with a team to do research, facilitation, collaborative design and development. (And yes, this approach still includes working in Photoshop and the traditional tools.)
So “Getting Out of The Deliverables Business” was mostly intended, I think, as a metaphor. Or perhaps as a way to prompt software teams to think about how they can be most effective in their work.
But there is one situation where “Getting Out of The Deliverables Business” is not a metaphor or a provocation but rather an imperative: it’s the contract.
My friends and future clients are excited to work in a new way: using an agile rhythm and lean methods to discover and validate the features of the system as we are building it. The problem is that the contract their procurement team wants to use would lock us into an old-style waterfall process—one in which we pretend to know what features we need to build ahead of time, and then grimly build those features (never learning or adjusting as we go) as we race towards our deadline.
To be fair to my future client, in my years of doing consulting based on Agile methods, I’ve never seen a contract from a large firm that didn’t make these same assumptions and force you into a waterfall method. The typical concepts you see built into these contracts include:
- Fixed-scope deliverable: Assuming that the features of the system are known in advance.
- Fixed time deliverable: Assuming that we know how long it will take to build the scope in question, and specifying a delivery date for these features.
- Acceptance: Assuming that at the end of the project, we’ll be able to tell that we’re done based on a set of “acceptance” criteria that were identified (and fully understood) at the beginning of the project.
- Corrections: assuming that the we will provide free labor to “fix” software that doesn’t meet the acceptance criteria (which in term assumes known acceptance criteria.)
- Payment upon acceptance: tying payment to acceptance, rather than to hours worked.
The core fallacy here is the assumption that anyone knows what the end point of the project should be. While that may have been true when companies were purchasing things like corporate identity systems or warehouses, for software this just isn’t true. In software, you discover complexity and efficacy as you work. Thus you must set up software projects as you would a sailing trip: with the ability to sense current conditions, and learn and adjust as you go.
So the contract is the place where we define what business we’re in. To keep ourselves out of the deliverables business, when we write contracts with our clients, we build up from a few key concepts:
- We assume that none of us know exactly what we’re going to build when we get started.
- We assume will use the work we do together on the project to discover the right thing to build together.
- We will design, build, and validate software together with our clients, and do that continuously and iteratively throughout our projects.
- We will evaluate our progress based on the outcomes that we’re achieving. Are we making software that’s effective? Is it serving the needs of the users and the business?
- We ask to be paid for the time we spend, rather than features we build. We commit to demonstrating valuable progress in each iteration. In return, we allow our clients to walk away at any time if they feel they are not getting value.
The bottom line here is that we write time-and-materials based contracts, rather than fixed-scope or fixed-time contracts. I don’t know any other way to do agile consulting. Have you found other ways? How do you stay out of the deliverables business?