Agile is not just a methodology – it’s a culture
The third sector is under increasing pressure to deliver quality services in uncertain circumstances, with lean budgets, less time and fewer staff than before. It’s never been more important that we adapt to change and work efficiently. To do that, we need to really listen to, and understand, our users.
This is where Agile can help. Agile puts the end user at the centre, helping us design and deliver products that work for people.
It’s hard to implement Agile in an organisation that is otherwise not very agile. Non-profit organisations are often hierarchical, suffering from founder’s syndrome, or are stuck in a “we’ve always done it this way” mindset. This holds them back from keeping up with changes in the world where their audiences, customers, supporters and beneficiaries live.
Pure Agile methodology is not appropriate for many non-techie projects (Agile was built to deliver software, after all). But I believe that we need to be curious about the principles and ethos of Agile. Everyone I’ve spoken to who’s been part of an Agile project team has loved it. This is revealing, given that some aspects of the process are almost the polar opposite of how we usually work in the sector.
The culture of Agile can address some of our most pressing problems
There are a few topics that are guaranteed to make my friends and colleagues in the charity sector tear their hair out. When I mention organisational silos or sign-off procedures, I know we’ll all have something to say about how they’re holding us back.
Here’s how Agile can help:
1. Put people before processes
In the Agile manifesto, the first sentence reads: “Individuals and interactions over processes and tools.” Processes matter, but not as much as people. When a process or a tool drives a project, the team is less able to respond and adapt to feedback from the user. Feedback is often sought late in the day, when it’s much harder to make changes.
Agile encourages us to ask for feedback early and make adjustments accordingly. It asks users for their opinions and uses internal and external expertise to build a better product. It stops a few people’s personal preferences from directing the show.
2. Keep your friends close and your users closer
We still see charity websites that were clearly developed by committee instead of driven by prioritisation of audiences and their needs. How many landing pages have been developed to match a print mailing appeal with no consideration for the user experience? How many organisations tweak their donate page, not to make it easier for their users, but to make life easier for themselves?
Agile methodology teaches us to get out of the narrow world of our organisation and look outside, putting our audiences’ needs first. It helps us really listen to and absorb user feedback so we can make things work better.
3. Say no to silos
“Need help? Set up a request for a support ticket.”
“Thanks for sharing this. I’m going to collate feedback from my whole team, and get back to you in two weeks.”
“Can your team please liaise with the project management lead on my team?”
“From the communications team’s perspective….”
Even in small charities, teams can feel like separate universes. The fundraising team can’t get the information they need from the customer support team, while IT say they don’t hear about important changes from legal until it’s too late.
In Agile, work is done in a cross-functional team made up of people with all the skills that we need to get things done. They work together in service of the end user.
If we need a writer to create some copy as part of a new website project, we have a writer on the team from day one. We don’t decide what content we need and how it should work, then hand it over to a writer to do the writing. We involve them in the project from the beginning so the project benefits from their skills, knowledge of audiences and talent from the start. There’s nothing more demoralising than working on a project where you had no say over things that impact the quality of your work.
4. Minimise waste
Saying no to silos makes another Agile practice much easier - getting rid of hand-offs.
Like many people, I thought it was great to have a person who could translate between technical teams and clients or users. One of the biggest discoveries about Agile for me was that we need to reduce the number of hand-offs.
On reflection, this makes sense.
When one person communicates feedback from another, there’s often a feeling at the back of our minds that they are twisting the feedback to fit their own agenda. So we doubt it, become defensive, hear what suits us. This means that messages get confused, changed or lost. Agile aims to cut out these wasteful exchanges of information and instructions and puts people who need to speak to each other together.
Everyone can benefit from hearing insights straight from the source. I worked with someone who considered herself an expert on campaigning. When she sat in on a co-design workshop with supporters, she was blown away by how different her supporters’ perspectives were. She assumed her audience understood the same complex information and subtle nuances as her, but they didn’t. After that experience, she was much more open to the simplified language and user-first approaches that her communications and fundraising colleagues were suggesting.
5. To be on the team you need to do the work
In charities, we often create massive project teams to make sure everyone who thinks they need to have a say is included. We hope this will reduce delays with sign-off. Often, people muscle their way in because “they want to know what’s going on”.
In Agile, everyone on a project team needs to have a role which contributes to delivery. Project meetings are there for the team to complete the work, not to update everyone in the organisation on what’s going on (other project structures and processes should cover that). In Agile, you don’t get to join the team unless you have a concrete role to play.
6. Find what’s working and what isn’t
Agile helps us see what’s working and what isn’t. From daily stand-ups and sprint reviews to project retrospectives, Agile methodologies encourage us to continuously review what we’re doing.
Agile encourages us to look not only at our output but also at our process. We review not only what has been delivered but also how it’s been delivered. There are structured opportunities to review the team process, culture and approach to stakeholder management. Agile helps us be accountable to each other and to our stakeholders.
Being accountable to each other is tough. Many people dread both giving and getting feedback. But if you formulate your feedback constructively, you will be bringing value to the person you’re giving it to, so it’s likely to be well received.
Project review meetings are sometimes deeply disappointing. Some people will use them to lodge complaints regardless of the fact that they’ve already been addressed. Some people will be defensive and shut down any feedback that isn’t celebratory.
The main goal of reviews is to learn not only what does or doesn’t work, but also why that’s the case. When we know the answer to “why” it’s much easier to know what the team should keep doing and what it needs to stop doing or do differently.
Constructive feedback describes what should happen rather than what shouldn’t and explores how to get to that solution, building on the input of other people on the team.
It is much more powerful to address problems in this way, as a team: being honest about what is and isn’t working, building a joint vision of how it should work and then tracing back the steps that you can make to get to that shared vision. This solution-oriented process will also show you which battles are worth fighting and which are not.
Lip service to Agile won’t deliver the results you need
Agile methodology is used differently in different organisations. It’s not a sticking plaster for dysfunctional working cultures, and it won’t work well if an organisation tries to manipulate Agile to fit an existing, traditional approach.
But genuinely embracing Agile’s principles of feedback, user-centricity, ongoing review and testing, accountability to team members and stakeholders, and trusting teams to deliver their projects, will create better working experiences and, ultimately, better products or project outputs.
Are you experimenting with agile approaches? How has it changed the way you adapt to change? I’d love to hear from you.
