Agile Contracts – 6 Best Practices to Kick Start Your Scrum Team

Signing business contractAgile contracting is a broad subject that can be approached from several perspectives with different types of contract. This blog post is written from my own experiences working for a web agency as a supplier. This is also the perspective I use. The customer is an external client desiring support for a software development project.

One of the values of the Agile manifesto is “customer collaboration over contract negotiation”. It states the customer/supplier relationship should be an effective partnership where the contract supports the Agile mindset. Adapting to new insights and processing gained knowledge should be possible after a healthy discussion between all the stakeholders. Responding to change is supported by a lightweight contract that only contains the necessary agreements about the cooperation between the customer and supplier.

In reality however, contract negotiation can be slightly more difficult. When the customer has a great idea that he liked to see fulfilled, enthusiasm is high and the possibilities are endless. We only have to agree upon the contract…

The difficulty with contracts is that it’s all about trust. If there’s enough mutual trust in each other’s capabilities and approach, setting up a contract probably won’t be too difficult. But often the customer and supplier haven’t worked together before, therefore a proven foundation of trust is still absent. The customer wants ‘security’ and complete control around budget, time, quality and scope. A decent change control process is lacking. After some tough negotiations the development team starts but doesn’t truly collaborate with the customer and is just mechanically building what’s written in outdated requirements. A suboptimal product will be the result and the relationship and trust is damaged deeply.

But how to gain trust when you haven’t worked together before? How to create a contract that offers the customer enough control but also gives the team enough flexibility around e.g. scope?

To answer these questions I’ll share some of my own experienced best practices.

  1. Create the product vision & backlog together

Often the customer has an idea about the product and it’s possibilities but a product backlog is still missing. This because the requirements aren’t ready yet or they don’t have any experience with creating a product backlog. A good practice is to offer the customer to create the product backlog together even before setting up a contract. To understand the customer’s needs some intakes are required. Organise a workshop with the customer and the supplier’s development team (including a business analist) and let them create the product backlog together. Ideally you also create the product vision (with the help of Roman Pichler’s product vision board) to ensure mutual understanding. By creating the product vision and backlog together the customer and supplier really get to know each other. More important: the customer meets the actual development team. They are the ones who are going to realise his dream. They are the ones he needs to trust.

  1. Estimate the product backlog together

After creating the product backlog together it’s also possible to estimate it in the presence of the customer. The advantage is the customer hears firsthand what the discussions and questions are about and can answer them directly. Possible complexity is also detected and discussed together which ensures mutual understanding about the given estimations.

  1. Start small

Even when a customer has a huge budget for his project, first agree upon doing only one sprint. After you’ve created the product vision and backlog in a cooperative workshop, only do the first sprint with the goal of delivering some ‘working software’.

  1. Invite the customer to the Scrum sessions

Invite the customer to all the Scrum sessions (assuming Scrum is used). Let the customer experience how the daily Scrum is done, let them experience the discussions during the sprint planning and share all the lessons learned during the sprint review. Most important of course is to gather feedback about the delivered product and evaluate the collaboration.

  1. Sell the entire Scrum team

Fixed Scrum teams that have been working together for a longer period, have experienced up’s & down’s and know there velocity are worth gold. A common pitfall is to separate this ‘golden team’ when a new project arrives. Don’t do this. Keep the team together at all costs. The customers gets the entire team, including tester, analist, designer, Scrum master, developers etc.

  1. Sell sprints

When working with fixed teams that know their velocity, it’s also easier to sell sprints for this team. Of course velocity is something for the team and can vary with every product they build. A fixed, experienced teams knows what they are capable of, they can estimate a product backlog and give a range of how much sprints the realisation will probably take, for example: between 5 – 7 sprints. Because the team is fixed they also know what the costs per sprint are, for example 40.000,-. This means the necessary budget for this project will be between 200.000,- and 280.000,-By selling sprints an advantage for the customer is the possibility of early termination of the contract. When the cost of continuing the project is higher than the additional value received, there is the possibility of just not buying any more sprints[1].

In the end, it’s all about trust. Creating the product vision & backlog together, estimate the backlog together, start small and invite the customer to the Scrum sessions are all practices to build this necessary foundation of trust. When there’s a foundation of trust it also becomes easier to sell the entire Scrum team and sell sprints. And of course, quickly delivering valuable, working software is the ultimate way to gain trust.

These are some of my best practices I’ve learned and experienced in doing projects from the perspective of the supplier. Of course not all the practices will suit every project, supplier and customer, but maybe they offer some new insights. If you have got any other best practices and experiences with Agile contracts, I would love to hear them!