Anyone involved in a startup can attest to the unique ability these new businesses have to generate a lot of ideas. The trick though is in working out which of those ideas can be practically executed into quick prototypes.
A great way to flex a team’s ‘minimum viable product’ muscles is to participate in a hackathon. And for those taking part, there are some critical lessons relevant to anyone wanting to turn an idea around quickly.
The biggest change in software development in the past few decades is the Agile methodologies. As far back as 1975, when IBM’s Fred Brooks published his seminal work, The Mythical Man-Month, he found that adding more staff to an overdue project would lead to the project taking longer. Brooks learned this from his experience working on the overdue IBM OS/360 operating system.
We now know that a small team, with a clear deliverable, working in short sprints can be much more productive than a large team working to an elaborate plan. Short sprints, with regular demonstrations of what’s been achieved, can head off wasted effort arising from building the wrong thing.
Working in a team can be tough. And with the added stress of time limitations, the pressure on a team coming together for a short time to take part in a hackathon can be exacerbated.
So work together to organise your team quickly, and organise them well. Ensure there are no over-lapping roles, and that there’s a good range of skills. While some hackathon-winning teams are large, many with as few as three report that this is a good number, providing the needed skills are on hand.
Typically, you’ll see someone early who emerges as the leader, not in an authoritarian sense but more as a project manager responsible for allocating work and resolving dependencies and blockages. This is a good thing.
Read more: What to do and what not to do at your next hackathon
In 2001, inspired perhaps by the industry embarrassment of the Y2K bug, and a history of large failed software projects, an influential group of software developers met and proclaimed a “Manifesto for Agile Software Development”.
Briefly, it values:
• Individuals and interactions over processes and tools;
• Working software over comprehensive documentation;
• Customer collaboration over contract negotiation; and
• Responding to change over following a plan.
For participants used to working on projects that are planned over many months, a hackathon offers a refreshing break with normal work practices. ‘Sprints’ can be down to a few hours. Technical experiments can be quickly tried and abandoned just as fast if required.
At every step, teams can run a demonstration of the project with specific users in mind. When a minimum viable product is achieved, all that’s left is to polish in the brief time remaining.
It’s working with this kind of approach that makes it easier for businesses to pivot and manage challenges.
Every year, GovHack surfaces a wondrous collection of data from enlightened government departments, while other hackathons out there specialise in other data sets or hypothetical situations.
Alongside new data, there are inevitably new software tools to learn about, including developments in data analysis, visualisation, mapping and machine learning. It’s a fantastic opportunity to grow and learn.
This is part of a 12-part series into hackathons SmartCompany is publishing in association with GovHack.
Peter Marks is a technology commentator appearing weekly on ABC Radio National Breakfast. He’s previously worked in various technical roles for CNN, News Interactive, and Apple. Peter is a past competitor and now volunteer at GovHack.
