Broadly-speaking, a hackathon is an event that temporarily disrupts "normal" business operations and allows self-organized teams to rapid prototype around their interest areas (technical discovery, business problems, future-looking improvements, etc). Organizations like Atlassian have formal hackathons (ShipIt Days) and others take an ad hoc approach. Rather than re-state what has already been written about successfully planning and holding these events, I would like to share a consultant's perspective on how teams benefit from special hacking events.
Build Competency in Incremental Delivery
As a practitioner of Extreme Programming, I constantly seek to improve responsiveness by shortening feedback loops. In a well-managed hackathon, the entire team is held to a deadline to deliver results; this prompts each team to regularly assess (and adjust) their scope of work to match a target pace of delivery. During presentations, teams can evaluate their contribution relative to their peer teams, providing even more feedback. As this cycle is typically much shorter than "normal" operations (1 day hackathon vs a 1 week sprint), the team will be able to learn and grow more quickly.
Connect to Stakeholders
"I love this new functionality! I can use it to solve [some nagging business problem]!"
By requiring that hackathon teams demonstrate their work in a closing ceremony, participants sees the organization from a stakeholder's perspective. This rapid feedback informs each developer's future work, and product owners will take more innovative risks with the knowledge that their technical team has the capacity to iterate quickly. This is a cornerstone of high-trust teams.
Break Down Silos
Allowing teams to self-organize gives them the opportunity to network and collaborate outside their "normal" domain. As a consultant, I am often empowered to cross team lines (especially during Discovery and Framing), and I can attest to the power of reaching across team boundaries. This effect compounds when teams find synergistic opportunities across functional boundaries. After all, when product and engineering work directly together, the risk of expensive rework drops considerably.
The Gift of Shared Experience
Even in the most tight-knit teams, daily work experiences can be wildly different (DevOps vs Customer Success, for example). Eventually, these functional groups begin to diverge and develop their own work subcultures. Intentionally bringing the team together for a shared set of rituals (coffee and donuts during kick-off, mid-hackathon trivia, project demos, and a hearty round of appreciation and congrats) can stitch the teams back together.
Demonstrate Your Values
Is your company customer-obsessed? Does it cultivate a learning-oriented culture? Do you work hard, play hard? No matter how Core Values are expressed on a corporate landing page, the actual results of a hackathon will open a window into the team's inner dynamics. This is important feedback for organizational leaders, who experience the team differently than their reports. Seeing the team in a different light can be instructive when mapping out the future of a company.
PS: On "normal"
In this article, I want to provide an argument for reconsidering what is "normal" for a team (of any size). Across multiple successful hackathons, I've seen teams produce surprising results in a very short period of time. I believe that a small change in environment (aka: turn on email auto-responders, silence the phones until 4pm, sit with your new team in a new conference room, etc) can have significant positive externalities. With some practice, teams can hold Retrospectives and incorporate hackathon tactics into their daily work, turning the static "normal" to a continuously-improving norm.
Cover photo is my own: Flickr
Oldest comments (0)