I see two main things going wrong when agile projects are done under traditional contracts.

The first problem is that the parameters of the project – cost, scope and time – are set far too early. The result is often an infeasible project.  No contract, no matter how it’s worded, can fully protect you in that situation.  Even if the contract puts all the financial risk onto the other party, there are plenty of risks that you can’t contract out of – not least of which is the embarrassment and reputational damage of a failed project.

The second problem is that there’s not enough discussion of scope flexibility, during the project.  You don’t necessarily have to out-and-out drop features, but it might be in everyone’s interest to simplify or change them. When I look back at our award-winning large agile project at OSPRI, these discussions were a hallmark of the project and a key reason why it finished exactly on time and slightly under budget.  And yet, if you asked the business now, “what did you miss out on, as a result of scope change during the project” – I suspect they’d be hard pressed to think of any significant features that were completely dropped.  (We did, in fact, drop two quite large features.  One was no longer needed due to business change, and the other was something that no-body seems to have missed. But mostly, we thinned features instead of dropping.)

Open discussion about scope flexibility doesn’t just help the team to deliver on time and on budget. It also helps the team to allocate their resources effectively.  By thinning features, you can take the money you save and devote it to adding value elsewhere.

Finally, scope flexibility is key to being a true professional in software development.  After reading about how professionals in other fields work, I am convinced that software engineers have an obligation to re-evaluate and discuss the scope of each feature as they work.  In fact, I’d go so far to say that, “if you produce a system that exactly matches its pre-written specification, you have acted unprofessionally.”  And yet traditional contracts encourage exactly this this failure of professionalism.

[The next, and final, post in this series will describe what I would do, if it was up to me(!), to preserve agility in software procurement and contracts]