Contracting for agile

Have I posed an oxymoron, to wit: contracting for Agile?

Perhaps. Consider these agile values:

• Tight coupling among, and high cohesion between team members
• Maximum decoupling between deliverables, and decoupling between the deliverables and a pre-planned outcome
• Trusting relationships--all for one; one for all.
• Personal commitment and accountability for team performance
• Subordination of cost and schedule to customer satisfaction

There are more, of course, (check out the agile manifesto) but these are enough to consider how these value collide with, or are consistent with a contract environment.

Contracting has many purposes.  Among the top ten: expand the resource base, gain access to skills and environment, and transfer risk. 

But, in a flip of Agile values, a contract environment loosens the team member coupling and tightens the coupling between a plan and a deliverable. 

What about the cost-schedule-scope relationship? It's a rare SOW that begins: "The contracting agency does not value cost and schedule as much as it values outcomes".  That's a tough one to explain to the public constituency, and their representatives, who have a fixed-price retail market orientation.

And, most troublesome, a contract presumes low trust.  Indeed, a contract's so-called high ceremony--all the terms and conditions of a contract--is the antidote to low trust.  A consequence, if not a purpose, of a vehicle like a contract to institutionalize "low trust high ceremony" is an adversarial relationship.

To be sure, an adversarial relationship need not be unfriendly or acrimonious.  Some of my best friends are contractors!  And, I've been one myself.  However, parties to a contract are not really friends; they are parties to a joint interest in an outcome.  (in diplomacy: countries do not have friends; they have interests).  When stresses set in, the adversarial juices amp up.

So what to do?

1. Set in place a contract framework for all the T's and C's
2. On the agency side, parse the requirements backlog into work orders of scope for which the confidence interval is relatively narrow.
3. Freeze the work order requirements for development (call this an 'ice cube')
4. Push the ice cube through the contract channel as a work order
5. Reflect on the initial results; adjust the backlog; parse a next ice cube
6. Repeat until the money runs out.

In effect, this is a strategy of rationing emergence and scope by a funding cap.  However, in terms of answering the mail from the public constituents, each 'ice cube' should be worth what's paid for it.  In aggregate, the public should be, or may be, satisfied with the aggregate bag of ice.

Do you think this will work?

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.