For many years, I have been advising both developers and procurers on software development agreements. During that time, there have been many phases and trends. In simple terms these can be broken down into two categories, Waterfall which is linear and sequential and a wide range of iterative methodologies, notably Rapid Application Development and various manifestations of Agile, such as Dynamic Systems Development Method (DSDM), Crystal Clear, Extreme Programming (XP) and of course Scrum.
There are many differences between the Waterfall and iterative Agile methodologies. To determine which is more appropriate one has to balance and evaluate a panoply of often conflicting drivers. Some of the key issues are set out below.
Flexibility
Unlike with the waterfall fixed specification model, there is real flexibility in the agile scenario. Whilst there is an agreed Product Backlog setting out the expectations of what is to be delivered in the project as a whole, there is typically no absolute commitment to the delivery of a fixed set of functionality. The parties agree on what is anticipated from each Sprint by way of an agreed Sprint Backlog but there are unlikely to be any meaningful sanctions if these are not achieved.
Whilst this may let an inefficient developer off the hook, it is more likely to recognise and reflect the dynamics of a typical development project where it may be difficult at the outset to define the ultimate goal and in which perspectives and requirements change during the course of the project.
Certainty
Some customers would argue that they need certainty as to what will be delivered and at what price before they commit to a particular developer and that agile development methodologies don’t give them that. However, that apparent disadvantage may be substantially outweighed by the ability easily to “can” a development project either because the customer’s situation has changed or the developer is not meeting expectations.
Horses for Courses
In some projects, the requirements are more uncertain and fluid whilst in others they will be easy to define at the outset. In the former case, an agile approach, probably based on scrum will reflect the reality of the situation whereas in the latter, there is a strong case to be made for a waterfall approach.
Terminology
Although this might sound disingenuous and irrelevant, some people of a more traditional leaning well versed in the conventional terminology of waterfall and the associated conceptual rigidity find the agile lexicon both unfamiliar and off-putting. With terms such as “potentially shippable product increment”, “done done”, “burndown chart” and “scrum master” this is not altogether surprising.
Collaboration
Whereas it is typical for each party in a waterfall software development project to appoint a representative and for them to liaise as appropriate, there is nothing like the same level of interaction as occurs in the agile firmament in which there are often daily meetings or “scrums” between the parties. The key players are usually the “Product Owner”, the “Scrum Master” and the “Development Team”. The Product Owner represents the interests of the customer and communicates its vision and objectives. The Scrum Master’s role is to oversee and co-ordinate the whole project and ensure that the parties are working co-operatively through the scrum process methodology. The Scrum Master is nearly always a member of the developer’s team but symptomatically of the fluidity and flexibility of Agile, may sometimes be a member of the customer’s team. One would think that the term “Development Team” connotes the developers themselves but it is possible that the team also comprises customer representatives although this could cause difficulties.
Duration
Whilst projects adopting the waterfall methodology may have an associated timetable stretching well into the future, in some cases 24 months or more, Agile sprints usually last 1-2 weeks and the entire project may end with any “Sprint Review Meeting” which looks back to determine and demonstrate which “Stories” (i.e. outline descriptions of elements of functionality) have been completed during the Sprint. One can see from this marked difference that the customer might feel reassured by the lack of long term commitment in a context where there is scope for both relationship deterioration and change of plan. However, if the escape hatch is for both parties then the customer may be concerned about being left in the lurch when it considers the project to be incomplete.
Payment Terms
Whereas in the waterfall scenario, payment of the whole or a major percentage of the project fee may well be due only at the end of the project after successful acceptance testing, in the Agile world, the agreement may provide for payment to be made at the end of each Sprint. Obviously if a sizeable proportion of the whole or the entire project price is only due on acceptance this will focus the mind of the developer and give the customer a strong commercial position. Indeed, in many Agile contracts payment is connected either loosely or not at all to the achievement of particular milestones and the financial basis is more akin to a “time and materials” scenario.
For information on our model Agile contract template, please see https://www.weblaw.co.uk/it-contract-templates/agile-software-development-contract/
Simon Halberstam