This article looks at what a customer entering an agile development project should do to ensure it is geared up to implement such a project and that the documents governing the same adequately protect its position.
A customer of an agile development solution should evaluate the following before entering into such a project to ensure it is geared to receiving such a product:
- Internal due diligence - is there internal buy-in for the project for example, is the customer able to delegate authority for decision making?
- External due diligence - has the customer looked into the financial standing, technical and financial capabilities of the potential supplier? Can the supplier meet the objectives required?
- Cultural fit - is the culture of the customer (and the supplier) suited to agile development together?
- Objective - does the customer have a set objective that it plans/needs to reach? How easy is it for the customer to articulate that objective, given there will be no technical specification?
What should an agile development contract include?
By its very nature, an agile development solution is flexible and less certain than traditional software development. Nonetheless, an agile development solution customer should ensure that its agile development contract protects its position, and should cover at least the following provisions.
Process, governance and communication
- Term - estimate the term for development based on the length of each sprint.
- Communication - identify methods of communication and review progress, time, cost and deliverables produced. Include provisions dealing with reviews to highlight issues/uncompleted deliverables, making clear the impact this may have on timetable and/or costs. It should also be made clear who bears these costs and in which circumstances - this will be particularly difficult area to define in an agile project and an early and open discussion about this should take place. One possible solution may be for the customer and supplier to share this risk. Whatever the outcome, the customer should ensure it fully understands and is comfortable with the risk it is taking, given the nature of the agile process.
- Decision-making - identify who will make key decisions; for example, is authority required to be delegated from a director or CEO? If so, is this possible/practical?
- Contract management - include rights enabling active management of the supplier; for example, input into meetings and rights to influence the development process.
- Dispute resolution - include a clear process for discussing and resolving disagreements/disputes that arise; if the project is well-managed with ongoing good communication, disputes should be few and resolved quickly. Otherwise, this will get in the way of the agile process.
- Personnel - consider whether the customer will have rights to influence or decide who makes up the development team. Are there specific vetting procedures required by the customer?
- Key personnel - identify which personnel are imperative to the success of the development and include provisions restricting the supplier's ability to remove them from the project.
Scope and obligations
- Scope - the very nature of agile means development is not set; there will be no 'technical specification': this is 'develop as you go'. Instead, clearly identify customer objectives or required outcomes (see above) and clearly define the scope of each sprint. Provide for flexibility - it is the nature of agile that change control procedures should not be required to alter the scope or direction of the project.
- Supplier obligations - include obligations requiring the supplier to deliver the services, skill and care, and compliance with good industry practise.
- Calculate price - the flexible nature of agile means that a fixed-price is not appropriate, so time and materials is often suggested as an alternative pricing mechanism. A customer will require more certainty, which can be achieved by looking at alternative pricing mechanisms. For example, recording and using consistent pricing methodology, agreeing a fixed-price-per -sprint, retrospective measurement of value delivered, a risk/reward mechanism (whereby the supplier is incentivised for delivering in less time), hierarchy of needs approach (i.e. fixed-price for 'critical' items, not for 'nice-to-haves').
- Monitor price - incorporate rights to monitor the price, thus ensuring, for example, consistent pricing for similar-sized sprints.
Testing and warranty
- Testing - this, and specific acceptance testing criteria, should be applicable to, and included in, each sprint.
- Warranty - although there is no specification to warrant against, include warranties covering quality of software relating to customer requirements of each sprint. Also include consequences for breach of such a warranty; for example repair or replacement, and identify for how long any applicable warranty will last.
- Termination - include clear parameters. For example, a long stop date, which, if not achieved, entitles the customer to terminate and consider whether a refund of all or part of the price would be appropriate. This links back to the customer's objective/outcome and how well this has been defined at the outset.
The terms noted above are not novel per se, but should be assessed in light of the agile development process and the fact that by its very nature it is flexible, providing less contractual certainty than a traditional waterfall software development process.
Agile software development is a very popular process for suppliers and in-house software development teams, and customers considering entering into a contract with a supplier using this methodology should:
- carefully weigh the pros and cons
- undertake full due diligence - internal and external
- ensure it fully understands the flexible nature of agile and the risks involved
- satisfy itself that agile is appropriate for the customer and the development proposed
Ultimately, the customer needs to understand that the output of agile, and its cost/timeline, may not be what it anticipated at the outset - but that might not always be such a bad thing!
This article is the second in a two part series on agile software development. In the first part of this article we provided an overview of the agile development process.