Our company was born during a hackathon 2+ years ago. It wasn't a service provider like it is today, but it was something to believe in. We were a team of four with bravery and courage to build something we wanted to show to others. Our greatest reward: a product being used.
Since the beginning we have embraced the hackathon culture to encourage team building, to learn new tools and to find awesome team members to be part of our family. Thanks to this culture we have met many of the icaliers, enabling a work dynamic that recognizes the potential of each individual.
Before starting with the main point of this post, I need to share our experience in numbers. We have been part of at least 8 hackathons, and some of us have organized, judged and mentored at least 20 more hackathons. Some of our victories have been:
- Hackathon Mty III: 1st place.
- Open Data MX Hackathon: 1st place.
- DAL 2012 Mexico City: 1st place and a company released.
- Startup Weekend MTY II: 2nd place (we transformed this event into a hackathon for us :] ).
- PayPal's Battlehack Mexico City: 3rd place out of 34.
- Angel Hack Monterrey: 4th place out of 30.
We though it was important to share the process we followed to achieve all of these wins after our participation in the Battlehack, in Mexico City. Our team in all of these hackathons was made out of at least 70% of icalier memebers, so the following practices were involved for sure.
1. Define your idea with anticipation
Many times we have seen teams discussing ideas at the beginning of hackathons. This is a waste of time. The hackathon is set up to hack, design, build and code, but not to chit chat about what idea would be the right one. Sometimes we have arranged roadtrips to the cities hosting hackathons, and those have been very helpful. We have a minimum of 1 to 2 sessions previously to the hackathon in order to define the right idea. If many ideas are shared between the team, we suggest to select the right one based on different criteria:
- Feasability of technology to implement.
- Communities and content generation vs. product ready to be used.
- Idea following the rules.
- Team approves.
- Something people is going to use.
In the end, we choose the idea that fits in all previous points, or at least the one that does it the most.
2. Follow an agile procedure
Management is an important element to scope efforts and to build something usable and useful at the end of the day. We have taken some agile practices particularly from scrum and translated them to the hackathon context in order to constantly prioritaize. Time is the biggest asset we have as human beings and during a hackathon, so prioritizing the features and functionality to include during the event is very important.
A block of time between 5 and 8 hours is called a sprint. There should be around 3 to 5 sprints, depending on the hours available for the hackathon. Each of those include a set of features and tasks to be completed within its scope of time. For example, a hackathon of 24 hours will have 3 sprints of 8 hours with the most important tasks on the first sprint, and the least important tasks on the last sprint. Tasks not finished at the end of a sprint should be moved to the next sprint and the least important features start getting excluded from the scope of the hack.
There is someone who needs to own the agile coach role to track the time on every sprint. This person guides the closing sprint sessions where he/she asks for a status of the estimated tasks that need to be done. This person needs to prioritize features and demands discipline from the team members.
3. Choose your team wisely
Technology teams need to be balanced. Depending on the hack you are building you will need to choose the right team members. Nevertheless, there's always a pattern that works for everything you are working on: Hackers + Designers.
When I say hackers, I'm talking about people with knowledge in back-end development and in all the features that are going to be built. When I say designers, I'm talking about design and front-end coders: people who are going to show the hack to the world in terms of presentation, emotions and in a humanized way. Forget about the hustlers, marketers or any other role. You are coding in a hackathon. Of course, you will need somebody that will pitch and talk to people, who will probably be getting out of the building for this. This can be done by anyone of these two parties.
An A-team is balanced with hackers and designers.
Unless we are talking about a 24-hour hackathon, sleep is one of the key factors to keep building the product with energy, determination and logic decisions. Every team member must take time to sleep properly in order to refill energy and make every effort count at the end of the hackathon. Don't be mistaken, no sleep doesn't mean more features.
Here is a graph explaining what happens when a team doesn't sleep at all:
The blue line represents a team who sleeps from T(5) to T(9), which allowed them to develop more features compared to the red line, representing a non-sleeping team.
5. Consider the rules and judges
There are always rules to follow and judges to convince. Understand the dynamic of the hackathon; what is the main technology to be used? What is the goal for the teams? Remember and stick to it. Also, do some research about the judges' profiles and find out what would they want to hear. Impress them with the right words. If they are mentoring, approach them and perceive their impressions. Let them know you are passionate about your project.
6. The pitch matters
We all know this is a hard part. The hacker stereotype is changing throughout time, nevertheless, standing in front of an audience is hard for anyone. Not only the presenter's diction is important, but also assesing if a mobile product would be more impressive compared to a web product. Sometimes we have decided to present a web project due to the fact that a mobile application cannot be accepted on marketplaces fast enough to be used by the audience during the pitch. This really depends on the idea you are working on.
The pitch matters a lot so you can explain everyone what you did. Let the guy with the loudest voice present. The rest of the team can support the pitcher by performing a live demo, which is a must during the presentation. Be prepared for any bug, crashes or issues, so rehearse a couple of hours before the pitches start.
7. Haters gonna hate, ignore them.
In all hackathons, you will find several trolls, ego hackers and even misanthropists always complaining about other participants or the competition itself. IGNORE THEM. Commit to your project, to your team, and to yourself. Hack for fun, make some friends and ignore the aphatetic.
Prepare as a team, mentalize, hack, build, design, code, learn, share and don't be a jerk.
Update: Octuber 19th, 2014 - 1:07pm CST
Updates in some paragraphs have been done. Thanks to Ever Padilla for the given feedback in grammar and syntax along this post.