Most recently when COVID-19 hit, we knew we’d need to adjust our tactics.
Instead of sending people out to the field in person as we’ve historically done, volunteers now respond virtually by gathering damage assessments from fire departments, photos from clients, and meeting with people over video conferences.
But since DCSOps is entirely cloud-based, we can still manage incidents the same way. Even as we updated logic around how volunteers are assigned, the core functionality has remained unchanged.
That’s the power of using software for us at the Red Cross. Let’s look deeper at what we’ve learned along the way.
Start with a minimum viable product
It’s tempting to try to boil the ocean at first: list every feature you want, create a big RFP and hire someone to build your dream application. It’s software, right? Let’s get something that does everything we want!
This approach has not been successful in my experience at the Red Cross. So for DCSOps, we began by embracing the terrific GOV.UK government design principles and started simply with a minimum viable product (MVP) and then began iterating from there.
As we evolved DCSOps, we ensured the product was always functional and could be used by volunteers. We started with a bare bones application and gradually added features as we learned more about user and program needs. For example, at first our solution didn’t include Twilio SMS communications and Google Maps was only used to identify incident locations, not help dispatch or find volunteer responders.
By starting with an MVP, we also learned things early and often that changed our roadmap and prioritization that wouldn’t have been possible if we’d tried to build the entire application at once.
For example, we learned early on that many volunteers didn’t have access to traditional computers (or chose not to use them) and, instead, preferred their phones. Identifying this need and solving it early on allowed us to focus on the actual needs of our volunteers by not ‘getting ahead of our users’ and letting their experience teach us as we went.
Consider open source
At the outset, we made the decision to keep DCSOps open source.
This was controversial, because for many people at the Red Cross, open source sounded risky and unsecure. On the contrary; building open source has enabled us to build a more secure product.
Open source development means that more people are reviewing the code and can help find vulnerabilities. Not only does this transparency help us identify bugs, but anyone can contribute to helping fix vulnerabilities, which is essential for an organization like the Red Cross that relies on volunteers not only for disaster response, but software development as well.
In fact, the majority of the contributions to DCSOps since its inception have been from volunteer developers—it’s truly an application by and for volunteers.
Lastly, being open source helps us ensure that there is no single point of failure. If someone leaves the project, we can always hand development to the next person. In fact, open source development and the need to document and track contributions across contributors & time removes any ‘hidden knowledge’ in one person’s head.
Volunteer development can work
In case you read the note above about developing an application with volunteers with skepticism, I want to ensure you it’s possible.
That said, we don’t build software with volunteers specifically because it’s cheaper. We do it because it aligns with our mission and delivers better long-term results.
Here are a few things we’ve learned along the way—through the development of DCSOps and other applications—that help us ensure that volunteer contributions can result in high quality software development.
You’ll need project managers, not just developers. Your PM could be a staff member, a consultant or a volunteer, but you’ll want to ensure you have people working on the project who are committed for a longer period of time and can help manage the user needs and roadmap. They help volunteers set up their working environments, review pull requests, lead virtual stand-ups and provide general, overall continuity. To build DCSOps, we’ve handled project management using a combination of volunteers, Red Cross staff and paid consultants.
Document user needs—or “stories”—as product requirements—or “issues”—and connect developer code contributions to those requirements. Maintaining traceability between issues and code contributions, will help your developers track code changes over time, who made them, and identify what issues drove those changes.
Have a plan in case your service goes down. We work with an open source support company named Open Tech Strategies on a limited engagement. When things go awry—and they do—we call them in. We don’t always need them on a regular basis, but when we do, they are a lifesaver!
Provide a variety of opportunities to contribute. We’ve found that some people want to show up and work on a specific task for a weekend, and others will contribute regularly. When we create tasks for volunteers, we take into account the range of commitment levels so that there are opportunities for more people to contribute, and ultimately more can get done.
Use hackathons wisely
Hackathons are an important activity for software development at the Red Cross. These events have enabled us to achieve significant development milestones and also recruit ongoing contributors.
In my experience, I typically see two kinds of hackathons used by organizations to inspire or support application development.
First, there are the “big idea” hackathons: people come together for a weekend, brainstorm some ideas to solve a significant problem, build a bunch of discrete solutions and then then go home. They all agree to continue the work but over time, as life happens, the project falls off everyone’s priority list.
Second, there are highly technical hackathons where developers drill deep to solve a specific coding challenge. While real work gets done, these hackathons lack the “change the world” optimism that inspires volunteers to join your cause in the first place.
At Red Cross hackathons, we try to split the difference between the feel good and the coding execution.
We host events where we have a specific problem to solve that will attract people who want to engage in a project that will actually help people. We also ensure that the outcome of the event advances the application so that meaningful product development takes place. This balance of impact and specific code requirements helps ensure that the event is worthwhile for both participants and the Red Cross.