Our First Hackathon
Hackathons are becoming a fairly common method to stimulate innovation at companies, software or otherwise. We recently held our first Hackathon here with the Sage 300 ERP development team. We are adding Hackathons to our Sage Innovation Process as an idea generator and a concept tester.
Probably the most famous recent Hackathons are those held at Facebook which resulted in the Like button, Facebook Chat and the Timeline feature. If you Google Facebook Hackatons on YouTube, you can find all sorts of videos showing these. In fact Hackathons are being conducted in industries outside of software development in things like government and food production.
The key goal of Hackathons is to stimulate the creative juices in the organization. To get ideas flowing, to provide a platform to quickly develop them, to show them off and then possibly productize them. In some sense you would like to have everyone creative and innovative all the time, but the pressures of day to day tasks usually damper such things.
Hackathons also give programmers a chance to do projects they’ve always wanted to do and felt were important, but couldn’t convince Product Management to prioritize high enough to get done.
We decided to have a two day Hackathon. We had a kick-off meeting just before lunch on Wednesday and then the teams had two days to hack. We then had a results presentation just after lunch on Friday. Some people formed small teams, others worked solo. Basically the two days were up to them. We then provided snacks and lunch on Thursday.
Facebook runs their Hackathons for 24 hours and people don’t sleep. We thought that too extreme. Although some people worked quite long hours getting their hacks to work, no one missed a night’s sleep. Our feeling is that sleep deprivation doesn’t help and is in fact quite destructive. Often a good night’s sleep is what you need to solve difficult problems.
When we were initially planning the Hackathon, we were worried that people wouldn’t participate because they would have trouble coming up with ideas of what to do. So to try to alleviate this, we came up with a list of suggestions for people.
What we found instead was that this wasn’t a problem at all. We had really good participation and none of our original ideas were used. All teams either had a brain storming session to start with, or had their own ideas that they had been thinking about and just needed an opportunity to explore them.
One key is to give plenty of warning of an upcoming Hackathon, so people can have plenty of time to come up with ideas, and to network with their peers to develop teams.
The results of the Hackathon greatly exceeded our expectations. All the teams, except for one that had to deal with an emergency issue, were able to demonstrate useful and exciting results.
The projects were very diverse including:
- testing out a new automated test tool
- evaluating running static code analysis tools on our code
- developing a new customer information connected service
- created a better tool to create knowledge base articles
- created a direct to customer advertising feature
- added a key CRM integration feature
- adding Skype and Google Maps integration
- fixing some long standing annoyances that never made the priority list.
Below is a picture of the winning team, that hacked in a number of useful social media integrations to the Sage 300 ERP product, including a rating system for things like customers (similar to Amazon ratings), integrations to Skype, Google Maps and a number of other things.
We insisted that each group write up their results. We wanted to document all learning’s. We want to know things tried that didn’t work out as well as successes. We did this via a page on our internal development Wiki. This is a very important part of Hackathons since you want to build on everything accomplished.
Our summary presentations went a bit long because everyone was so excited to show so much; however, we decided that next time we will limit each presentation to 5 minutes, since the whole presentation went quite long.
The idea of giving awards turned out to be quite controversial. We had a best project award and a better luck next time award. Everyone felt we should get rid of the better luck next time award. Some people like the idea of having a “winner”, others felt that it corrupted the hackathon process by motivating people to produce visual fluff over perhaps more technical work.
The idea of the “better luck necessary” award was to celebrate failure, since we want to motivate people to take risks and not be too conservative. However people seemed to think this wasn’t a great idea since a couple of “failures” were actually considered successes since they provided proof that a couple of popular technologies weren’t really ready for prime time.
The two day time frame seemed to work quite well for our staff. No one wanted to switch to the 24 hour no sleep method. Then the consensus was that we should try to repeat the Hackathon every 2 to 3 months. It makes no sense to only do a Hackathon once, you really need to keep doing them regularly to exercise your innovation muscles or they will just atrophy again.
Hackathons are a great way to stimulate innovation in an organization. Not only do you generate a lot of ideas, but you often pick off some low hanging fruit. Or you have a POC (proof of concept) to prove out an idea to productize. Hackathons have been used successfully at many companies in many industries and our own experience was very positive.