Recently, I had the interesting challenge of planning for a one day hack-a-thon. The event was limited to a single business day, giving us only 8 hours to hack. Below, I shall give some advice on how to plan, execute, and wrap up a one-day hack-a-thon. Hopefully some of this advice can also be used to plan hack-a-thons of larger scope.
Let Hackers Hack
This one may be kind of obvious, but why do people want to participate in a hack-a-thon? To hack on cool ideas! This means your job is to ensure as little interference as possible and let programmers do what they do best. In our case, this meant having brainstorming sessions before the hack-a-thon even started. We ideated on our topics and split up into teams before the date in question. This allowed us to focus our efforts into actually building something when the day came.
It is easy to get lost in the labyrinth of project set-up. Making sure the kanban board is up and running. How about CI? A code reviewing process? All these things are important for the project lifeline; however, I would suggest trying to get as much as possible set up before the hack-a-thon starts. I firmly believe that the most fun arises in these situations when people can just work on an idea they feel passionate about and not get muddled down by setting up a healthy project.
In summary, try to get as much project maintenance and kick up tasks done prior to the start of the hack-a-thon.
To help us keep to the required time limit, I used one of our weekly meetings to plan out ideas, and divide the company into teams for the hack-a-thon. The only “homework” assigned to participants was to come into the meeting with an idea or two in mind.
As meeting leader, I find the most important task is to listen, and provide a floor open for ideas. Whiteboard at the ready, I opened the floor and allowed people to go around the room, presenting ideas they thought would be good to hack on. The meeting progressed naturally from there, as I wrote down ideas, what people seemed to gravitate to almost came naturally. The only real issue was trying to keep this meeting within the time limit of one hour. Time seems to dilate whenever people talk about ideas they are passionate about.
In this case, the session lasted the whole hour, so I set up an online poll to divide the company into teams and choose the winning ideas. At the end of the day, the two winning ideas were presented. Teams followed suit, and it so happened that we had a pretty even split without much hassle. From the ideating session, this seemed like it would be the case just based on who was passionate about what.
The proponents of the ideas became their project leaders and were in charged with ensuring proper task delegation when the day in question came about.
I think it is important for teammates to have goals. Often time in these short-burst hacking sessions the goals can be lofty. I am not going to sit here and hamper down on setting realistic goals. I say, shoot for the stars!
Morning of, gather the team around and ask the team leaders for milestones. Get two to three concrete milestones. Milestones can take many shapes and sizes, but essentially you want something for the team to aspire to. It can be certain parts of the app being functional, having a whole input/output flow setup, working design etc. Gather these milestones in a list that will be used to make sure people are on track at half time, and see how reality compares to them when the hack-a-thon is over.
Let the Hack-a-thon Begin
At the end of gathering milestones, time to get ready and hack!
Half-time Check Up
It’s important to make sure people are keeping their goals in front and adjust goals accordingly. It is easy to go down into rabbit holes where not much is being gained. This is why setting up a check in at half time is important. It allows for teams to vent any frustrations, and adjust course if needed.
We found that our milestones were definitely very lofty and adjusted our expectations accordingly. Keep the old milestones around though! They are important if you hope to work on your product/app outside of the confines of the hack-a-thon.
This also lets the teams get together and talk about how they are faring which is important as well.
Have a Retrospective & Demo
At the end, it is time to have a retrospective and demo. Start with the fun, and let the teams demo what they have. This is always a great moment of pride and should be celebrated since a group of people have successfully created something where once there was nothing. Has a Prometheus like ring to it, doesn’t it?
Follow this up with a retrospective. Each organization has their own way to run retrospectives, and that could be its own blog post entirely. Just remember, use this as a time to think about what has happened, and take important notes away from the hack-a-thon. Action items are always an important part of any retrospective. This is also a great time for reflection on how processes can be improved in the future so your hack-a-thons can keep on getting better.
This hack-a-thon didn’t have any sort of concrete theme, but I do think a theme of sorts is helpful for any kind of hacking session. It provides a tent pole for ideas to gravitate around and tends to bring people out of their comfort zones.
I also believe one of the great things about hack-a-thons and/or game jams is the rapid learning that goes on, so I would suggest challenging yourself and reaching out to try something new. I chose my team because I had no idea how to help build the product but had an eagerness in learning more about machine learning. It took a while for me to get spun up, but I was surprised how fast I started making meaningful contributions.
Finally, have fun and enjoy!