In the fast-evolving world of software development, contractual frameworks must align with the chosen development methodology. For the uninitiated, software development methodologies have undergone significant transformations over the past few decades, typically due to the constant need for a more efficient approach to software development.
The Waterfall model was the method used in the early days, where developers were approaching software development in a linear and sequential way – requirements gathering, system design, implementation, testing and deployment are carried out in phases. The process requires the full completion of each phase before moving to the next, and after the completion of the entire software development lifecycle only will the customers receive its commissioned software. While the Waterfall model is easy to understand and implement, it presents a significant challenge – end users or customers can only identify and discover issues or misalignments at the tail end of the development lifecycle. If the issues or misalignments would require significant effort to rectify, it can seriously derail the project timeline and potentially translate to increased costs to the end users or customers.
The Agile methodologies rose to popularity as they address the major shortcoming of the Waterfall model. The Agile model takes an iterative and flexible approach to software development that emphasises collaboration, adaptability and continuous delivery of working software. Instead of following a fixed sequence, Agile breaks the project into small cycles called “sprints”, and each sprint is typically tied to the delivery of usable working product increments – meaning each sprint aims to produce a potentially shippable or testable piece of functionality of the software. Each sprint would individually go through the entire development lifecycle, from development through the testing, where issues or misalignments are fleshed out early before the completed software is delivered to the end users. To make it even easier to understand, Agile methodologies are akin to building a train, carriage by carriage, testing and improving as you go.
The above being said, the Waterfall model is still preferred by many, primarily due to its predictability and clarity in terms of the scope of work, timeline and cost. Whether a project follows the traditional Waterfall approach or adopts an Agile mindset significantly affects the legal and commercial terms of the software development agreement. This article explores the key contractual differences between Agile and Waterfall models and provides guidance on structuring agreements that align with each.
1. Scope of Work
Due to the difference in the way Waterfall model and Agile model approach software development, the scope of work section in a software development agreement will have to be structured accordingly to cater to the nuances between Waterfall model and Agile model.
For Waterfall model, the scope of work of the software developer would have been defined upfront, including detailed specifications of the software to be developed, taking into account all the end user’s requirements. All these details forming the scope of work of the software developer will then be baked into the software development agreement and ultimately be signed between the developer and the customer.
In the case of Agile model, the software development agreement will still spell out the scope of work of the software developer, but it is structured substantially different than one for Waterfall model. In Agile model, the scope of work would typically only describe, at high-level, what the software is intended to achieve. Instead of detailing the specification and feature list of the software, the agreement will detail the roles and responsibilities of both the customer and the software developer in collaborating through the development lifecycles to work on the “product backlog” or a to-do list of everything that needs to be done to build or improve a software.
.
2. Pricing and Payment Terms
Similarly, pricing and payment terms are structured differently between software development project adopting Waterfall method and one with Agile method.
In the case of Waterfall model, since the software developer will have visibility on the extent of the scope of work, it will typically commit to undertaking the development work on a fixed fee basis. To better manage cash-flow, software developers will also establish payment milestones that correspond to predefined phases of the development lifecycle, with the crossing of each phase translating to payment obligation of a fixed sum by the customer.
The Agile model embraces flexibility by forgoing the need for a detailed, predefined scope of work. It is precisely for this reason that it is difficult, if not impossible, for any software developer to commit to a fixed fee arrangement when adopting Agile development method. For an Agile development project, software developers will typically charge on a time-and-materials basis, similar to how law firms charge based on time spent. In this case, the software development agreement will have to provide the rate cards of the developer, along with a process on how the time spent of the developer can be monitored and verified. We have seen in some instances that the developers have agreed to fixed fee arrangement based on the number of sprints – in these scenarios, the payment term in the software development agreement will then be structured quite similarly to a Waterfall model.
.
3. Change Management
A change control provision explains how changes to the project will be handled after the contract is signed. In the context of software development, it is more crucial for a Waterfall software development project, where the requirements of the software to be built have already been scoped out and made part of the software development agreement. The change control provision will typically set out the process on how to request a change, how can a proposed change be approved, how a proposed change can affect cost or agreed timeline, etc.
For Agile software development project however, this is in a way less critical. Given that the specification and feature list of the desired software are not locked in, changes along the way are already anticipated by both the customer and the developer, and the use of “product backlog” and the ability of the stakeholders to “reprioritise” the product backlog are precisely to manage changes. That being said, we would still advise that a change control provision be included in a software development agreement adopting Agile development method. It should be noted however that the change control provision should only be applicable when changes are being proposed on the objective of the software development.
.
4. Acceptance Mechanism
We cannot stress enough the importance of a clear acceptance mechanism in any agreement involving the delivery of software deliverables. Acceptance mechanism matters in a software development project as it allows for the determination of whether the software delivered by the developer meets the user requirements, as well as the customer’s recourse should the developer fails to deliver.
When it comes to Waterfall software development, the acceptance mechanism is more straightforward. The most common acceptance mechanism will entail the performance of a user acceptance test right after the software is delivered. If the end user verifies that the delivered software meets the exit or acceptance criteria, which is typically prepared based on the agreed specifications of the software, the software delivered will then be considered as having passed the acceptance test and be deployed accordingly. Failure to pass the acceptance test will result in further rectification work by the developer, or termination of the software development agreement in the case of repeated failures in passing acceptance test.
On the other hand, acceptance mechanism is slightly more complicated for Agile software development. As opposed to there being only one acceptance test at the end of the development lifecycle, acceptance testing can be said to be carried out throughout the entire development lifecycle based on the individual product backlog completed. In the software development agreement, parties will agree on a list of criteria for a backlog item (item to be delivered pursuant to a product backlog) to be considered accepted (commonly known as “Definition of Done”). Some examples might include the passing of unit and functional testing by the backlog item, acceptance criteria written in the user story having been met, or where the backlog item is approved during the sprint review. The acceptance mechanism of an Agile software development agreement will have to be structured with the above criteria in mind. Additionally, we will also advise for the incorporation of a final sign-off by the customer after all the sprints have been concluded, and where all the backlog items achieve Definition of Done.
.
When reviewing or finalising a software development agreement, it is important to first understand the type of software development methodologies to be employed by the developer. While this article only examines the key differences between Agile and Waterfall models, these are not the only two development methodologies out there. These software development methodologies typically differ in terms of the workflow of the developer, which in turn affect payment terms and acceptance mechanisms. Companies looking to commission the development of custom-built software should make sure that the legal team working on finalising the software development agreement is aware of the nuances presented by the software development methodology employed so that the contractual terms would align with operation and practical expectations.
The Technology Practice Group at Halim Hong & Quek frequently represents our clients on various technology and software outsourcing or development exercises. If your organisation is planning for a software development project and would need external legal support, or if you simply would like to know more about how we can help in a software development project, please feel free to reach out to the partners of the Technology Practice Group.
About the authors
Lo Khai Yi Partner Co-Head of Technology Practice Group Technology, Media & Telecommunications (“TMT”), Technology Acquisition and Outsourcing, Telecommunication Licensing and Acquisition, Cybersecurity [email protected].
◦
Ong Johnson Partner Head of Technology Practice Group Technology, Media & Telecommunications (“TMT”), Fintech, TMT Disputes, TMT Competition, Regulatory and Compliance [email protected]
Agile and Waterfall Software Development Methodologies – How the Differences Impact Contract Terms
In the fast-evolving world of software development, contractual frameworks must align with the chosen development methodology. For the uninitiated, software development methodologies have undergone significant transformations over the past few decades, typically due to the constant need for a more efficient approach to software development.
The Waterfall model was the method used in the early days, where developers were approaching software development in a linear and sequential way – requirements gathering, system design, implementation, testing and deployment are carried out in phases. The process requires the full completion of each phase before moving to the next, and after the completion of the entire software development lifecycle only will the customers receive its commissioned software. While the Waterfall model is easy to understand and implement, it presents a significant challenge – end users or customers can only identify and discover issues or misalignments at the tail end of the development lifecycle. If the issues or misalignments would require significant effort to rectify, it can seriously derail the project timeline and potentially translate to increased costs to the end users or customers.
The Agile methodologies rose to popularity as they address the major shortcoming of the Waterfall model. The Agile model takes an iterative and flexible approach to software development that emphasises collaboration, adaptability and continuous delivery of working software. Instead of following a fixed sequence, Agile breaks the project into small cycles called “sprints”, and each sprint is typically tied to the delivery of usable working product increments – meaning each sprint aims to produce a potentially shippable or testable piece of functionality of the software. Each sprint would individually go through the entire development lifecycle, from development through the testing, where issues or misalignments are fleshed out early before the completed software is delivered to the end users. To make it even easier to understand, Agile methodologies are akin to building a train, carriage by carriage, testing and improving as you go.
The above being said, the Waterfall model is still preferred by many, primarily due to its predictability and clarity in terms of the scope of work, timeline and cost. Whether a project follows the traditional Waterfall approach or adopts an Agile mindset significantly affects the legal and commercial terms of the software development agreement. This article explores the key contractual differences between Agile and Waterfall models and provides guidance on structuring agreements that align with each.
When reviewing or finalising a software development agreement, it is important to first understand the type of software development methodologies to be employed by the developer. While this article only examines the key differences between Agile and Waterfall models, these are not the only two development methodologies out there. These software development methodologies typically differ in terms of the workflow of the developer, which in turn affect payment terms and acceptance mechanisms. Companies looking to commission the development of custom-built software should make sure that the legal team working on finalising the software development agreement is aware of the nuances presented by the software development methodology employed so that the contractual terms would align with operation and practical expectations.
The Technology Practice Group at Halim Hong & Quek frequently represents our clients on various technology and software outsourcing or development exercises. If your organisation is planning for a software development project and would need external legal support, or if you simply would like to know more about how we can help in a software development project, please feel free to reach out to the partners of the Technology Practice Group.
About the authors
Lo Khai Yi
Partner
Co-Head of Technology Practice Group
Technology, Media & Telecommunications (“TMT”), Technology
Acquisition and Outsourcing, Telecommunication Licensing and
Acquisition, Cybersecurity
[email protected].
◦
Ong Johnson
Partner
Head of Technology Practice Group
Technology, Media & Telecommunications (“TMT”),
Fintech, TMT Disputes, TMT Competition, Regulatory
and Compliance
[email protected]
More of our Tech articles that you should read: