Hackathon Cat Herding
Align your team, finish strong, preserve your sanity.
If you enjoy spending your weekends at hackathons as much as I do, you’ve probably noticed that some teams have fun and accomplish a lot while other teams get frustrated with each other and have nothing to show at the end of the weekend.
After attending several hackathons, I noticed that successful teams have the right people, the right focus, and just enough structure.
I recently had an opportunity to apply some of my observations at the Jumpstart LA Hackathon and would like to share what I learned with you while working on the MoveIt! project.
Pick the right people
Making useful and interesting software requires a coordinated effort. Your hackathon team needs to have all the necessary skills to build what you have in mind, but the team can’t be too large.
Starting with a core team of a product designer and a mobile engineer, we recruited three more friends with engineering, graphic design and UX skills before the event and added one more person with engineering skills during the event. We chose people who had tangible skills to contribute and also wanted to learn new things. We also selected for people who were able to collaborate and communicate well.
Get to know each other
A hackathon can be pretty intense and can bring out the best (or worst!) in people. A team is more resilient when the participants respect and trust each other. Spend some time before the event getting to know each other.
Because each of us only knew a couple other people in the group when we started, we shared our LinkedIn profiles and answered some “get to know you” questions in a Google doc before the event.
JumpStart LA Team Introductions
- what is your experience with hackathons?
- what skills do you want to use at the hackathon?
- what kind of project would be fun to work on for a weekend?
- what other skills might we want to add to our team?
We also set up an email alias and had a meeting via Google Hangouts the night before the event so we could get to know each other and narrow down the ideas we wanted to work on.
Share goals
People attend a hackathon for different reasons. Some people want to launch a startup and expect to continue work after the event. Others want to try out a new skill or create work for their portfolio and don’t expect the commitment to last beyond the weekend. Be sure to share your goals with each other and make sure they are compatible.
During our introduction call, we each shared our personal goals for the weekend and created a list that we agreed on. It was helpful to refer to our team goals when we were tempted to get too serious about the event.
Our Team Goals
- learn something new
- make something we can show at the end (shipit!)
- no one leaves mad
Align the product vision
When a hackathon team isn’t aligned about what they are doing, they argue about priorities and might even split into factions to work on rival ideas. A little time spent considering options and coming to consensus as a team will pay off in group productivity, harmony and satisfaction.
From the start, our team agreed that it was important that we agree to work on the same thing. None of us were particularly attached to the ideas we suggested. We used a democratic process to discuss our ideas and vote for the ones we wanted to start with. During the event, our first idea failed quickly, so we picked another and kept going. As our ideas evolved, we made time to pause, re-align and agree on what we were making.
Work in short cycles
Another hackathon failure I see is when a team goes “heads down” to work for hours without a clear idea of what everyone is doing and doesn’t set a time when people will get back together to review each other’s work. It may give the illusion that you’re working hard and getting a lot done, but if you’re not checking in with each other (and merging your code frequently) your work may be wasted.
At our hackathon, we worked in short cycles and used time boxes to help us fail fast. This allowed us to work independently and be closely aligned.
Short cycles: On the first day the designers created storyboards and UI screen sketches while the developers set up their dev environments and tested technical capabilities. We did three rounds of parallel design and development “spikes” on the first day before we found an idea that felt viable to the team. The second day, we re-organized into front and back end teams and continued working in parallel with frequent code merges and demos to each other.
Time boxes: At the start of each cycle, we’d agree on the length of time (time box) we’d work before getting back together to show our work to each other. We wrote the time down in a visible place and set a timer to keep ourselves honest.
Fail fast: At the end of each cycle, we’d show our work, talk about it and decide if we would continue or abandon that direction. Each time we failed, we took a moment to rejoice with a loud “Fail!” which made us all laugh (and feel a little better).
Focus on a complete experience
How many times have you seen a hackathon team stand up to do a demo, show one feature and then wistfully describe all the other cool things the product would have done, if they didn’t run out of time?
Focus on the key experience of the product and deliver thin but complete functionality. Your demo will show off your idea better and you can get more genuine feedback from users.
By the end of the first day, our design and development spikes gave us a solid idea of what we wanted to create together. We had confidence in what it should do, how it should behave and how we could make it.
We documented our understanding with a storyboard, sketches of a few key screens and states and a user scenario. I call this technique “trailing documentation” because the artifacts you create document decisions the team made together.
Lead with conversation, trail with documentation. Low-fidelity “sketchy” designs are sufficient when the design lives in the heads of the whole team.
MoveIt! Scenario
Susan knows she needs to walk more but has a problem with motivation. At the end of the day, she often binge-watches movies on Netflx and then feels bad about herself. MoveIt! is an iPhone app that helps reinforce Susan’s resolve by locking her out of Netflix until she’s walked her daily step goal.
- When Susan sets a step goal in MoveIt! she’s locked out of Netflix on all her devices.
- If she tries to get to Netflix, on any of her devices she is redirected to a page that encourages her to walk instead.
- Susan can view her step progress in real time.
- When she reaches her goal, Susan is notified and Netflix is unlocked. She can access Netflix from MoveIt! and her other devices.
Throughout the weekend, we maintained a dialog with each other to figure out how rich each feature could be. We committed to deliver functionality across the entire experience first, then make it better as we had time. For example, we wanted to use a progress circle to show step progress, but writing a custom UI element was going to be take too long and block us from developing other necessary functionality. We decided that we could prove the value of the feature using a basic UI element (a progress bar). Later we found an open-source progress circle widget and integrated it into the UI when we had some spare cycles.
Pair designers and developers
At hackathons, I’ve seen designers who wanted to participate, but were blocked because they didn’t have the development environment on their computers and developers didn’t know how to engage them.
Most of the people on the MoveIt! team had not built a mobile application before and didn’t know the iOS programming environment. One person in our front end team had more development experience and volunteered to set up Interface Builder and pair with others to translate the sketched concept into the application views. Everyone was able to contribute, learn and we moved really fast.
:shipit:
We finished in time to create a slide deck and practice our demo a few times. Here’s a video of our presentation to the JumpStart LA participants.
Considering how much we got done in a weekend and how good the process felt, I want to bring more of these ideas into my weekday projects.
After this experience, I’m inspired to surface and align our team’s personal goals, focus on the product’s key experience, work in shorter cycles and shipit! frequently.
cat photo: Merlijn Hoek
