Hackathons Don’t Just Build Software
Typical timelines for software projects are usually measured in months or years. So how much can you achieve in just 7 hours? This is something that I found myself wondering as I took the elevator up to the 7th floor of the UK Legal Aid Agency’s London offices to join them for their most recent hackathon.
The day itself was a frenzy of activity, with 14 cross-functional teams, including staff from the Legal Aid Agency (LAA) and Atos working side by side, racing to deliver a Minimum Viable Product (MVP) by the four ‘o’clock deadline.
The first thing that struck me was the impact that a short timescale has on a team. Faced with the challenge of delivering something quickly, everyone on the team is forced to focus only on what will deliver value. For the team that I was part of, this meant really understanding the business problem and what value the solution was expected to deliver. Even so, we still all had a tendency to over complicate things: those with a business or analysis background devising more and increasingly intricate requirements, whilst those with a more technical background looked for the most automated solution (rather than the simplest). However, using Scrum with hourly Sprints forced us to put the “Minimum” back into MVP, and focus on delivering only what we could realistically achieve whilst ruthlessly prioritising business value. As I have said before, simplicity is an advantage, and we were forced to use it!
At the end of the day, each team presented their solution, and, in the spirit of friendly competition, everyone who participated in the event voted to select a winner. Watching all the presentations it was apparent that all teams had made use of open source to varying degrees. This ranged from choice of development framework (for example using the Django stack for web development) to delivering the entire solution by configuring an existing open source product. This crystallised for me why open source plays such an important role in fast development at the proof-of-concept stage: by being freed from gaining approval for a capital spend, teams can instead focus on proving that their concept will deliver value. Open source may not always be the best long term choice, but it is almost always the most sensible option for experimental work where the end business value is currently unclear.
So how fruitful was the day? Laurence Lewis (Head of Digital and IT at the LAA) described it as their “best ever hackathon by some margin with 14 teams each producing working solutions on the day”. A few weeks later one of the solutions went live, broadcasting the current status of the LAA’s IT systems across their 16 office locations by integrating with their existing LAA TV platform.
By the end of the day I came to realise that it had been about far more than delivering some IT solutions (impressive as this result was). Because hackathons like this don’t just build solutions, they build an organisational ethos. They create a safe-to-fail, yet usefully pressurised environment where people can explore and try out different technologies and approaches, as well as forging new relationships.
As I took the elevator back down to reception after the hackathon had finished, I overheard one attendee say this: “we’re really doing it; we are transforming the way we work”. So whilst I had started the day wondering how much software could be delivered in a day, I ended it realising the massive positive impact on organisational culture that an event like this can have.