Or “Why Do a Hack-a-thon”
Or “What You Can Expect from a Hack-a-thon?”
Or “How Do You Set Up a Hack-a-thon?”
“Innovation” seems to be the business buzzword of the moment. But if you are part of a successful software development shop we all know the problem when people ask you to be “more innovative.” We don't really allow the time to do true innovation. After all everyone knows about all the urgent things we have coming up in the plan and if we take away capacity from that work … well you know how this argument goes. So the development shop gets the reputation of not being innovative.
To break this cycle, and to prove to ourselves that we still had innovation chops, we decided to take a leaf out of the playbook of companies like Atlassian and Facebook and set up a “hack-a-thon”. A hack-a-thon is a (development shop) event where people are given a couple of days to try out anything they want to improve in their product or process.
Now for us, selling this idea took some time. We worked to help everyone understand the development treadmill we were on, and that we could establish innovation by dedicating some capacity to the effort. In the end we set it up as an experiment to see what happens, what the results were and what impact it had on existing plans.
Before going into the details of how we organized our first hack-a-thon, what were the results? The backdrop for this experiment is a product family with more than 20 years of continuous software development, with work from 10 teams located in multiple countries around the world. We gave everyone about 1 week notice that we were going to run the hack-a-thon at the end of the latest release of the product. At the end of the hack-a-thon we had 38 ideas demonstrated after 3 days of effort. Product Management was excited about putting a number of these ideas into future release plans. We had a huge return-on-investment in terms of the engagement in the development shop in their work which I suspect improved productivity. As we involved leadership in all steps along the way, it allowed us to start dispelling the notion that the development shop is unable to innovate. And we started to help people understand that innovation is not something you get for free, that you need to decide that you want to do it and set up the environment so that it can be done.
How did we do it? As said about a week before the release of a product, we issued a notice to the development shop that we would run a hack-a-thon. We decided that if we were going to do something like this, it makes sense to do it at the end of a release where we really haven't started to work too much on the next release. We put together a simple (5) slide presentation for everyone that explained the idea, how it worked and what people needed to do next and presented it in a 1 hour kick-off session. The presentation covered:
We wanted to keep the administrative overhead as low as possible to encourage participation and because, in reality, we didn't know what to expect. We pointed everyone to a Wiki page (Confluence) to register their ideas. As people came up with ideas they filled in a table with the name of the idea, a brief description and the person(s) who will work the idea on the Wiki page. This was also where people recorded their results once implemented. In our case we said that you have to show something real through a short video and that people would vote on what they saw in the videos.
There was quite a bit of discussion around whether we should specify what we wanted folks to be innovative about. There were two drivers for this discussion. On the one hand, there were people who were concerned that we weren't going to be any new ideas and that we needed to seed the ideas in some way. At the other end of the spectrum, there was a fear that people would “just do anything” and we'd up with things that wouldn't help the business. In the end both of these fears proved unjustified. We went for “no approval of ideas” - we simply let people scratch whatever itch they had - and then offered up one “special prize” in an area where we were hoping for a little more focus (in our case the upgrade process between versions of the product).
We set up the hack-a-thon so that the implementation ran Tuesday to Thursday with results complete on the wiki page by midnight on that Thursday (note: we've also done the timing so that it incorporates a weekend with good results). If you ever want to understand the level of excitement these events engender, just watch the mad rush of activity that happens on that page in the run up to midnight (and a little beyond) as people and teams trying to get their final cut of their entry registered.
We then opened up voting through a survey (we used “Lime Survey” to tally up the results), allowing everyone in the development shop vote on what they thought were the most innovative, best presented ideas. We were originally going to have management do the vote, but decided that it would have more meaning if the vote came from peers. Voting was open until 11am the following day so that we could make announcements of the winners at a hack-a-thon lunch. Prizes were award to individuals or groups by the executives based on the voting results.
After the award luncheon, closing down the event involved two activities:
There are a lot of words in this post so let me close with a few closing summary ideas as you think about setting up your own hack-a-thon especially if you doing it for the first time:
But, as they say “just do it”. The benefits in terms of innovative ideas (and helping the culture of the organization become more conscious of innovation) as well as engagement from your people more than outweigh the cost.