How hack weeks help us build better software.

Aiimi UI Lead & Developer Shaina Koval shares how hack weeks work– and gives an inside look at how they've helped the Aiimi Labs team develop a better software product.

If you’re in tech, or a tech-adjacent industry, you may have heard of a hack week before, or maybe a hackathon, depending on your dialect of tech-speak. It’s something we in the Aiimi Labs team have tried our hands at before but have only recently started to understand how to make it work for us.

What is a Hack Week?

For those not yet in the know, a hack week is a period in which normal roadmap-driven activities are put on pause, and more out-there ideas are given the spotlight. Unlike a Design Sprint, Data Sprint, or Design Dash, a hack week ends with a coded-up proof of concept that has had input from everyone, from UX to data science to developers to QA. It’s a whole-team effort in which everyone gets to flex their strengths and explore new ideas, combining the speedy iteration of a Design Sprint with competition, blue-sky thinking, and teamwork.

Ideally a hack week is run in person, where it’s quick and natural to bounce ideas off your team members throughout the day, but making it work over Zoom is doable with a little extra effort, a dedicated Slack channel, and a Miro board (or whatever your messaging and ideation platforms of choice are).

Why run a Hack Week?

We decided to introduce a hack week in the middle of each of our quarterly releases to give our Aiimi Labs team a break from the pressure of back-to-back sprints and a chance to work with people they might not work with as closely during the normal development cycle. From a business perspective, the hack week is an opportunity to explore new areas for the product that are outside the scope of the roadmap and to quickly test out whether an idea is viable or worthwhile before pouring loads of resources into it.

What we've been working on in Aiimi Labs' Hack Week

Our Q1 2021 Hack Week started with the presentation of five different avenues of exploration. Everyone on the team voted for their choice and, based on the winning topics, we narrowed it down to three different ideas to tackle:

• Outlook Calendar Recommendations
  As a member of staff, I want to be pushed the information that I need, whether it be via email or Slack for upcoming meetings and events in my diary.
• Miro Source Connector
  As a user of Aiimi Insight Engine, I want to be able to surface insights about any information captured in Miro, so that I can easily find workshop outputs and artefacts produced in there, without having to remember exactly which Miro Board to look at, especially when there are so many.
• Test Data Generation
  For Aiimi Labs to be able to performance-test each release of our software, we need to have a suitably sized environment in which to perform sufficient testing. A significant part of that sizing is index size, which is driven by the volume of content we have indexed. We currently estimate that we will need somewhere between 300m-500m documents of varying size and type (docx, xlsx, pdf etc.) with text content that isn’t Lorem Ipsum, isn’t overly gibberish, and can obviously be searched and found.

Each team had their own journey of discovery, research, iteration, and development, adapting tools from Design Sprints and normal development cycles to suit the short time frame and task at hand.

For example, the Outlook Calendar Recommendations team that I was a part of started with a discovery session in Miro, in which we identified technical challenges and mapped out our personas’ wants/needs, pains/gains, and resulting actions, to paint an overview of their journey and struggles. We followed up with a How Might We exercise and generated some solution ideas to answer those questions.

This process helped us identify what functionality we would need to satisfy our users—now we just had to see whether it was feasible! Some of the team went off to do technical research and environment setup, while the creative team members tightened up the user journeys and got to work on low-fidelity wireframes.

Although not identical for all teams, the process during Hack Week was one of research, building, and intense collaboration. Regular team huddles via Zoom and constant Slacking filled in for the in-person interaction that a Hack Week would have depended on in pre-Covid times.

What we learned

In addition to the mental health benefits of taking a break from the usual grind, we reaped a number of benefits from setting aside this time for a hack week.

Thinking out of the box can lead to some new, exciting paths to explore:

• What would it look like if Aiimi Insight Engine could live-suggest recommendations based on an ongoing Slack conversation? Just how far can we take active engagement with users?
• What benefits would we get out of rethinking our current approach to search results?
• Could we use the test data tool to create demo environments representative of potential clients’ systems to help them understand Aiimi Insight Engine in the context of their data ecosystem?

Normally our heads are down, looking at the immediate tasks at hand. Lifting our gaze skyward to whatever possibilities are out there further down the line gives us fresh fuel for the work we’re doing now. I for one have been thinking of new ways to build on the themes of my team’s hack and considering what steps we can do now to prepare for a future where what we hacked can be made a reality.

We don't just use Data Hacks and Design Sprints to develop our own software - we're also experienced facilitators, regularly running hacks and sprints for our customers too! Find out more about our Design Sprints & Data Sprints.