Organising and managing a successful ‘hackathon’ or ‘hack day’

Avid readers of the blog will notice that this week, there’s no Sabisu release. The reason is that we’ve all been holed up in a secret location in deepest Derbyshire, cutting some new and rather interesting code.

Here’s why and how we did it. And here are some photos.

So why do it?

Sometimes you have to break the routine; pull the team out of a familiar environment and change the rules. It’s also an opportunity to get distributed teams together to work on a single challenge. Focus is really important.

This is what a ‘hackathon’ is to us; it’s persistent, relentless iterative product development sprints. The origin of the term might relate to the idea of the  ‘life hack‘ but in fact we misuse the term to mean rapid and focused development.

Sabisu Hackathon Development Team Leader

Relax into it

Changing the rules is important for this to work, though it does depend on the culture already present. So for example if you want a beer, you get yourself a beer. It’s up to the individual to ensure they remain productive and that their work is of a high quality. With the right culture, it’s not a problem.

Normal working hours go out of the window too. A two-hour football break? Sure, nice weather demands it. Equally it’s no problem, at 2300, working through database queries and validation mechanisms. (And writing blog posts.)

I think the job of management here is two-fold; let the group self-manage and do all the fetching/carrying/cooking required to give the team an easy life.

Sabisu Hackathon Slow Cooked Lamb

A bit of structure goes a long way

We started the hackathon with a simple statement of the objective: a minimum viable product. There were some clear challenges about what we wanted to achieve. These were phrased as open questions; ‘what do we do about x?’, ‘how do we do y?’ and of course the important ‘why does the customer want to do z?’.

Then in response to these questions the development team (untramelled by management) devised the ‘ideal world’; what they’d build if time was unlimited. The idea here was that anything produced would be with the long term in mind, rather than just a short term hack.

With some idea of the long term, the guys then split it into really small sprints, typically about 3 hours work for the team. The idea was to keep the scope for each sprint as tight as possible, producing something ready for demonstration from each sprint. Keeping it to 3 hours does this nicely – it’s long enough to produce something, but short enough to stay focused.

Sabisu Hackathon Team Sprint

 

So what happened?

Well, there are two questions to be answered;

  • what did we produce?
  • was the process a success?

In terms of the latter question, all the feedback from the team has been positive – and the photos support this. We’ll post up their thoughts in the next few days.

In terms of what we produced…well, we’ll be announcing that very soon. Let’s just say it moves Sabisu firmly towards being one place where you can find everything you need.

[Edited to add the follow up announcement and details posts.]

Start typing and press Enter to search