Building confidence in Agile amongst your charity trustees

Whilst the charity sector’s relationship with Agile is not new, we’ve seen a growth in uptake and popularity of late. Before Covid, it was absolutely worth charities exploring Agile ways of working, but since Covid, we’ve seen Agile principles support the sector’s sudden need to adapt with digital. After all, Agile is centred around overcoming uncertainty and adapting to change; cue, pandemic.

Yet, charities can still be slow to try an Agile approach – an approach that could improve ways of working in the long term and increase impact on the people they strive to serve. As a team, we have many charity trustees among us. First hand experience tells us that it can be reluctance amongst trustees that stunts a charity’s attempt to implement Agile working.

Why? And how can charities help trustees really get Agile once and for all?

What is Agile?

If charities and digital agency partners believe we know all there is to know at the start of a project, we’re wrong. And sometimes, this belief can mean wading through treacle when trying to get anything done if (and when) things surprise us along the way. With Agile, project teams can build and learn at the same time and do the most possible with a budget, with minimal waste.

Agile was born at the start of the noughties as an alternative to ‘Waterfall’ project delivery – which can sometimes be risky. During a project things change: sometimes tech itself changes, sometimes we learn a truth about the user we hadn’t anticipated, and sometimes, charities change their mind on what they want to see at the end of it. Working in an Agile way, as opposed to Waterfall, allows you to embrace these changes and stay focused.

In Waterfall delivery, the project team comes up with a specification which normally doesn’t budge. In an Agile project, there’s no rigid adherence to a delivery plan. You’ll need to get used to change – and maybe even learn to relish it.

High priority features

At the beginning of an Agile project, the team identifies the highest priority features to benefit users. These are worked on first. Should something happen, the important, high priority features will still be there for the user.

Priorities were established recently in an Agile project we’re working on with Skills Builder. We ran a discovery session with one of our UX designers, Christian. Then together with Skills Builder, using insights from that session, we identified many potential features for their platform that would support the user.

We categorised the features into ‘MoSCoW’ – Must/Should/Could/Won’t haves. We took that prioritised list to our tech team so they could estimate effort. They told us, within this project we can achieve this many ‘Musts’, this many ‘Shoulds’, and a couple of ‘Coulds’.

We had our roadmap.

Feedback

Agile is a ‘learn as you go’ approach with a ‘rapid feedback loop’. Daily, or near-daily standups enable different teams working on the project to come together to share, pivot, and plan. New requirements are established and lower priority ones are swapped out. This means that the project always has a flexible backlog of work, and that the team is always working on the highest priority feature at any given time.

What does Agile require from a charity?

To do it right, Agile is time-intensive on the charity side as there needs to be a ‘product owner’ from the charity team. The product owner should be prepared to do regular standups, a retrospective after every sprint, and planning sessions.

In an ideal world, the charity product owner is Agile trained. Alternatively, product owners can be taught as they go but their role involves making a final call on possible conflicting opinions, so they need to hold a sufficient level of authority.

Agile also requires a fixed budget that is flexible in its allocation to specific deliverables. Along the course of the project, the charity can change what money is spent on. This, whilst it might sound haphazard, actually minimises the risk of lumping all your budget into one thing, finding out it doesn’t work, and then being left with zero budget to deliver impact.

Why are trustees reluctant?

Reluctance is understandable. Trustees, by nature, have to be cautious – the ultimate fallout of poorly used resources might land on their shoulders. Sometimes, Agile can sound unpredictable or too flexible. This is why the way Agile is presented is very important.

When explained incorrectly, or not at all, an Agile approach sounds a bit like “I’m going to take your money, and potentially not give you what you think you want.” A lot of trustees come from traditional corporate backgrounds: lawyers, accountants, consultants. In 2017, research found that the average age of a trustee was between 55-64. The professional training some trustees hold could be from 30 years ago – before the Agile Manifesto was even introduced.

Not bearing in mind trustees’ needs and assuming an easy sign-off on your Agile project is unlikely to be successful.

Jack, one of our Digital Partners here at Reason Digital, has experienced Agile proposals both on the charity side and agency side.

How to get your trustees on board

You may understand Agile, but can you explain it?

As someone without a background in project management, four different people explained Agile to me before it finally clicked. Google did not help; the way Agile is described is usually abstract, varies from source to source, and unless you’re directly involved in project delivery, can be difficult to visualise.

Be proactive in educating your trustees. Misconceptions or worries that trustees have about Agile are often down to a lack of knowledge. Many trustees are on multiple charity boards and are time-poor, so providing a few digestible resources that address the things they care about will be more effective than asking them to read a book on Agile or sending them in Google’s direction. It can be frustrating to learn about Agile – especially as it comes with a chunky glossary of jargon.

Countless diagrams break down different aspects of Agile working, and make it less abstract. For example, Henrik Kniberg’s diagrams are a super simplistic way to explain how an Agile team works towards a Minimum Viable Product.

If you’re going to send one resource to your trustees, make it Catalyst’s Agile explainer. It succinctly covers Agile’s benefits and dispels myths. It also contains an Agile definition specific to charity digital projects, from CAST’s Dan Sutch:

“Agile working is a way of managing risk and waste when developing a charity digital project. It involves highly structured cycles of identifying assumptions, testing them and then iterating an approach. This ensures the project is responsive to learning and change, and better suited to the people it serves and the environment in which it operates.”

Fundamentally, Agile is about risk control. So it is ironic that risk-averse trustees tend to resist it. It’s essential to emphasise that with an Agile approach, you’d be mitigating the risk of spending money on one thing that doesn’t work. You’re more likely to be spending money on something that you know will be usable, and impactful, based on human feedback.

Provide social proof

Many charities have used Agile approaches to digital in the past few years to great effect, and some have documented their journey. Showing your trustees that it can and has been done well by charities can alleviate concern.

Gemma Sherrington of Save The Children UK delivered a talk at the Charity Comms Charity Digital conference titled ‘Why Agile is the mindset to get us through the pandemic’ and wrote about the charity’s transformation in a piece for Civil Society.

As a large charity example, it may lack relatability for those on the board of a smaller charity. Make sure that you source realistic success stories that fit in with the scope and visions of your own charity.

Charity projects and Agile go together like..

In an Agile project, you always want to have a prototype or demo of the tool being developed. That way, users can test it and feed back, and you can factor their voice into the product. This step is arguably more important in charity digital projects, than in other sectors.

You’re not analysing feedback about the colour of a checkout button on a clothing retailer’s website. You could be a mental health charity receiving feedback on your new form along the lines of “I’m trans and struggle with my mental health. You don’t have an option for my gender on your form, which makes me feel even worse.” This kind of insight carries much more weight, and Agile allows you to efficiently factor this feedback into the next iteration of the tool.

Mention the helmet

Safeguarding is a major priority for trustees, and practices of an Agile approach can sometimes come across as anti-safeguarding. The idea of putting an imperfect piece of tech in the hands of a potentially vulnerable user can seem irrational.

This can be mitigated by:

• Only giving the tool to people who understand that it’s a demo. As you get further on in the project you can then cast the net to more people.
• Dedicating a chunk of planning time to safeguarding at the beginning and highlighting this as a priority. In the Car/Skateboard analogy, the safeguarding planning we do at the beginning of an Agile project is like a helmet. You’ve got to make sure you’ve made the helmet.

When we work in an Agile way at Reason Digital, we tend to ditch the term ‘Minimum Viable Product’ and strive to create a ‘Minimum Socially Valuable Product.’ Why? Because we don’t just want tech to be viable. We want it to, at a minimum, make someone’s life better. Before putting it in the hands of real people we always ask, is it safe? Are we sure it won’t have unintended consequences?

Implement an Agile champion on your board

An Agile champion doesn’t need to be all singing, all dancing. This can be someone who’s familiar with the Agile approach – perhaps they’ve had experience in their workplace or have already done their own research. If you can nominate one of your trustees as an Agile champion, they can advocate for it on the board even after your 5 minute presentation time is up. This is especially relevant if you’ve got a designated ‘digital trustee’ on your board, or someone with a background in digital.

When trustees are right to be reluctant

With a lot of charity digital projects, Agile works really well, but other projects still suit a Waterfall style delivery. At Reason Digital, we’re big advocates for an Agile approach but are bias-free; we will always recommend the best route to reach your objectives.

Agile does require more time. If your charity is low on capacity, Agile – while it might not be impossible – might be trickier.

Waterfall delivery works when you have a really precise outcome where all unknowns have been removed. For example, a straightforward technical integration project where you’re making System A talk to System B and there’s documentation for both systems.

A new version of success

You’ve got your trustees on board and are ready to get going, but the challenge doesn’t end there. If you’re working in an Agile way for the first time, there’s going to be a change in the way you report on projects. Your milestones are going to be different too.

What the team delivers might not be what you envisioned at the beginning – that’s absolutely not a failure, and is something you’re going to have to assure your trustees of. Perceptions of what success looks like are going to have to change.

It’s important to fight for Agile when it’s right, even if it starts out as an uphill battle. As an approach to charity digital projects, it can give everybody what they want: risk mitigation for the board, a more realistic chance of effective management for whoever is in charge, and most importantly a better product for the people you’re striving to help. If you know your project can deliver value in people’s lives – why not unlock it earlier?