How to Hackathon: An Ad Hoc Method with Design Sprints
If you’ve ever worked with data, you know it’s messy.
While it can be messy, data is also extremely integral to what we do here at Niche. Data is our fuel, product and purpose in the sense that it allows Niche to connect others with places to live, work, and go to school. So how do we reconcile this messy data with our user-friendly interface that is Niche.com?
Well the short answer, is we clean it. The longer answer, is that we conduct an entire process for this. This process is appropriately, but not affectionately, named the Monthly Data Update (MDU).
Stay tuned to discover how we used a hackathon approach to increase the efficiency of this cumbersome process, create a number of user-friendly internal tools, and improve cross functional communication in just one week.
A Hackathon in the Making
Before diving into the hackathon, let’s first talk about what’s currently happening at Niche’s office. As a small, fast growing tech company, Niche has recently found the need for a full-time technical project manager to better manage our processes and workflow.
When Courtney Thomas was hired for this position back in May of 2018 she observed the current processes and started tackling head-on, our most challenging pain points. A hackathon was starting to form!
Let’s hear from Courtney, herself.
So Courtney, where did the hackathon idea come from?
“I approached our CTO, Geoff Misek, about reading a book together from Google Ventures called SPRINT. We reconvened a week later and concluded that it could be an interesting tool to use strategically and wanted to focus on a specific challenge Tech was facing”
Interesting, so what happened next?
“We pinpointed the Monthly Data Update processes as our target. With a few additional discussions with the Tech team managers, they suggested renaming it to encourage people to join the endeavor. And with that, the MDU Hackathon was born.”
The MDU
So, what exactly is this MDU thing? The MDU is a process for updating our data on a monthly basis. It starts with the Data team, who are tasked with importing, cleaning, and adding data updates into our various databases. Generally speaking, the data comes in its raw form and is moved into the Data team’s source of truth databases. These sources of truth are utilized in moving the data to the development databases, then to the staging databases, and finally the data is moved into the production databases.
Sounds simple enough, right? It’s actually not.
The data also has to be approved by our Quality Assurance team, be aligned with our Infrastructure team, and moved on site where all our awesome users can find this data and make informed life decisions. There are quite a few moving parts in the MDU process and here at Niche, we want to get it right.
We place importance on maintaining reliable and accurate data that you can trust. And as a tech company that values constant improvement, we also want to provide these updates as efficiently as possible. This is where the hackathon comes into play.
Geoff explained how in order to begin resolving our MDU process,
“We needed to map out the problem, identify the pain points, and bring in the rest of the team to help build solutions. All of that takes a lot of focused time and energy, which isn’t usually available in our normal day-to-day. The hackathon was a great way to get the key stakeholders into one room, with no meetings or distractions, and really focus on alleviating a major pain point.”
Time to SPRINT
It was decided. As a necessary (but time consuming) process the MDU was the perfect candidate for implementing the kind of process innovation outlined in SPRINT. Here’s SPRINT in a nutshell:
SPRINT defines a Design Sprint as a structured, 5-day process tackling a larger problem facing your company, and follows this outline:
- Monday: Map the problem
- Tuesday: Sketch solutions
- Wednesday: Choose a target
- Thursday: Prototype
- Friday: Test and learn
Courtney, how did we modify this process to meet our specific needs?
Instead of mapping one problem in an hour, we spent two days mapping out nearly every single MDU-related process. Instead of conducting interviews during the week, we held two pre-interviews the week prior to gather descriptions of relevant pain points. Instead of prototyping a facade, we endeavored to develop real tools that could be integrated with appropriate tweaking and testing.”
What Went Down at the Hackathon
The actual week of the hackathon had a core, focused group of people at the company involved, being those that hold key roles in the MDU process.
The Mapping
As the Design Sprint facilitator, Courtney walked the group through the first step of the hackathon: the mapping of the MDU process. As a smaller company, we were also fortunate to have Geoff (our CTO), present for additional insight. He described how,
“One of the challenges at a small, fast-paced company is that people often have many responsibilities across multiple projects. When you’re constantly shifting your focus, it’s hard to find time to build automation around manual, but well-understood processes. Over time, those manual processes can accumulate until they become a large, painful process, as in the case of our monthly data updates.”
We needed to break the MDU down into smaller pieces, but first, the team had to identify key problem areas and goals. These were written on large sheets of krafting paper, which we also used for outlining the MDU process.
Some of the key problem areas and goals identified were:
Next, the MDU was broken down into parts, with each part being mapped vertically. I should also point out that sticky notes, stickers, and Sharpies were important to our Design Sprint. Yes, really.
Sticky notes were used as a tool to physically place, and remove if needed, the tasks included in each part of the process. Each team involved also chose a unique Sharpie color for their tasks, in order to further identify ownership. In between these sticky notes, arrows were drawn to visualize the direction of those tasks.
By the time we had finished mapping, each part of the MDU process had its own group of sticky notes with a header and was designed to be read vertically. The exception to this were those parts of the MDU process that had an overlapping task flow and didn’t need to be laid out separately. These instances were represented with colored stickers.
In doing this, the value of the Design Sprint was already evident.
Michael Scotto, Niche’s Director of Quality Assurance noted that even after being a primary MDU driver and a subject matter expert on this process for years, there were still parts of the data team’s process that he learned about through mapping each team’s flow of tasks.
Laura Fetch, Niche’s Manager of Data Analysis also felt there was value because of a key point: It allowed her to give full attention to the MDU process improvements. She commented that:
“Setting aside time was very useful because it helped focus our attention on the process. In a normal day there is a lot of context switching between projects. For this hackathon, we didn’t have meetings, access to Slack or emails.”
What Should We Fix?
Now that the mapping had been completed, the group discussed their top ten pain points, which were eventually whittled down to just three. By selecting just three paint points, the hackathon was better narrowed and focused.
These pain points were:
- Time spent on the task by Data & QA [Blue]
- Difficult to train others [Pink]
- Dependencies-Tasks heavily relied on by other tasks [Orange]
Next, these final pain points were assigned smaller, colored sticky notes which were then placed on the the larger sticky notes, or tasks. Once the colored sticky notes had been placed, the group looked for the areas in our layout that had received the most colored sticky notes.
Aha!
This effort of placing the sticky notes demonstrated to us the areas of the MDU that had the most need for improvement. Going forward, these areas were utilized to provide guidance to our Back-End, Front-End, and Infrastructure teams in the improvements they should look to implement.
Here the areas that received the most colored sticky notes:
- The use of a 3rd Party Tool as a collection method for new K-12 schools
- The QA team’s Proliferation Process
- The QA team’s Deployment Process
This wrapped up the mapping portion of the Design Sprint and made possible for the next step, sketching solutions.
The Sketching
When the Back-End, Front-End, and Infrastructure teams were brought in, everyone involved in the mapping and sketching of the MDU discussed the feasibility of each project, how we could scale things to be deliverable by the end of the week, and what (if any) tech debt these projects would introduce.
Out of the brainstorming and discussion, came the following actionable items:
- Rethink the 3rd Party Data Collection Tool
Remove reliance on an external forms vendor for collecting user information by creating an on-site alternative and improves the data import and cleaning.
- Create a SQL Script Runner Tool
Automate the execution of hundreds of SQL scripts for data verification, in order to aid the QA team’s Proliferation Process.
- Improve Testing in the Development Environment
Automate the process that brings up the testing environment during the QA team’s Deployment Process.
Now that the deliverables were outlined, the Back-End, Front-End, and Infrastructure teams collaborated to accomplish these goals for the remainder of the Design Sprint week. Languages utilized were JavaScript by our Front-End team and Go by our Back-End team.
In just a few short days, these teams had impressively come up with improved solutions for all three of the bottleneck areas that had been mapped earlier in the Design Sprint. At this point, the key stakeholders and those involved in building these prototypes met to preview the tools built and establish additional implementation needs.
Also, the team conducted a mini retro (a look back at the entire Design Sprint) to understand its benefits and pinpoint potential modifications that would be useful for any future Design Sprint hackathons.
So, Was it Actually Helpful?
Absolutely! But let’s talk to some of the key stakeholders to see exactly how the Design Sprint hackathon was a useful process improvement method.
Michael Scotto, Director of Quality Assurance
“I gained time to really focus on the MDU exclusively, and also the tools the back-enders developed. The time allowed me to devote myself to documentation and increase transparency, and the tools will save time every month going forward.”
Vivan Shah, Manager of Back-End Engineering
“The SQL script runner tool was built to be relatively generic — it takes a folder of SQL scripts and executes them concurrently against a specified database. It includes counts and rows (if any) that the report generates. It also allows anyone in the company to utilize it to automate the execution of multiple scripts.”
Melissa Wang, Product Manager
“I think the way we prioritized our problems really enabled the group to brainstorm together. Having a list of all the problems/goals we could be working towards and allowing the stakeholders to prioritize independently did a lot to drive the discussion.”
Key Takeaways
As a whole, we found there were great benefits from holding our first Design Sprint hackathon at Niche.
Vivan explained how the tools generated were huge successes for our team, not only because they were time savers, but also because the on-site survey was an important improvement for our branding and client interaction. When a Niche user goes to submit a new K-12 school, they can now have their initial interaction be with the Niche platform, instead of being redirected elsewhere.
Another important takeaway identified was the ability to focus in on this specific issue by stepping away from piles of emails and meetings in order to better communicate cross-functionally. This cross-functional communication resulted in another hackathon takeaway; the added transparency of the MDU process.
Whether a Niche team member had no knowledge or expert knowledge of the process prior to the hackathon, everyone involved gained improved insight into how we can refine what we are currently doing as a team. Recognizing how valuable this insight can be for process improvement, Melissa added,
“I don’t think it can be overstated how helpful context is for any problem or process improvement even if the benefits aren’t obvious in the moment. Having a time set aside for teams to really collaborate is a great way to set us up for more transparent cross-functional communication in the future.”
What’s Next?
There is still room for improvement with our MDU process, so we anticipate more of this type of brainstorming and process-improvement in our future.
With our hackathon completed, we’ve achieved a new way of approaching difficult solutions through Google Venture’s SPRINT, and are confident that any future hackathon will result in even more gains for our team!
And if you would like to check out where our data comes from, click here.
