Since January we’ve been branding, designing and building the 2018 Pride in London app (which you can download here). It was a big deal to take on a project like this for free and involved considerable reputational risk if we didn’t deliver. So why did we chose to do it in the first place? And what did we learn along the way?
As an open source, pro-bono, voluntary project that has been built for the community, by the community, it’s clearly been a labour of love and collaboration. And Doodles.
At Red Badger, we’re on a mission to make the technology industry a more socially conscious and inclusive one and have a dedicated Social Value task force to make this happen. So when in December last year we found out Pride in London were looking for a partner to build their 2018 app we got rather excited.
But as we were all flat out on client projects, we knew that Red Badger couldn’t commit to delivering this as a pro-bono project. So we did a callout for volunteers on Slack. The response was overwhelming. Over half the company offered to help, and nearly a dozen people committed to giving eight hours a week to the project.
And what could be more apt for a project like the Pride in London app, than a mass of volunteers? Inclusive, community-orientated and vibrant, our approach couldn’t have been more on-brand if we tried. Throw in some exciting new tech, free rein on the visual identity, plentiful rainbow gifs on Slack, package it all up in open source and it’s easy to see why we got so excited.
We started in January earlier this year and approached things in the same way we would any other project. We had a kick-off session with our key stakeholders, scoping out the major features on the backlog, taking into account successes and failures from last year’s app. We established ways of working, setting up our open source approach, project workflow, key tools (Trello, Github) and got regular touchpoints in the diary.
The key difference? All of this was done on evenings and weekends.
This was also one of the key challenges for us. Here at Red Badger we like to work in cross-functional, co-located teams. Why is this so important to us? Because it leads to very small feedback loops and thus greater efficiency. It’s the sort of thing you notice in its absence; if the UXD team had a question for our Pride Product Owner, or a question around tech feasibility, replies were often stilted and on Trello or Slack, rather than face to face, leaving room for misinterpretation and creating lags in productivity.
We needed to create a space that brought the full cross-functional team together on the weekend. All 30-odd of them. Enter the Pride Lab. It’s like a hackathon but with none of the negative connotations of competitive, macho engineers working round the clock. Instead, this was more like a design sprint, in a day, with all skills at the table feeding in their ideas and rapidly prototyping.
After a successful couple of Pride Labs and some run ahead UXD we had a pretty well-formed backlog, a scoped out MDP (Minimum Desirable Product) and a load of features sitting in the ‘Ready for Dev’ column on our backlog. But take up for the evening coding sessions I’d put in was low. And many of those that had committed time way back in December now had other commitments/illness/general life stuff to deal with. I had three options; lock everyone in a room until the app was built, ask Red Badger management to take people off client projects to get it done, or understand what barriers there were that were preventing people from volunteering so that I could better enable them.
I sent out a survey to our engineering and testing team to understand their needs better, and more than a dozen responded. Rather than have sessions in the week after work when they were tired, many said, they would prefer a weekly Pride Lab which they could drop into if they were free. Some had to travel a long way so preferred to work from home but would be online at the same time.
The developers had spoken, and I listened. Weekly Pride Labs went in the diary and our throughput started to increase dramatically (though, to be fair, the starting point was 0).
To de-risk a rather intimidating timeline for the app we also managed to get project holidays for some of our key volunteers every other Friday. This gave our Saturday Pride Labs a real kick of momentum by helping our volunteers to pick up where they left off the previous day.
It hasn’t been all rainbow hearts. This was a big undertaking for us, full of new challenges that went well beyond the standard delivery stuff like dependency and stakeholder management.
One of the biggest challenges has been coordinating a mix of volunteer and pro bono time. And while nothing beats face-to-face interactions, there are definitely steps you can take to minimise friction and reduce the feedback loop. We had weekly check-ins with our key Pride stakeholders where we could provide delivery updates, review dependencies and progress. To counter slow responses and stilted communication, we focused more on documenting and breaking features up into the smallest chunks possible, more so than on a standard, co-located team. Communication has been key, as has patience.
Like any other project, this app had a hard deadline. But forecasting without a stable team has been a real challenge. Instead of using average throughput I tracked to key milestones and target throughput. That way, if we were looking way off a milestone or the target throughput, I could see immediately and alarm bells would ring.
It was a great data-driven discussion starter that I could use to bring up scope with our Pride stakeholders, and resourcing internally.
Another learning for us has been that we need to take volunteer commitment with a big pinch salt. Of the people that commited time way back in December, less than half have actually delivered on that commitment, many for good reason. Sickness, stressful, tiring projects and family commitments are some of the common reasons why some people just weren’t able to give the time they thought they could.
Having a small pool of volunteers has also meant a very real risk of burnout. By tracking everyone’s voluntary hours (here at Red Badger we provide compensation for voluntary work on open source and social value projects) I had a good indication if someone was putting in too much time.
We did a number of things to try and mitigate this risk; expanding the pool of volunteers, reducing the scope as much as we could, and negotiating some project holidays for some of the key engineers. The latter was the most costly and as a result very much a last resort, but it was also the most effective.
As a successful project which has showcased all of our skills as a cross-functional, full-service consultancy, from branding, UX, design and development right through to QA, the impact of building this app has been immense. With the freedoms bestowed on us by Pride in London to lead the visual identity of the app and choose our tech and tooling, we’ve had the opportunity to see what we can do in a world without constraints. We’ve also learnt to use new technologies that we’re now using with our clients. It’s been such a positive, productive experience for us that we are figuring out how we can take on more projects like this in the future without relying heavily on volunteer effort.
The future of social value at Red Badger is looking not only bright, but sustainable. And, of course, covered in rainbows.
Find out more about the project here.
This blog article was first published on red-badger.com/blog