Last week we held our bi-annual hackathon event, it was the 5th time we’ve run one at Mountain Warehouse (the 4th that I’ve run) and we’re getting into some patterns.
Why we run it
- Know other developers better – because our teams are product-focussed (and gain the benefits of real ownership of their applications) they work with the same people on a day-to-day basis. The Hackathon gives everyone an opportunity to spend real time with other developers to learn more about who they are and how they work.
- Broaden our knowledge – by looking at other technologies we gain an understanding of it and when it might be applicable to our day-to-day work. Sometimes the tech is already in use in part of the development team but it’s an opportunity for those who haven’t worked with it to get some experience.
- Identify unused skills – an unexpected benefit that I now keep my eyes more open for – several of our team have shown themselves to be proficient in an area that they don’t get to use day-to-day. Trying to provide opportunities to use those skills further is then my job!
- Provide another business benefit – occasionally a project lays the foundations for something the rest of the business could use.
How we run it
At the beginning of the hackathon all developers with an idea get about 1 minute to pitch their idea to the whole group. When we’ve gone through all the hack ideas then all the developers write down on a sheet the 4 projects they’d like to work on in descending order. Roughly, the projects with the most votes get through, although there is usually a little massaging to split up people who work together already.
Practical note: I write each idea against a number on a large screen so that everyone can see them all at the end when they vote… and for my own sanity!
The developers have all had a month or so to come up with ideas and it’s something that I try to raise whenever I bump into anyone in the kitchen, corridor, meeting, etc. I ask for the ideas in advance essentially to merge any similar ideas or comment if something is already in our project backlog (and it has no other exciting technical angle). I can also help flesh out those ideas to make a better pitch.
It is not a competitive event – although some developers would prefer it to be, in the past some have said that they would not want to take part if it is and that has to take priority. Upon reflection, it may affect matching the goals we’ve set up anyway as team members will choose team and project based upon wanting to win rather than wanting to learn. This may change!
What about non-developers?
For me, this is still a work-in-progress as I think we could use the time better. However for the last few hackathons it’s worked out a little like this:
Designers: There’s usually an idea or two that will need some graphic resource or user journey planning.
QA: Have generally used the time as an opportunity to catch up a little bit and gain some breathing space. I’d like to work some extra personal development in here though.
Lead Developers: Sometimes they join in, sometimes they also take it as an opportunity to catch up and to keep any business attention away from their team. We do occasionally use this time to have a discussion around system architecture and other cross-team concerns.
Project Managers: Catch up and other personal development tasks.
Infrastructure / DevOps: Have generally commented that their day-to-day work is interesting enough – this time they did a quick demo of Helm and Zabbix for the rest of the developers.