Hackathons, Jams und Challenges: alle Formate erklärt

Es gibt etwa ein Dutzend Arten zeitlich begrenzter Innovationsformate, und sie unterscheiden sich in drei Dingen: wer teilnimmt, was am Ende herauskommen soll und was danach passiert. Ein Hackathon baut funktionierende Software oder Hardware; ein Jam gestaltet und prototypisiert einen Service oder ein Erlebnis zu einem Thema; eine Innovation Challenge lädt über Wochen oder Monate zu Lösungen für ein benanntes Problem ein. Wählen Sie das Format danach, welches Ergebnis Sie am Montagmorgen brauchen – nicht nach dem Namen, der am aufregendsten klingt.

Dieser Überblick ordnet alle gängigen Formate ein, sagt, was jedes gut und schlecht kann, und verweist auf die vertiefenden Artikel in diesem Bereich.

Die drei Fragen, die jedes Format einordnen

Vor den Namen kommt die Logik. Jedes Format dieser Familie beantwortet drei Fragen unterschiedlich.

1. Wer ist im Raum? Ihre eigenen Beschäftigten (intern), eingeladene Partner (Ökosystem) oder alle, die sich anmelden (offen).
2. Was gilt als fertig? Funktionierender Code, ein physisches Objekt, ein getesteter Service-Prototyp, eine Datenanalyse oder ein gut begründetes Konzept.
3. Wie lange läuft die Uhr? Ein einziger Tag, die klassischen 48 Stunden oder eine Challenge, die über Wochen in Phasen läuft.

Können Sie diese drei Fragen für Ihre Situation beantworten, wählt sich das Format fast von selbst. Wer sie überspringt, veranstaltet am Ende einen „Hackathon“, dessen eigentliches Ziel Mitarbeiterbindung war, und wundert sich, warum nichts umgesetzt wird. Für eine direkte Gegenüberstellung siehe Hackathon, Design Jam oder Innovation Challenge.

Hackathons: schnell etwas bauen

Das Wort stammt aus dem Juni 1999, als OpenBSD-Entwickler und unabhängig davon Sun Microsystems auf seiner JavaOne-Konferenz es für intensive Programmier-Events verwendeten. Die Grundidee hat sich nicht verändert: kleine Teams, eine knappe Deadline und am Ende etwas, das läuft.

Corporate (interner) Hackathon. Beschäftigte einer Organisation bilden gemischte Teams und bauen Prototypen zu geschäftlichen Problemen. Gut, um interne Talente sichtbar zu machen, Silos zu durchbrechen und Ideen zu testen, die als Papiervorschlag nie einen Budgetausschuss überleben würden. Schwach, wenn die Leitung keinen Plan, keine Verantwortlichen und kein Budget für das Siegerprojekt hat. Lesen Sie warum die meisten Hackathon-Gewinner nie umgesetzt werden, bevor Sie den Veranstaltungsort buchen.

Civic- und Government-Hackathon. Eine öffentliche Einrichtung öffnet ihre Probleme – und oft ihre Daten – für Entwickler, Designer und Bürger. Die International Space Apps Challenge der NASA, seit 2012 jedes Jahr ausgetragen, ist das bekannteste globale Beispiel. Solche Events schaffen Vertrauen und holen externe Kompetenz in die Verwaltung, brauchen aber einen klaren Weg, auf dem ein Prototyp einen echten Service erreicht – sonst werden sie zu reinen Imageübungen. Hackathons fürs Gemeinwohl behandelt zweckgebundene Varianten.

Offener (öffentlicher) Hackathon. Jede und jeder kann sich anmelden. Sie gewinnen Bandbreite, Energie und Menschen, die Ihr Problem noch nie gesehen haben. Sie verlieren Kontrolle über geistiges Eigentum, Vertraulichkeit und Weiterverfolgung, weil die meisten Teilnehmenden danach zu anderen Jobs zurückkehren. Die Abwägung finden Sie in Interner Hackathon oder offen für alle.

Ökosystem-Hackathon. Mehrere Einrichtungen teilen eine Challenge, die keine allein lösen kann: eine Aufsichtsbehörde, zwei Banken und eine Fintech-Community; ein Ministerium, eine Universität und Krankenhäuser. Die Teams werden bewusst organisationsübergreifend gemischt. Das Schwierigste ist nicht das Wochenende, sondern die vorherige Einigung, wem das Problem gehört und wer das Siegerprojekt finanziert. Siehe Der Ökosystem-Hackathon.

Jams: Services und Erlebnisse gestalten

Ein Jam übernimmt die Uhr des Hackathons, ändert aber, was als fertig gilt. Das Ergebnis ist ein Prototyp eines Service, eines Erlebnisses oder eines Spiels, möglichst mit echten Menschen getestet, statt produktionsreifen Codes.

Service Jam. Der Global Service Jam wurde 2011 von Adam Lawrence und Markus Hormess von WorkPlayExperience ins Leben gerufen. Teams in vielen Städten arbeiten 48 Stunden lang am selben geheimen Thema, das zum Start enthüllt wird, und veröffentlichen ihre Prototypen anschließend online unter einer offenen Lizenz. Die Methode ist Service Design mit dem Grundsatz „Machen statt reden“: rausgehen, mit Menschen sprechen, eine grobe Version bauen, testen, ändern. Es ist das beste Format, um einer Organisation zu vermitteln, wie sich Service Design wirklich anfühlt.

GovJam. Dasselbe Modell, ausgerichtet auf den öffentlichen Sektor. Der GovJam wurde 2012 von der australischen Regierung gemeinsam mit WorkPlayExperience und Protopartners initiiert, und der Global GovJam findet seit 2013 in Städten auf der ganzen Welt statt. Beschäftigte der Verwaltung, Designer und Bürger arbeiten 48 Stunden Seite an Seite an einem gemeinsamen geheimen Thema. Ein Schwesterformat, der Global Sustainability Jam, wendet denselben Ansatz auf Nachhaltigkeit an.

Design Jam. Die allgemeine, lokal organisierte Variante: ein oder zwei Tage an einem Designproblem, oft zu User Experience oder einem bestimmten Service, mit einer Moderation, die durch Research, Ideenfindung und Prototyping führt. Leichter zu organisieren als ein Hackathon, weil niemand eine Entwicklungsumgebung braucht, und offen für Menschen, die nicht programmieren.

Game Jam. Teams entwickeln ein spielbares Spiel zu einem Thema. Der Global Game Jam, gegründet von Susan Gold, Ian Schreiber, Gorm Lai und Foaad Khosmood und inspiriert vom Nordic Game Jam, fand erstmals im Januar 2009 an 53 Standorten statt. Er dauert 48 Stunden, meist Ende Januar, das Thema wird zum Start bekanntgegeben. Organisationen nutzen Game Jams weniger wegen der Spiele als wegen dessen, was sie trainieren: hart priorisieren und in zwei Tagen etwas Vollständiges, Spielbares abliefern.

Wie Sie selbst einen solchen Jam durchführen, Thema inklusive, erfahren Sie in Einen Jam durchführen.

Die „-athon“-Varianten: gleiche Uhr, anderes Ergebnis

Ideathon. Teams entwickeln Konzepte, keine Builds. Das Ergebnis ist eine Problemrahmung, ein Lösungskonzept, ein grobes Storyboard und ein Pitch. Nützlich früh im Prozess, wenn Sie noch nicht wissen, welches Problem zählt, oder wenn den Teilnehmenden technische Kenntnisse fehlen. Das Risiko: Ein polierter Pitch wird mit Evidenz verwechselt. Bestehen Sie auf mindestens einem Gespräch mit einem echten Nutzer pro Team.

Datathon. Ein Hackathon, der sich auf das Analysieren und Verknüpfen von Datensätzen konzentriert statt auf Softwareentwicklung. Das Ergebnis ist eine Erkenntnis, ein Modell oder eine Visualisierung, die eine Frage beantwortet. Das funktioniert nur, wenn die Daten vor dem Tag bereitstehen, bereinigt und zur Nutzung freigegeben sind; die meisten gescheiterten Datathons sterben in den ersten drei Stunden an Berechtigungsproblemen.

Makeathon. Physisches Prototyping: Hardware, Elektronik, Produktmodelle, oft in einem Fab Lab oder Makerspace. Sie brauchen Werkzeuge, Material, Sicherheitseinweisungen und Techniker, und die Uhr läuft meist länger, weil Objekte Zeit brauchen, um gebaut zu werden und kaputtzugehen.

Innovation Challenges: das lange Format

Eine Innovation Challenge (auch Open Call oder Prize Challenge genannt) veröffentlicht ein Problem und lädt über Wochen oder Monate zu Lösungen ein, meist in Phasen: Einreichung, Shortlist, begleitete Weiterentwicklung, finale Auswahl. Sie passt zu Problemen, die sich nicht in 48 Stunden knacken lassen, zu Lösern, die bereits an dem Problem arbeiten (Startups, Forschungsgruppen, Lieferanten), und zu Organisationen, die eine Pipeline von Piloten wollen statt eines Wochenendes voller Energie.

Eine Challenge steht und fällt mit ihrer Problemstellung. Zu breit, und Sie bekommen einen Stapel generischer Apps; zu eng, und Sie haben eine Ausschreibung geschrieben. Wie Sie eine Challenge-Fragestellung schreiben, die Menschen lösen wollen behandelt das ausführlich, und Bewertungskriterien, die den richtigen Gewinner finden behandelt die Auswahlphasen.

Alle Formate auf einen Blick

So wählen Sie aus – in fünf Schritten

1. Den Montagmorgen-Satz schreiben. „Nach diesem Event haben wir ___, und ___ verantwortet es.“ Lautet die Lücke „einen funktionierenden Prototyp, den unser IT-Team weiterführt“, brauchen Sie einen Hackathon. Lautet sie „drei getestete Servicekonzepte, die das Customer-Experience-Team pilotiert“, einen Jam. Lautet sie „zwei Startups, die für einen Piloten beauftragt sind“, eine Challenge.
2. Prüfen, ob das Problem reif ist. Rahmen Sie es mit einem Problembaum und formen Sie den Kern zu einigen Wie-könnten-wir-Fragen. Gelingt das nicht, führen Sie zuerst einen Ideathon oder eine Discovery-Phase durch.
3. Kompetenzen auf das Ergebnis abstimmen. Funktionierender Code braucht Entwickler in den meisten Teams. Service-Prototypen brauchen Menschen, die mit Fremden sprechen. Daten-Events brauchen bereinigte, freigegebene Daten.
4. Das Danach vor dem Währenddessen entscheiden. Benennen Sie die Verantwortlichen, die Budgetposition und den Entscheidungstermin für die Gewinner. Wie Sie einen Hackathon durchführen, der etwas Echtes hervorbringt baut das in den Plan ein.
5. Jury und Mentoren nach dem Ergebnis auswählen, nicht nach dem Foto. Juroren, die das Ergebnis verantworten werden; Mentoren, die das Problem kennen. Siehe Mentoren bei einem Hackathon.

Beispiel

Illustrativ. Eine mittelgroße städtische Verkehrsbehörde in Nordeuropa wollte verpasste Anschlüsse bei älteren Fahrgästen reduzieren. Ihr erster Impuls war ein offener Hackathon mit einem Preis für die beste App. In der Planung schrieb das Team seinen Montagmorgen-Satz und stellte fest, dass es gar keine App wollte: Es wollte wissen, welcher Teil der Reise versagte und welche Serviceänderungen das Personal im Rahmen des bestehenden Budgets umsetzen konnte.

Stattdessen führte es einen zweitägigen Service Jam durch, mit Fahrern, Stationspersonal, einigen älteren Fahrgästen und zwei Designern. Die Teams verbrachten den ersten Vormittag damit, Strecken abzufahren und Fahrgäste zu interviewen, bauten Storyboards und Papierprototypen für Durchsagen, Beschilderung und eine Rolle als „Umsteigebegleitung“ und testeten sie an einem echten Umsteigeknoten. Ein Challenge Panel aus dem Betriebsleiter und zwei Stationsleitern wählte zwei Konzepte für einen Piloten aus. Ein Hackathon folgte sechs Monate später, mit einem engen Auftrag: den Echtzeit-Anschlussalarm zu bauen, den sich die Fahrgäste laut Jam tatsächlich wünschten.

Was Sie tun und lassen sollten

Tun

• Das Format nach dem benötigten Ergebnis wählen und danach, wer es verantworten wird.
• Problem, Bewertungskriterien und das, was Gewinner erhalten, veröffentlichen, bevor die Anmeldung öffnet.
• Teams bewusst mischen: Fachleute mit Entwicklern, Junioren mit Senioren, Insider mit Externen.
• Die 90 Tage nach dem Event so sorgfältig planen wie seine 48 Stunden. Eine Rollout-Checkliste hilft.
• Bei Ökosystem-Events eine Ecosystem Map zeichnen und die Verantwortung klären, bevor Sie jemanden einladen.

Lassen

• Ein Engagement-Event Hackathon nennen und dann Umsetzung versprechen.
• Einen Datathon durchführen, bevor die Daten freigegeben sind, oder einen Hackathon ohne Zugang zu den Systemen, die der Prototyp berühren muss.
• Den Pitch alles entscheiden lassen. Bewerten Sie Evidenz und Machbarkeit mit einer gewichteten Entscheidungsmatrix, nicht mit Applaus.
• Die Geheimthema-Mechanik eines globalen Jams für ein internes Event kopieren, bei dem Sie das Problem schon kennen. Geheime Themen passen zu Lernformaten, nicht zu gezielter Problemlösung.
• Die klassischen Fehler wiederholen, die in 9 Hackathon-Fehler, die Veranstalter immer wieder machen aufgeführt sind.

Häufige Fragen

Was ist der Unterschied zwischen einem Hackathon und einem Jam? Ein Hackathon wird danach bewertet, was funktioniert: Code, Hardware, ein laufender Prototyp. Ein Jam wird nach einem gestalteten und getesteten Service oder Erlebnis bewertet und erfordert meist keine Programmierung. Beide dauern oft 48 Stunden, aber ein Jam verbringt weit mehr dieser Zeit mit echten Nutzern.

Was ist der Unterschied zwischen einem Hackathon und einem Ideathon? Ein Ideathon endet mit Konzepten und Pitches, ein Hackathon mit etwas Gebautem. Nutzen Sie einen Ideathon, wenn das Problem noch unscharf ist oder die Teilnehmenden nicht technisch sind, und einen Hackathon, wenn das Problem klar ist und Sie Entwickler haben.

Ist eine Innovation Challenge dasselbe wie ein Hackathon? Nein. Eine Challenge läuft über Wochen oder Monate in Phasen und zieht Löser an, die bereits Kompetenz mitbringen, etwa Startups und Forschungsteams. Ein Hackathon verdichtet alles auf wenige Tage, und die meisten Teams beginnen bei null.

Wie es weitergeht

Beginnen Sie mit den Guides, die das Problem vor jedem Event schärfen: Problembaum und Wie-könnten-wir-Fragen. Für die Bau- und Testphase nutzen Sie Papierprototyp und Storyboard, für die Auswahl ein Challenge Panel. Alle Methoden-Guides finden Sie in der Guide-Übersicht.