Hackathons can be fun and engaging activities for your team, as well as incredibly useful for the business of your customers. However, organizing a hackathon is not so straightforward. Organize it at the wrong moment, in the wrong way, or for the wrong reasons and you might find yourself with a demotivated team and no valuable business results.
We compiled this easy hackathon organizing guide, taking you step by step through the decisions you face and the best strategy for making sure that both your team and the customer will have a smile on their faces at the end of it all. This guide is based on some of our recent customer hackathon experiences and it includes real-life examples.
Start with the why
“Hackathon” is a buzzword. It sounds good on a company website, it looks impressive on a customer report. But this is not reason enough to have one.
Hackathons are a great way to boost morale, engage the team in an interesting initiative and let the creativity flow. From the point of view of the customer, this activity might encourage creative development and bring value-adding features to its product or service. It’s a win-win!
Beware, though. If you just do it for the sake of the team, then your customers might not be on board and might not use any of the proof of concepts you showed them. This can prove extremely demotivating for the team and they might not be so excited about another hackathon the second time around. On the contrary, if it is only your customer who pushes for the hackathon, but the team is not enthusiastic, then organizing it will just create added pressure and stress.
Earlier this year, we organized a hackathon for a world-renowned transportation company, right after the first release of the driver app about which you can read more here. It was our customer who proposed that we organize it, with the dual purpose of relaxing the team, after a stressful period and encouraging creative development.
Time it correctly
Great! You have decided that a hackathon is just what you and your customer need… so when should you schedule it? Let’s start with when NOT to schedule it: before a release! As a rule of thumb, it’s best to avoid all the stressful periods during a project timeline. Otherwise, topping tight deadlines and delivery pressure with the obligation to think creatively for two days simply adds stress and is completely unproductive.
You should schedule the hackathon at a time when the team is not in “survival mode”, putting out fires left and right. It may be after a big release, or it may be during a period when you anticipate an ease in the issues that arise. Check the calendars, to make sure nobody is on holiday during that period. Make sure to agree on the timeline with the customer.
You should also leave a significant period of time to pass between the announcement and when the event actually takes place: aim for at least 3-4 months. This in-between time allows new ideas to rise to the surface, issues to brew, and new features to pop up in discussions between teammates or with the customer.
What about the duration? 1 or 2 days is the norm. Peak work and creativity cannot be sustained for long periods of time. Alternatively, if you just allocate a couple of hours for this fun activity, it’s not enough to come up with a useful result.
Collect ideas
If the hackathon is not very rushed, then your team has plenty of time to come up with ideas about what they want to do: maybe new features? A new UI? Implement a new technology? Don’t say no to anything just yet. You’ll do that at a later stage.
Both seniors and juniors can propose ideas. If you have a junior team that has never gone through a hackathon before, they might be uncomfortable proposing new and daring ideas. Don’t force them. The first hackathon will be a learning and calibrating experience, teaching them what to expect on similar occasions, what is feasible, how high can they dream, and how limited they are in implementation. The more senior members can set a good example and come up with ideas to be later presented to the whole team.
The customer might also have some ideas of their own. Maybe they’d like your team to tinkle with a new feature or to creatively solve an issue they noticed.
At this stage, all ideas are welcomed.
To keep track of them, you can do a brainstorming meeting or keep an open list.
Select the ideas
Take a look at that idea list. You will not be able to do all of them. But how to select what to work on?
First, use senior members to refine the list. As they have better exposure, they know what can be done. They have interacted with several frameworks and technologies and they already know if ideas such as a watch app, machine learning, or Siri are something that makes sense to be implemented for that particular project. They should also be more aware of the business value of each idea, keeping in mind that the end result is to add value to the customer’s business or service.
Second, validate the list with the product owner: does the customer have something they really want the team to be working on? Is there something they feel would be a complete waste of time? Third, take a team vote: what do they want to work on?
During one of our hackathons, we let our team members vote and decide who wants to do what. They were over-the-hills excited! Our final work order was a list of 2-3 topics per platform and everyone got their pick. No member of the team was forced to work on a topic they did not want.
Who pays for the hackathon?
Your team will work for several days straight on these ideas, so make sure you clearly know who is financially supporting this. Customer hackathons are usually part of the project management timeline and the project management budget. However, make sure this is very clear for both sides. As the hackathon might cost the customer some money, you might find yourself in the position of having to “sell” this idea to your customer. In this case, your clear “whys” from the first step will be very helpful.
The day of the hackathon
If your list was correctly put together, then everyone will eagerly await the hackathon. According to the list and the team members’ choice, they will normally be split into groups of two or one. A hackathon day is pretty much like an ordinary day, without all the meetings. Just make sure there’s plenty of food and coffee to go around.
End with a demo
This here is one of the hottest tips we can give you about organizing a hackathon: demo, demo, demo. End this intense, fun effort with a presentation. Each topic on your work list should have resulted in a tangible result that could be presented to the whole team and the customer. Have each group and/or person present his or her ideas in an engaging, visual manner for maximum impact on the customer: from new widgets to Siri voice activation — ideas only come to life if they are properly packaged.
Demos are more than simply impressing a customer. They are great tools for stepping into the shoes of the customer and understanding its needs and the business value of that particular feature or idea. More often than not, developers do not think about these criteria when they are working on something or making project decisions. Presenting something to a customer puts things in perspective and allows for a better understanding of the business expectations, needs and issues.
And one more thing: if the team is aware that they will be expected to deliver a demo at the end of the two days, they will go the extra mile.
Sometimes, the customer will ask you to do another demo, at a higher level. The more people in the audience, the better it is for the team.
Such was the case of our most recent hackathon. It ended with not one demo, but with several demos. As the first demo, inside the group, went very well, the Levi9 team was asked to make a demo at KY level.
How to measure success
How do you know if your hackathon was successful? Both parties of the hackathon should be quite pleased. Teams should feel more content with their work, after experiencing the immediate impact and reaction they got from the customer during and after the demo. The customers should be enthusiastic about some of the features that were presented and ask for implementation. Keep in mind that even if you fell in love with one of the new features, the customer still might not choose it: the business value will prevail in the final decision.
More often than not, you will know that your effort was successful once you hear this question from both the members of your team and the customer: “So when will we have another hackathon?”.
