Seeking: A Balanced Agile Contract
Agile Contracting! You might think that's the setup for a good joke. "A Scrum Master, an entrepreneur and a lawyer walk into a bar …" But it's no joke. It's something we do, and something we find necessary. We are seeking better ways of developing software as we seek better ways to delight both our customers and their end users. By developing web applications for other organizations, we find ourselves negotiating software development contracts with each of the organizations hiring us. And so, we are also seeking better ways of doing Agile contracting.
Even if the custom software development contract was not something we used every day, we'd still care about contracts. Because, of course, we also deal with employment contracts, supplier contracts and support contracts. All of these contracts form part of one of the four tensions expressed in the values of the Agile Manifesto. "We value collaboration over contract negotiation."
The authors must have included this in the Agile Manifesto because contracts have always been an important part of the traditional way of doing software business according to defined process control. Defined process control is where we claim to know the exact outcome of a process, and we believe that by following a set of clearly defined tasks in the right order we will arrive at exactly that outcome. The software development contract exists, at least in part, as a tool for enforcement that's required by this sort of defined process control development. It's a tool that gets pulled out at any point when the defined process has failed to yield the defined outcome at every step along the way (perhaps the problem domain was too complex). Let the skirmishes over contractual obligations begin!
When we are working according to the Agile values and principles, we continually seek to find better ways to balance the necessary "contract negotiation" on the — more defined and structured—right-hand side of the agile value equation with "collaboration"—the adaptive, empirical quality—on the left. And, we prefer to emphasize the "collaboration".
The contract is a useful, probably necessary, tool for defining a project undertaken by more than one party. But, while the contract has traditionally been seen as a tool to manage risk through control and enforcement, tying a project manager's time up in costly (wasteful?) contract negotiation, it should come to be seen as a tool to support collaboration and cooperation. The contract can define a container which holds the project and allows (if not promotes and encourages) the empirical, collaborative, adaptive, safe-to-fail and safe-to-succeed environment necessary for us to do great development work on a complex software system.
How do we find the right balance to support the tangible aspects of a contract without putting limits on the more intangible spirit of collaboration? Many groups have gone exploring the landscape of Agile Contracting. Fewer groups have shared their findings. In seeking out the good parts of Agile contracting, I've joined an exploration party, a working group, with Dave Campey, an entrepreneur in Cape Town, South Africa, Nancy Van Schooenderwoert, an Agile coach, and Bob Feigin, a lawyer, both of Boston, USA. My role in the group is "Scrum Master with a contract and experience with using it." Liip has supported us by allowing me to share our Agile contract and discuss it in great detail making the search for the good parts of Agile contracting an empirical, adaptive process itself.
Our wiki for this effort is here. We will be adding to it over the coming days, weeks and months. We hope you will also join us in finding the good and balanced parts of Agile contracting.
A Scrum Master, an Entrepreneur and a Lawyer walk into a bar.
The bartender asked, "What'll it be folks?"
"I'd like an Agile contract that supports the spirit of agility necessary for a team to develop a great product", the Scrum Master answered.
The Entrepreneur answered, "I'd like a contract that protects the interests of my lean startup but doesn't interfere with collaboration across company boundaries."
The lawyer heard all this and said, "I can see I'll be writing a lot of fine print."
The bartender (who like all good bartenders was also an agile coach) replied, "That's a tall order, let's see what we can do …"
(This blog post is based on Agile Contracting: The Good Parts presented Aug 29 at ALE2012, the Agile Lean Europe conference, in Barcelona, Spain.)
Add a comment
Your email adress will never be published. Comment spam will be deleted!