Why we ran a hackathon

“A hackathon is a design sprint-like event in which any interested parties, often including domain experts, collaborate intensively on creating something of value.

The goal of a hackathon is to create usable software or a strip of value that can be tested and iterated during and after the event. Hackathons tend to have a specific focus.” (from Wikipedia)

I’ve taken the definition of a hackathon above from Wikipedia. Like so much that exists in the agile sphere, the definition seems solely written for software development. At Genesis, we create software products, but they’re part of a larger piece – including marketing, analytics, wholesale – that we’re trying to apply agile ways of working to. Hence the italics, which I feel make the description fit what we did.

Why did we choose to run a hackathon outside of the traditional realm of software development? First off, one of the core agile values is collaboration over contracts – what better way to do this with other members of your organisation and key partners than to get them together for an intensive two-day session? It helps to break down barriers, and helps areas of the business that may not be familiar with agile ways of working see the benefits of it.

One of Genesis’s key drivers is to encourage diversity of thought, which is harder to achieve if you try and push through innovation with the same people you work with day in day out. Open up the event to different viewpoints, different skillsets, different ways of working, and new ideas emerge.

Secondly, we held the hackathon in our tribe’s increment break. This is a vestige from our dabbling with SAFe and is probably one of the only things that came out of this framework that we’ve chosen to retain. The point of an increment break is, in part, to drive innovation, as with continuous delivery the ability for people to step away from their immediate focus can be difficult. By providing a time-boxed period for this type of thinking, you ultimately provide a refresh for people, whilst still adding benefit – people who work on hackathons come away feeling revitalised because they get to think about something different for a bit, and the organisation as a whole benefits because new ideas are generated, new relationships forged, and in the best cases, new products are born.

Thirdly, and following on from the idea of helping your employees feel revitalised and refreshed, these types of events help to create a culture that any agile organisation should aim for. This culture is threefold:

1. It addresses the idea of continuous improvement, by asking employees to learn new skills, develop new relationships, and try new things
2. It creates an environment that people want to work in by shifting the focus on a regular basis, giving people the chance to have fun, to get out of the normal patterns for a few days, and to feel that their employer wants them to be supported
3. Lastly it should take these two cultural shifts, and make employees feel passionate about advocating for their organisation. The best places I’ve worked are ones where there’s a sense of belonging, a feeling that it’s not just about output, that you’re enjoying what you do. If this happens, you tend to stick with the place that makes you feel these things. For any organisation this is a great thing, as it helps to keep your best people working for you, and helps to attract other like-minded people to come and join you.

The bit you might think is missing from this is ‘what about the product? Where’s the value?’. We’re getting there very shortly, I promise. However, to my mind, as someone who’s responsible for the ‘how’ we work on something, rather than the ‘what’ we actually work on, the above points are good enough reasons for holding a hackathon without any other output. Because what you’re getting here is outcome, rather than output – that outcome being better ways of working, a more invested set of people working for you, a feeling that your organisation is a damn fine place to work.

These are the things that really motivate me. You can have the best idea for a product in the world, but if you don’t have the best, most motivated people delivering it, it’ll never be as good as it could be, if it gets built at all.

Having said all that, we did end up building three products, in varying degrees of complexity and completeness. All three were built on pillars that I believe to be of most importance when it comes to product development, aside from the people-focused ones above. These are:

• involvement from a cross functional team
• a clear understand of what is trying to be achieved,
• user-centred design
• iteration
• the ability to throw it all away if it seems like it won’t fly

I mention this last one as one of our teams started work on something and came to the conclusion a day in that what they were doing wasn’t the right thing. Rather than just chuck the whole enterprise in, they changed tack, and tried a different approach. They ended up with something that wasn’t as developed as the other two ideas, but they kept on going, and learned a valuable lesson that I think is too often lost, especially in large organisations that are in the process of transforming their ways of working to more agile means – that it’s okay to get things wrong.

Part of the reason I believe that working in this quick, responsive, agile way is so beneficial is that it allows you to decide that what you’re doing isn’t maybe as useful or valuable as you first thought. This isn’t the massive problem it is on a project where you’ve invested a load of time, money and effort into building something, and then coming to this conclusion. In that scenario, you can’t afford to fail. In the scenario our team found themselves in, sure, it was a little disheartening, and they’d had to abandon an idea that they’d come up with together. But they could quickly move on, with minimal cost or disruption and try something else, and that something else may end up being 20 or 50 times more valuable than the original idea.

As organisers of the event we learned a huge amount, as well as getting improved ways of working and three product ideas to build on. For anyone looking to run a hackathon, here’s some key points:

• Prepare. And then prepare some more. We started our prep for our session about two months in advance, but this probably wasn’t enough. Whilst logistically it was okay, it didn’t give people enough time to get invested in the idea, or meant that they had other things booked in. To give yourself the widest possible base to pull from in terms of people attending, start as early as you can
• Spread the net as wide as you can. We’re limited to a degree by our increment cadence – it means that we can only really invite people from our tribe, which limits not just the people who can attend, but tends to keep that focus narrow too, as you don’t get as many differing opinions. We were lucky enough to get a few people from outside our tribe, as well as a number of partner organisations. This really helped widen our knowledge, and gave us some interesting and varied points of view we may otherwise have lacked. For our next one, we'll look to get as many people involved as possible, even if this means trying to pull them from outside our direct sphere of influence
• Provide structure. Make sure everyone knows what’s expected of them – create a shared understanding similar to how a planning session would work, with goals and targets that everyone understands. Have everyone in the event understand what part they will play; this isn’t to say that you should dogmatically assign everyone a role, as in most cases, you’ll need people to be highly flexible in what they do – developers doing user research, product owners creating wireframes. However, you want people to know what they’re working towards, and how they might get there. We ran our team as a scrum team, with morning and afternoon standups, refinement sessions after testing, planning after refinement. This may not work for every team, but starting with what you know is a good idea
• Leave your preconceptions at the door. I’ve been part of hackathons before, but I’ve never organised one. We had our teams self-select and assemble, and my pessimistic side thought that was going to be a recipe for disaster. As it turned out, the level of self-organisation in the whole event was by and large flawless, restoring my faith in humanity somewhat. My take out from this is that no matter what you’ve experienced before, there’s always room for you to be pleasantly surprised, and that coming at things with as open a mind as possible will make things easier and more effective

The two days went by in a blur, but they were some of the most fun I’ve had at a place of work. Everyone I’ve spoken to who attended found it really valuable, learned a lot, and had a blast. We’re already organising the next one, and looking forward to getting a whole lot of new folk involved and invested.

How have you run hackathons, what did you learn, and what would you do differently?