The Contractual Process

A few days ago during an agile workshop I was explaining the concept of optional scope contracts in agile processes, and listening to myself talk, the word “waterfall” suddenly came to mind. I had never thought of it in those terms before, even though this is clearly what it is.

What I hadn’t been thinking clearly about was the fact that contracting also has a process, which usually tracks or mirrors the software development process, but doesn’t have to. But we don’t see that until we radically change the software process away from the classic waterfall process.

The waterfall process for software development has a number of known problems. The agile process (basically an iterative process) arose in response to the need to get risk and scope under control, allowing to developer to reassess the state of development continuously and intervene to take decisions.

But when agile processes are adopted, it’s actually the exception more than the rule that the contracting process is changed, too. The contracting process stays waterfall (requirements up front, etc.). We end up with a mismatch between the two processes. If people were to think this way, in terms of processes, maybe they would start “getting it” about the possibility of doing contracting in different ways – effectively, an agile contracting process.