Boxfusion’s development team was tasked with helping the Gauteng Health Department manage mass-screenings of South Africa’s COVID-19 cases. Despite extreme time pressure and uncertainty, their team managed to ship the first version of a working solution over a weekend. Managing Director, Ian Houvet, shares how his team used one-to-one customer research, quick feedback loops, and complexity minimisation in order to follow an MVP approach and work effectively during extraordinary conditions.
Boxfusion uses technical solutions to improve governmental systems, by digitising existing processes and improving the efficiency of government operations. When COVID-19 hit South Africa, the National Institute for Communicable Diseases (NICD) and Gauteng Health Department (GHD) needed to ramp up their viral screenings in order to monitor and track the spread of the virus. This included things from initial testing and contact tracing, all the way to monitoring recovery of infected patients.
“To be honest, the original brief was very undefined”, Ian explains. At the beginning of the project, no one could predict how complicated the problem would be. “It all evolved so quickly, and nobody knew exactly what it was we were meant to do.”
“We had to rethink some of our systems, because all they knew was that there were going to be many problems that needed to be solved, and that building systems would help us solve them in a scalable way. It was a very unique, and interesting problem for us to work on.”
To add to that challenge, time was an extremely limited resource, and there was no clear direction for what would ‘work’. This meant that everything became a priority: “It’s normally the job of the client to point out the fires and tell us what’s burning.” In a time of crisis, though, Ian says that, when everything is burning, it’s incredibly difficult to figure out what’s just ‘noise’ and what’s a priority that needs solving: “There were so many opinions on things; in that environment, everybody's in disaster management mode and everyone's running around frantically.”
Ian’s team had to be really selective about what they worked on first, so that they weren’t overwhelmed with things to do and actually made real progress on the stuff that mattered.
A few strategies in particular helped Ian’s team manage these constraints, namely:
- One-on-one customer research
- Quick feedback loops
- Complexity minimisation
Here they are in more detail:
One-on-one customer research
When dealing with so many stakeholders, all with their own ideas of what should be done first, Ian said that they needed to find one person, and get a detailed view of the system from start to finish. “We just said, ‘You know what, that guy over there looks like he knows what he's talking about, and the one that people are gravitating towards for guidance. We had to make that leap, or else we were going to endlessly try to follow whoever's shouting the loudest.” Picking someone they could treat as a customer meant Ian’s team could filter out the noise, figure out what the user of their solution needed it to do, and prioritise.
In order to make this effective, Ian’s team needed to ask the right questions and get as much detail as they could, as fast as they could. “We mapped out as much as we could for the end-to-end process with the customer, letting them give us a baseline that we could work from later.”
The kinds of questions his team asked were aligned to figuring out what happens at each and every step of the process – for example, contact tracing – and what the current blockers were. They included:
- From the time a positive case has been identified, what happens?
- How does this thing / system / process operate?
- Who needs to be able to do what with it?
- What do you expect from the system to help you do this more efficiently, and at scale?
- And then, what happens next?
This enabled Ian’s team to have a clearer understanding of the problems at hand, and which solutions needed to be built first.
Quick feedback loops
With such a novel problem, and having a lot of things that were burning and ‘important’, Ian says his team needed to make sure they shortened the time it took to get feedback. The only way they could tell if they were building the right things was for someone to use it and give them feedback.
“When you have such a limited understanding of the total problem space, and everything's moving so quickly, the only real way you can hope to solve a problem is to put something out quickly, and let your users tell you.”
This meant following an MVP approach, and sticking to Agile methodology as much as possible. “The key is that it doesn't have to be perfect, and it doesn't have to solve everything from day one”, Ian says. Instead, his team opted to build solutions out in smaller chunks and put them out ‘into the wild’, rather than build larger-scale technical solutions, so that they could iterate and improve faster.
Pro-tip: To make MVPs effective, Ian says it helps to find out what your baseline is, and work in increments from there. “People sometimes have a tendency to want a Rolls Royce... You barely have a bicycle, so let’s start by building a bicycle with suspension. That’s your baseline.” With their PPE management system, the baseline they had was spreadsheets. They needed to consolidate hundreds of spreadsheets into one view. “For version one, all we had to do was improve on that baseline, and that was a good enough MVP.”
Complexity minimisation
As far as possible, Ian and his team tried to keep complexity to a minimum. In a sector like the government, where many systems are still old, manual and ‘legacy’, complex development tends to take longer to be implemented. “Especially in an environment like the government”, Ian explains, “there's still a lot of skepticism around technology as an end-to-end solution.” As a result, his team opted for simplicity wherever possible in order to enable more buy-in from governmental stakeholders, faster development, and the building of solutions that users could implement without extra training or heavy integration.
In their case, Google Sheets kept their data in a commonly understood, ‘raw’ format, as opposed to requiring a ton of data conversion as it moves from point to point in their systems.
“I love spreadsheets. It's the succinctness of it. You just get crisp information without all the ‘fluff’ around it. As a developer, you want to get straight to the essence of what you need, and I tend to find spreadsheets are a much more succinct way of communicating the critical information.”
Spreadsheets helped Ian’s team adjust their data, their solutions, and their specs: “As your understanding of the problem evolves, you need to update this, add an entity there, change the list of requirements there... And I find spreadsheets are succinct, and quick to manipulate and update.”
Furthermore, Ian’s team used spreadsheet templates as a communication enabler between their planning and their development teams: “If you can define templates upfront for those key design artefacts – like the domain, or the various UI elements required – then it becomes a super effective tool for communicating requirements to the devs. They have the raw information to operate on, and they can execute super quickly.”
With these three strategies, Ian’s team was better equipped to mitigate the specific challenges of the project at hand. It’s an ongoing learning process, but these tactics helped their development move faster, iterate more effectively, and better know what priority was a key priority, and which priority was just ‘noise.’
The above system was built on top of an existing app Boxfusion worked on called Mpilo, which you can read more about here.