We gathered senior legal and IT professionals from both vendors and major users of information services to a roundtable discussion as to their uptake of agile based computing. On an unattributable basis, we obtained a wide range of views as to the benefits and disbenefits of traditional waterfall versus agile software development contracts.
Traditional “Waterfall” approach
A waterfall approach to a software development contract typically has the following phases:
Each phase follows on from the previous one after completion, cascading down like a “waterfall” and hence its name. Like a waterfall, it flows down and never flows up. Often, this method is seen as ‘safe’ as detailed documentation is repared and everything is agreed and signed off at the beginning of the contract, including contractual mechanisms for a change authorisation process intended to minimise changes. The downsides to waterfall are: a slow start to the project, difficulty or lack of flexibility to change specification, and no customer visibility of software until completion of development. Waterfall works for commercial arrangements where payments are typically made against completion of fixed phases but it will almost certainly fail if a customer’s requirement is fluid or ambiguous at the start of a project.
Owing to the difficulties described above, there has been a move towards a contracting methodology whereby a lengthy waterfall contract is broken down into many smaller and shorter development cycles, known as iterations, perhaps on a weekly basis. Typically, no complicated specification is agreed and the software vendor focuses on producing the required work product (i.e. the purpose of the project) by evolution. Over multiple iterations, the software vendor will have constant collaboration with the customer and will therefore be able to respond to changes in user requirements. In each iteration, a full software development cycle takes place and a working software is deployed for customer’s early feedback.
A software vendor in an agile contract may be remunerated by reference to:
- the savings it achieved for the customer
- the value it produced
- an efficiency index or customer satisfaction
- key performance indicators
- T&M (time and materials) incurred
Experiences of “Agile” contract users
"Vendors notice an increase in customer satisfaction as the short development cycle of the agile approach de-risks the project. "
Succeed or fail fast
Successful users of agile contracts reported that the value of such contracts are generally small – in the range of US$100,000 to US$150,000. Customers expect an agile contract to be fast: a vendor will need to understand the purpose of the project by the first week and if by the third week the vendor failed to deliver a tangible work product then this will lead to a backlog of issues and the agile contract would be regarded as a failure. Vendors tend to be retained on a time and materials basis, with continuation dependent upon discussion taken at weekly review meetings. (This incentivised vendors to concentrate on demonstrating incremental weekly achievement, and worked against longer term planning towards major advancements). Without a fixed scope of work, vendors are unwilling to work on a fixed price basis.
Real connection with the Users
Agile contract users say that the involvement of their IT personnel and potential users of the software on a weekly basis with the software vendor has proven to be valuable in the project. This alleviated one of the biggest concerns in a waterfall contract – a disconnect between the real users and the vendor.
Not for large projects
Agile contract users say that they are not comfortable with using the agile approach for high value contracts. This is because they are unwilling to move on to the next stage of the project unless all checks are done and issues are identified and resolved. This may be especially important when a latent problem is discovered at a stage which may require a total revamp of the design to resolve the issue and can be very costly to implement.
Large software vendors say they do not mind letting a smaller vendor take up the smaller value work as the larger software vendors believe that the waterfall approach is a hard but safe way.
Vendors notice an increase in customer satisfaction as the short development cycle of the agile approach de-risks the project. In an 18 month plus project, what a customer wanted at the outset would most likely be different to their requirement at the time of eventual delivery. Conversely, the agile approach may end up producing many iterations of prototypes but fail to deliver a production-ready system.
To maximise the chances of delivery in an agile contract, it was agreed that having a clear vision at the outset is critical. But just stating the output must be “user-friendly” is not sufficient to enable a vendor to understand the purpose and scope of the project.
Finance sector systems
The banking and finance sector finds that agile contracting does not work with tightly linked IT systems. Changing the underlying code of a section of a software will lead to dependency issues of other linked software. Also, financial institutions face intense scrutiny from the regulators in relation to the robust documentation and definition of their systems. Although FinTech applications often lend themselves to agile development, in the main financial institutions will likely remain users of the waterfall approach.
"Customers expect an agile contract to be fast...if by the third week the vendor failed to deliver a tangible work product then...the agile contract would be regarded as a failure. "
Vendors say that breaking down a large IT project into many smaller components and awarding each component to a different vendor is not a good idea as there is lack of synergy among the vendors. However, the Austrian government successfully adopted this multi-sourcing approach, and favoured retaining a systems integrator responsible for managing the large number of vendors. In the main, however, agile IT projects require only a handful of vendors and a customer may choose to cap the project to a certain number of iterations.
Customers say that the agile methodology is best for non-urgent and non-safety critical matters, while vendors say that agile methodology is best for customers who are not certain what they want and it helps develop an on-going relationship with the customer.
Looking to the future, it was thought that the biggest market for agile contracts would be development of mobile apps and websites. Agile contracting is a necessary development as vendors need to come up with new ways to attract customers. Microservicing (described as agile on steroids) is commonly adopted by large tech companies such as Google and Facebook. In that type of development, almost every day produces a new iteration.