Startups generate many ideas but finding those that can be practically executed requires quick prototypes. A great way to flex the team’s ‘minimum viable product’ muscles is to participate in a hackathon. There are valuable lessons to learn.
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 small team, with a clear deliverable, working in short sprints can be much more productive than a large team working to an elaborate plan; further, 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. A hackathon is a scenario where a team comes together for a short time to build something that can be shown within a few short days. The time pressure means that teams must organise themselves quickly and find non-overlapping roles.
While some winning teams are large, many with as few as three report that this is a good number providing the needed skills are on hand.
Winning teams report that early on someone emerged as the leader, not in an authoritarian sense but more as a project manager responsible for allocating work and resolving dependencies and blockages.
In 2001, perhaps after the industry embarrassment of the Y2K bug, and a history of large software projects which had failed for various reasons, 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
- Responding to Change over following a plan
For participants used to working on projects that are planned out over many months, a hackathon, which must be delivered in a few days 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, a demonstration of the project, with specific users in mind, can be run. When a minimum viable product is achieved all that’s left is to polish in the brief time remaining. If a sprint fails to deliver, the team can pivot.
Send your team to GovHack
Every year, GovHack surfaces a wondrous collection of data from enlightened government departments. Alongside the new data there are inevitably new software tools to learn about including developments in data analysis, visualisation, mapping and machine learning.
Starting a project with data or tools looking for a problem smacks a bit of a person likely to hammer a screw, but it’s a refreshing change from normal work practices.
Past winners have often looked to the awards categories in search of clear problems to solve and then drawn from the data and tools to come up with innovative entries.
This year GovHack will run at 40 locations in Australia and New Zealand. We’re looking for participants, data mentors and sponsors. For more information visit http://govhack.org
Written by Peter Marks for GovHack.
Peter Marks is a software developer and technology analyst.
He is a regular contributor to ABC Radio National and blogs at http://blog.marxy.org