An Agile software contract sets up your project for success.

Categories : What We Do

An Agile software contract sets up your project for success.

By Alastair Johnson on 22 August 2019

Using the Agile methodology to build custom software means a very different approach to the traditional waterfall model. In waterfall, fixed-price contracts were common because we had to define scope and specification at the start of the project. With an Agile project, this model cannot be effective. That is why you need an Agile software contract.

Customer collaboration over contract negotiation

The Agile Manifesto has four core values. One of them is that customer collaboration is valued over contract negotiation. The principle does not mean that there is no contract required, quite the contrary. It means that the Agile project contract you put in place for your custom software project needs to enable your project to function in an Agile way.

Consider how these core principles of Agile can impact how you think about your contract.

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Working software is the primary measure of progress.

These principles mean the contract should focus on how the work will be delivered, not what the final product will look like.

What to aim for in an Agile software contract.

  1. Agile is built on collaboration and cooperation between the customer and the build team. The contract needs to be a shared risk/reward framework to encourage a win-win outcome.
  2. The payment terms should be logical. For example, Suria Labs uses a time-based payment cycle. Here, the payment for each calendar month is on the 15th of each month thus each party accepts 50% of the risk. The supplier accepts the risk for the first 15 days, and the client for the second 15 days.
  3. Change is an integral part of the Agile process, and so an Agile software project contract that references charging for changes won’t work.

Steps in getting the contract right.

  1. Customer Engagement. This step should be a designated period for the supplier to carry out some preliminary work, sometimes called a Requirements Engineering Workshop. For example, client and supplier should work together to gather information about requirements, open lines of communication, test assumptions, build rough prototypes, and see if there is merit in the idea behind the project. The product vision should be an output of this work and be referenced in the contract. As an example, a startup without a clear vision of what they want to build can follow to process to generate a product backlog of estimated User Stories (note: link to User Story blog). As a result, there is a much clearer and more accurate understanding of the work and requirements than can be gained from an initial sales meeting. 
  2. Time and effort. At the start of your project, (either at contract time or during your Customer Engagement),  agree on the number and type of team members, and their unit cost. For example, four developers at $x.xx and one designer at $y.yy. This method will allow you to define the ongoing monthly costs of the project.
  3. Waypoints for the project. At the heart of Agile is the concept of iterative development. This means that after each sprint (usually one or two weeks in length) the client will have an updated application with the latest work incorporated which allows progress to be assessed. The sprint cycle is the most obvious waypoint to use. Tools like the burndown chart will also allow you to assess progress against the initial projections.
  4. Lastly, the duration. How long will the engagement be? Your discussions should use estimates to agree on a starting duration for the contract given your understanding of the deliverables and the allocated resources.


If as a customer, you are using the contract to beat your development team over the head, then something has gone wrong with your project. A good Agile project means keeping honest communication at the core of the project, being open to necessary change that is highlighted through this communication, and using working, valuable software as your primary measure of success. A good Agile software contract encourages these behaviours.


How We Built the Travel Icons App

Post By Samuel Khew | 24 November 2020

Let us walk you through how we built Travel Icons, so you have a roadmap on how to build and launch your very own app!

Woman Working From Home
Why Scrum is Ideal for Managing Remote Teams

Post By Samuel Khew | 16 October 2020

Working from home is becoming the new normal thanks to Covid19. Learn how Scrum has helped us maintain productivity and continue to deliver.

Increasing Productivity Graph
When the Team Became TOO Productive

Post By Samuel Khew | 17 February 2020

At Suria Labs we are all about results. Discover how to create a culture and environment that maximises your team’s productivity.

How to build a Minimum Viable Product

Post By Alastair Johnson | 12 February 2020

How to build a minimum viable product – your guide to a successful project.

Minimum Viable Product
What is a Minimum Viable Product?

Post By Alastair Johnson | 11 November 2019

What is an MVP and why does your custom software project need one?

Tablet with custom software
6 reasons to build a custom software solution for your business, and one reason to avoid it.

Post By Alastair Johnson | 14 October 2019

There are excellent reasons to build custom software solutions. A custom-built, or bespoke, software solution can revolutionize your business.

Share On :