A colleague and I have been set the challenge of writing a contract for an IT development factory which will adopt the Scrum Agile methodology. Agile has many benefits in terms of delivery of an end product, that meets the customers quality and functionality requirements but it is far from straight forward to contract for.

In the proposed factory model, there will be 4 week sprints with a release into live each month. There is enough demand that we need 4 to 6 scrums all working in parallel delivering in to the same release. Waterfall projects have a defined scope and often duration which make it pretty straight forward to contract for. Agile, especially in the proposed factory model approach this is not the case.

The decision of what to contract against becomes even more complicated when adopting Agile compared to waterfall. No longer can the Contract Manager be confident he knows what he has purchased, that he has incentivised the supplier to over perform and he has implemented mechanisms to penalise the supplier for poor performance or low productivity. Contracting for FTE’s, developer days or ideal developer days are easy to do but offer little assistance in guaranteeing output delivered.

One could look at using story points to contract against to ensure a certain level of output but would you get a school boy to set and then mark his own homework? No? Neither would I but that is pretty much how Story Points are used in Agile. This means trust becomes more important than ever which is difficult enough for those on the ground involved in the day to day working with the supplier. For those in Supply Chain or Contract Management roles tasked with protecting their employer, this is not a path they would be happy to tread. It also requires a long transition period to baseline the right level of velocity to contract against increasing the level of risk for 3 to 6 months. 

So in short, there are no obvious answers to the challenges I face and for once, even Google doesnt have the answer. Do you?

Tweet