While the agile software development movement lends itself very nicely to lean internet startups, large corporates with their multi-level governance approvals are slighted more challenged when trying to adopt agile development methodology for in-house IT projects.
To make things more difficult, the nature of agile development doesn’t fit well with procurement officers and lawyers who like certainty written into contracts.
As Agile development is primarily an iterative/collaborative design and build process – this is inherently conflicted with the preferred corporate procurement model of traditional waterfall contracts with fixed scope/requirement for fixed fees within a defined project timeline.
I won’t bother to get into the semantic distinctions engineers use between scrum and agile development, needless to say that the contracts that lawyers ultimately draft for these types of projects will intuitively contain more ‘scrum’-like mechanisms in the contract and statements of work.
So how can agile development be captured contractually? Some of the key issues to address in agile development contracted services include:
- Choosing the billing model – due to its nature, agile development contracts will use some form of hybrid T&M billing model, quite often capped T&M.
- Change management – by definition, the agile model should bypass the need for very structured formal change request and approval processes.
- Establishing key personnel.
- Intense/regular workshop sessions – to gather & validate initial requirements.
- Breaking up SOWs into smaller chunks.
- Managing offshoring – a lot of agile development relies on offshore teams turning around code.
- Define the delivery cycle for iterative code drops (fortnightly, monthly, etc.)
- user acceptance – in agile development this can include exploratory testing in addition to verification tests.
The acceptance of agile development models in big corporate contracting is still very much work in progress. It’s often more politically safe and with lower “corporate risk” for smaller coding projects.
Vendors are keen to promote the merits of agile development because it encourages a much closer collaborative customer working relationship, better reflects the reality of obsolete or yet to be determined user requirements and the billing methodology usually doesn’t shift all the risk to the vendor to deliver all the final requirements within an original or outdated fixed price quote.
Large IT customers with their teams of lawyers, finance and sourcing professionals are more comfortable with the traditional contract structures and risk allocation models. For Agile development to be used in these environments, successful adoption will rely on the CIO or senior management to know upfront what quantitative results they want, so they can communicate this to their contract drafting lawyers.
