How to Contract Agile Developers - A Guide for Charities

Steven Taylor

Steven Taylor

Agile is the most commonly used approach to building new software and digital services. It’s also recommended by leading charitable funders like Comic Relief. This article explains how to contract Agile developers for charities used to more traditional ways of developing resources and projects.

The conundrum

Agile is different because it avoids specifying design or development outputs in advance. Instead it takes an iterative approach, trusting that what needs building will be learnt as the work itself unfolds. This trust is founded on rigorous, test-driven methodologies that ensure insight and learning emerge in a structured and reassuring way.

Agile can feel uncomfortable for other reasons too. It’s impossible to estimate in advance how much a concept or idea will cost. This is because the level of fidelity and depth of functionality required by an idea to be successful can’t be known at the start. Some uncertainty and unpredictability has to be accepted.

The alternative to Agile would be to take what’s known as the ‘waterfall’ approach. Waterfall specifies (i.e. guesses) features and functionality in advance, builds the whole product, then tests it at the end. While this approach may sound more comfortable it doesn’t allow for early testing and rapid changes as learning evolves. It also relies on a big reveal at the end of the project, increasing risk of problems and failures. It’s not really a good way to develop digital services.

Why does Agile work so well?

  • It forces a user-focused and data-driven approach
  • It forces a focus on the most important features first
  • It allows for rapid iteration
  • It improves end-product quality
  • It fosters an honest and transparent relationship during development

Comfortable Agile contracting is possible

The only way to approach agile contracting is time-based. This means fixing the amount of development time your charity will be buying and how many ‘sprints’ of work will be delivered. Then, as the work proceeds, you flex the scope of each sprint in response to your emerging learning. The learning guides development priorities so that time is used in the most effective way and on the most important features.

Because your charity might not have experience of contracting in this way its important to educate your budget holders. That way they can feel more comfortable. Here are six tips to help you and them.

1. Get confident before you commit

A little confidence can make a big difference. Read this article.

Then read CAST’s conversation guide.

Find a supportive peer or friendly designer who has worked with charities and Agile developers. Ask them about their experience.

Search for an agency with the right experience to fit your project. For example a web design agency probably won’t be best at solving problems to do with data or interactive mobile functionality.

2. Understand how Agile reduces risks

Contracting an Agile agency can feel risky, simply because there’s no agreement about the software outputs to be delivered. But avoiding agreeing outputs in advance actually reduces risk and minimises waste. It reduces the risk of building the wrong thing and reduces time spent on unnecessary or less important features. This also creates better value for money.

For example, when we developed MESMAC’s HIV ‘Book-a-Test’ service we used Agile methods to discover the core functionality required, putting other ‘nice-to-have’ features on the ‘backlog’. Because of this MESMAC were able to test the functionality first, before more confidently investing in a much richer service. A waterfall project would have required them to make a single up-front investment, creating greater risk because of the uncertainty of their initial ideas and assumptions.

3. Understand how Agile is similar to outcome-based working

Charities are usually good at focusing on outcomes. They matter more to you and your funders than outputs and deliverables. Agile is similar. It continuously asks what are the priority things that need achieving, then gives developers the role of building a thing that does this. Those priorities are always focused on well-evidenced beneficiary needs and behaviours.

“With Agile charities and developers must both be able to justify everything that is built. This means prioritising user needs over ‘nice-to-haves’ and ‘want-to-haves’. This means that the features and tasks that go into each sprint end up as those focused on the right outcomes. This can be very empowering and fulfilling.”

Dan Sutch, Director, Centre for Acceleration of Social technology

4. Get clear about roles

When contracting it’s also worth thinking about who will be responsible for what. Usually as a charity you’ll take responsibility for user research. Developers will focus on designing and developing. Or you might employ a designer separately.

However, it’s important to avoid silo working and enable everyone’s roles to cross over. This means helping everyone get close to the user research and involving everyone in co-design and testing sessions. That helps all your people build empathy for your users.

Also, you’ll want to get together for:

  • Design workshops - to explore possible ideas, ideally with your beneficiaries present
  • Sprint planning sessions - to make sure you agree on development priorities
  • Sprint retrospectives - to review what was built and understand what happened
  • Testing activity - either running tests together, or exploring test results together

5. Learn typical day rates

Questions about day rates always come up sooner or later. Here’s some rough current costs:

  • Freelance web developer (may or may not be Agile experienced) £250-350/day
  • Development agency (with access to a range of professionals) £500-1000/day
  • Freelance GDS software developer (pro, should be very experienced in Agile methods) £500-850/day

If you receive an expensive quotation from an agency then ask charities they have worked with about the quality of their work. You should do this for everyone!

Check out potential agencies’ business models, because they influence their rates. Those without external shareholders are more likely to be socially motivated and serve the needs of charities. Agencies with external shareholders will be trying to meet greater profit expectations and are less likely to be an ethical fit or deliver extra value.

6. Budget bravely

Regardless of your development needs it’s still all about the money. How much should you allocate to your development partner and how much to the rest of the project? The answer is ‘it depends’. But as a rule of thumb consider:

  • Design and user research: 30%
  • Your organisation’s project costs: 30%
  • Tech development: 40%

There’s no hard or fast rule on this. It depends what type of challenge you are looking to solve so it’s up to you and your developer to negotiate.

Shape Phone Guy

Take action

Want more support? Download our guide to starting and funding a digital service.

Or talk to us. We answer all queries.