From innovation to business transformation
November 2019
4 common hackathon myths demystified
Hackathons are really popular right now and they are a valuable tool for organisational change as they can foster innovation and a can-do culture.
Having been involved I realised that while many people don’t have first-hand experience of these events, there are some common misconceptions about them. Not all hackathons are the same. ORM have years of experience running hackathons, both internally and for a broad range of clients.
Here are some common misconceptions we’ve encountered.
A hackathon is an exercise in creative problem solving. It’s an intense period of work by a team of multi-skilled people that might include a competition element (and sometimes even prizes) but the purpose is to solve real-life problems.
The hackathon approach to problem-solving is based on agile delivery – a methodology that was developed as an alternative to large waterfall projects that took months, or sometimes years, to deliver working solutions. Instead, agile projects adopt an iterative approach, where smaller, working components of the bigger solutions are delivered in short work cycles called sprints.
Hackathons are rapid prototyping sessions that allow teams to quickly produce working solutions that can be tested by users, adapted and updated before they decide if the product is desirable (by users), viable (for the business) and feasible (to build). The ultimate goal is to deliver a working prototype or solution to a real-life problem, not to win a trophy.
While software developers and interface designers can be invaluable participants in certain instances, not every hackathon is designed to create this kind of product. And, even if you do need to develop a piece of software, it takes a team of people with different input to create a successful tool.
A hackathon team should include four to six people with a broad range of skills and who represent an understanding of:
Without input from the users, people who understand the business and those at the coalface, the “techies” alone wouldn’t be able to create a product that is fit for purpose.
Participating in a hackathon does not necessarily mean packing a sleeping bag and working through the night. Typically, an event can last anything from a few hours to a week, and it’s possible to develop ideas into a working product in a single day.
We recognise that our workdays are full of meetings or bursts of work, meaning we have less opportunity to focus on specific activities. One of the reasons why it’s possible to achieve so much at a hackathon without working through the night is because these events allow people to work together, without the distraction of meetings, phone calls, emails, etc.
In the leadup to the event it’s important for all of the stakeholders to meet and define the business problems that the group aims to address. If the problem is clearly defined, it’s easier to understand and find a solution.
It’s true, hackathons are extremely effective ways to kickstart tech projects because they deliver a working prototype much faster than a typical operational cycle would allow. This makes it much easier to present proposed solutions to senior stakeholders and to get buy-in and approval for building a full working solution.
Hackathons can be used to improve existing products by quickly producing new features and tools for market testing. They are also ideally suited to developing business propositions – if you’ve got a business idea that you want to develop, the right hackathon teams can help you understand what customers are looking for, what’s possible from a technology perspective and what the business case is so that you can develop your business plan. Hackathons can also be used to define new ways of working and solve existing operational problems.
Whatever the purpose of your hackathon, putting people from different disciplines together provides the added benefit of promoting better working relationships and gives people an opportunity to participate in projects that they may otherwise not have been able to.
Learn more about ORM here.
