Different ways to create technology for change
How waterfall and agile software development differ and how you can choose the right approach for your tech for good project
We’re here to offer you the digital and development expertise you need to make your projects happen. We know you’re focused on making change and have a clear vision for how technology will help you get to that destination. You are absolutely the experts on ‘why?’ (why does this project need to happen?) and that should be the guiding principle of any tech for good project.
Before you start working with a tech partner, you will need to map out a route to get to the outcomes you want and there are several key questions you need to answer together: ‘what?’ (what are we going to build to support your work?), ‘how?’ (how is that going to be delivered’?), and ‘when?’ (when will it be ready to launch?).
After delivering hundreds of projects for charities and NGOs at The Developer Society, we firmly believe that the best tech for good is built in an agile manner. This means your project:
- Evolves as your project develops
- Changes overtime
- Is responsive to your needs and user feedback
- Stays focused on outcomes not outputs
- Uses your budget in a flexible and results focused manner
Of course, there are always constraints when starting a project and great work can be delivered in a ‘waterfall’ way but where possible, we believe an agile approach is ideal for changemakers developing technology.
This article is intended as a short (and necessarily simplified)explainer on the pros and cons of both approaches to help charities, NGOs, and other mission-driven organisations developing technology understand the choices available to them.
Waterfall & agile
Broadly speaking, there are two main approaches to developing technology. The traditional approach is called ‘waterfall’. This is where a detailed plan is agreed at the very start of the project and then the developers follow it as closely as possible to deliver those outputs on a fixed timeline.
With a waterfall project you get some key benefits:
- Set outputs
- Certainty before project starts
- The plan doesn’t change
- You set the ‘why?’, ‘what?’, and ‘when?’
However, the rigidity that offers such certainty comes with some serious drawbacks:
- There is little/no room to react to learning from testing
- The project is high risk as all the budget is assigned based off the initial plan and assumptions
- Responding to issues in the project is difficult as there is no flexibility in what needs to be delivered and for when
- There is no room in the project to adopt new ideas throughout or adapt to external changes
- Any additions or changes are seen as a new project and need to be scheduled as such by the developers
The alternative to this is to take an agile approach. In essence, this means that you agree on a process for how your project will be delivered and how much time will be put into it but not the final deliverables (although you can certainly develop a plan for this up front as long as it remains open to change). This is how software is typically developed at leading groups in the tech sector, from Google to Tesla and runs along these lines:
- To start, you build the smallest working versions of each feature, test them, and then develop them over time
- Projects are realised in stages not in a ‘grand launch’
- Features are prioritised and delivered in that order
- The fixed element is time and as much work as can be done in that time is delivered, no more
- Development occurs in an ongoing manner
- You set the ‘why?’. The ‘what?’ and ‘when?’ are decided by the requirements of the project.
This is a highly responsive approach, allowing you to develop your thinking over time, test out features with users/stakeholders and modify the project in response to their feedback. It allows you to stay flexible and is built on the understanding that plans and circumstances can — and should — change overtime.
However, there are some tradeoffs which can be hard to square with a traditional procurement process.
- It doesn’t guarantee a fixed single outcome, which can be harder to present to high-level stakeholders
- It is harder to predict the final outcome from the start, as learning from outcomes alters the project direction. Where you end up should be closer to where you need to be but you won’t know where that will be on day one
There are a few key differences worth drawing out between the two approaches, the first being iteration. As you’ll see here, with waterfall you set the plan at the start and the project ‘flows’ from there. With agile, you bite off small chunks and take the project in stages, regularly assessing progress and where you need to go next.
Or to put that another way, you make lots of small course corrections along the way rather than big, fixed A to B plans with a higher margin for error.
The second difference is to do with outcomes and testing. The skateboard analogy is a classic here. If you are trying to get from your house to the office and need to build a means of transport, you could decide that you need a car to do it. Building a car is a huge undertaking that will require a lot of time and investment. At the end, you’ll have a car and you better hope that’s exactly what you need. This is the waterfall approach.
The agile approach is to focus on what you need to achieve. In this case, you would build the smallest means of transport possible and try it out. Starting with a skateboard and progressing from there, you will learn huge amounts about your commute and what you need to do it effectively such as how long cars spend in traffic, what the weather is like and so on. You might discover that a bicycle is the quickest and easiest way to travel and stop development there or even change course and spend your time building the best bike possible. Alternatively, you might end up progressing to build a car and it will likely have taken you a little while longer to get there but crucially, by that point you will know two things for certain: that you in fact did need a car in the first place and just what type of car you need (maybe you can have an electric car if you discover charging stations on the route, maybe you don’t need to spend time building cupholders if you never bring drinks in your car). This way, you keep the outcomes you need front and centre at every step of the process.
The third key difference is risk. No matter how much time and research you put into a project, before you actually start building it and testing it in the real world you are by definition working based off of assumptions. With waterfall projects the scale of release — and consequently the risks — are higher. In an uncertain world where you are open to learning from feedback, smaller and more regular releases reduce the level of risk per stage of the project.
The world of technology development can be daunting. It’s jargon heavy and it can be intimidating to get to grips with. However, to build truly great tech for good projects we need to find a balance between the people who know the mission (the ‘why’) and the people who can help them build the technology in a way that will help them create impact (the ‘what’, ‘how’, and ‘when’). When you are starting out on your next technology project, make sure that you and everyone involved in your work are speaking the same language when it comes to how you want the project to run.
You can see here how we like to implement an agile approach at The Developer Society.
John Dunford is the CEO at The Developer Society, a not-for-profit digital agency, working with NGOs and groups with a progressive mission to help make the world we live in a better place.
Stay in touch by subscribing to our updates here. Follow us on Twitter too to show a bit of extra love.
And of course if you liked this article, please add a clap below and share the piece — it means the world to us at DEV.
