Have you ever wondered what a hackathon is? Are you’re attending one and looking for tips and tricks for success? I participated in a hackathon event late last month and in this post you can learn from our mistakes and not make the same ones we did. Part one of a two-part post, this article focuses on how people interact within a group during the event and how you can shape your own group and guide it towards success. The next part will tell a story how we developed the idea that we presented in the event.
The World Wildlife Fund wanted a mobile application to support their upcoming Earth Hour event and similarly their “I will if you will” environmental awareness campaign. They worked with Newton Circus and UP Singapore and organized an event to crowdsource the idea. In other words, they arranged a contest so that many people will come and contribute their ideas for free. It was framed as a hackathon event that took place in NUS’ U-Town complex at 25-27 January 2013.
Since the dayjob company was one of this event’s sponsors, I volunteered to be a participant. There were five of us from the dayjob company and we took in three additional participants as part of the group. Our team consisted of primarily technical researchers and software developers but the other three participants did not have any software engineering backgrounds.
These are the lessons I learned during the hackathon:
- Lean & mean is still the best.
- Get down to work fast.
- Keep it simple but not simpler.
On Being Lean & Mean
Having a small team is important since it keeps the discussion focused. However each team member need to be both a do-er and a thinker so that they all constantly contributes during their entire process. In this sense, a do-er is some kind of hands-on skills but not necessarily programming skills – mainly graphics design, writing, organizing thoughts – in general skills that produces immediate results. Strange enough, there wasn’t much time to do some actual programming during the event, but nonetheless application design skills will come in handy. Finally pure managers with no technical skills but only armed with extensive NATO (No Action, Talk Only) politician’s skillset won’t be much useful.
Our group has plenty of room for improvements in this area. Team members got pulled out at various times during the event either because of personal commitments or professional tasks. The dayjob company was one of the sponsors who provided a software to be used during the event and there wasn’t any dedicated technical support crew and hence at time we needed to help the organizers on some technical issues with the software. Note that this was an enterprise software that isn’t generally available for casual tinkering.
Technical issues aside, there weren’t much synergy in the various skillset of the group members. Some members were having difficulties in grasping some of the basics of designing a mobile application – even though there were no programming involved. Basic stuff like understanding the basic concepts of a scrolling list, insight on what various other mobile applications that are available, or even keeping up with the general flow of the group’s discussion. Furthermore there was more than one alpha-person in the group and some of them weren’t much of a do-er at the first half of the time – although close to the end they finally rolled up their sleeves and made worthwhile contributions.
On Getting Down to Work
The effective time available for real work is one day. It will be best if you can fit it in an 8-hour day and not 12-hour day as fatigue will creep in and make you ineffective by the 7th hour. There isn’t much time to go through all the four stages of group development – once your group is formed on Friday night, and have its initial discussion, the group should have completed the norming stage by Saturday morning.
The diagram above shows how it should have happened. As you can see for yourself, the actual work happens in Saturday and there isn’t much time available for the group to warm up – it needs to briskly go through the storming and norming phases and get down to work fast. There need to be several iterations and the team shouldn’t pull an all-nighter for these idea sessions since the creative brain will just grew wary and productivity will go south.
Sadly our group took too much time in the storming and norming phases and did not have enough iterations. A possible cause can be attributed to the lack of insight on how a software product should be designed and what are currently available in the market. Another possible problem points is the presence of more than one dominating personality. Then again the team got distracted because some team members need to take care other commitments outside of the event.
On Keeping It Simple but not Simpler
Don’t throw good ideas away. How do you make sure you’re not throwing out good ideas? By rapid iteration and reviews. You’ll really need to quickly iterate through ideas within the first four hours of Saturday and have it finalized just after lunch time so you can get down to fleshing out the details and have it roughly done within an eight hour day.
Our group went through a rough storming period at the first half of Saturday and there were many ideas generated but made through only one iteration. When we finally taken a step back to take a birds’ eye view of the idea, feature-set, and flow of the application, we realized that it was an incoherent set of features and then threw most of it away. This was done when almost half of the group members checked out and went home. But in hindsight there was one good feature that we had but threw away. Why we realized the feature was a good idea? Because the winning proposal has that feature (stay tuned and I’ll describe more on the idea on the next post).
The hackathon event was interesting if you have a weekend to spare and you’d like to try your hand working in focus groups. In retrospect, the dynamics were pretty similar to what happened during my MBA in ITB but with a significantly compressed time frame and there was no 3-5 pages of Harvard-published case study to read beforehand. On the other hand it might not be an appropriate venue if you’re looking for (or validating) an idea that you can launch as a solopreneur.