We have a lot to say about Agile contracts, but the best thing to say (and as developers, we love saying this) is that there’s more than one way to do it.

Fixed price contracts and Time & Materials are just the two ends of the spectrum…in between you can charge by hours, man-months, or story points, you can fix scope (and price) at different times, you can increase the frequency of milestones for payment and delivery, and there’s always lots of fun to be hand figuring out a project’s “definition of done.”

But, as is usually the case, the way engineers prefer to talk about something isn’t necessarily the most, shall we say, straightforward. Alistair Cockburn maintains a collection of Agile contract ideas that are invaluable to us when introducing Agile contracts to our customers. We like this list for a couple of reasons: they’re succinct, precise descriptions of the different directions you can go with Agile contracts, embedding shared risk and Agile ideas into contract T&Cs. Also, Alistair’s list thankfully doesn’t go into the details of the more esoteric contracts, but does hint that they’re around. Finally, a more subtle reason we like Alistair’s list is that, when introducing Agile to your customers, every little bit helps to show that Agile development is a well established movement much larger than our two firms and this contract.

I really appreciate the non-combative tone (and eye-candylicious design). Despite TPL being firmly in the Agile camp, there are definitely situations where waterfall applies better. As developers, though, those situations (hands-off stakeholders, lock-step documentation required by law) aren’t really our cup of tea anyway.

The hybrid approach they discuss at the end is actually baked into most Agile projects already. Most projects kick off with an “Iteration 0″…technically this iteration is “for” setting up the technical & management structures for the project, but every iteration 0 I’ve seen has included a broad, high level effort to build your initial backlog. Some up front design is always required, but using Agile forces you to timebox it and get started :)