Einen Jam durchführen: 48 Stunden, ein geheimes Thema und echte Services

Ein Jam ist eine 48-stündige Veranstaltung, in der kleine, gemischte Teams von Grund auf einen neuen Service gestalten – zu einem Thema, das bis zum Eröffnungsabend niemand kennt. Für einen guten Jam brauchen Sie vier Dinge: ein Thema, das wirklich geheim bleibt, echte Menschen außerhalb des Raums, mit denen recherchiert und getestet wird, eine harte Deadline für einen funktionierenden Prototyp und einen Plan für den Montag danach. Code ist optional; rausgehen und mit Menschen sprechen nicht.

Das Format hat eine klare Herkunft. Der Global Service Jam wurde 2011 von Adam Lawrence und Markus Hormess von WorkPlayExperience ins Leben gerufen, nach dem Vorbild von Game Jams wie dem Global Game Jam (erstmals 2009). Schwesterformate folgten: der Global Sustainability Jam und der GovJam, der denselben Ansatz auf öffentliche Dienstleistungen anwendet. In den globalen Ausgaben wird das Thema am Freitagabend Ortszeit per Video enthüllt, und die Teams veröffentlichen bis Sonntagnachmittag die Dokumentation ihres Prototyps, offen geteilt unter einer Creative-Commons-Lizenz. Sie müssen nicht an einem globalen Jam teilnehmen, um das Format zu nutzen, aber sein Rhythmus ist ein guter Ausgangspunkt.

Dieser Beitrag behandelt speziell die Durchführung eines Jams. Wie sich Jams zu Hackathons und Challenges verhalten, lesen Sie in Hackathon, Design Jam oder Innovation Challenge; die vollständige Formatübersicht finden Sie in Hackathons, Jams und Challenges: alle Formate erklärt.

Was einen Jam von einem Hackathon unterscheidet

Ein Hackathon beginnt meist mit einer definierten Challenge und endet mit einem Pitch vor einer Jury. Ein Jam beginnt mit einem bewusst vagen Thema („verborgene Schätze“, „Warten“, „Vertrauen“), verlangt von den Teams, darin ein echtes menschliches Bedürfnis zu finden, und endet mit einem Prototyp, den Menschen erleben können. Daraus folgen drei Dinge:

• Niemand kann mit einer fertigen Lösung anreisen. Das geheime Thema verhindert, dass jemand ein Lieblingsprojekt mitbringt und es neu verpackt.
• Die Recherche findet während der Veranstaltung statt. Die Teams verlassen das Gebäude, beobachten, befragen Fremde und kommen mit Belegen zurück.
• Das Ergebnis ist ein Service, keine App. Ein im Rollenspiel durchgespielter Empfangstresen, ein Papierformular, ein Storyboard einer neuen Customer Journey – all das zählt. Viele gute Jam-Prototypen enthalten überhaupt keine Software.

Globale Jams sind im Kern keine Wettbewerbe. Wenn Ihr Sponsor einen Gewinner will, fragen Sie sich, ob ein Preis die Teams nicht einfach dazu bringt, Pitches zu polieren, statt zu testen.

So führen Sie einen Jam durch, Schritt für Schritt

1. Klären Sie, warum Sie jammen (sechs bis acht Wochen vorher). Schreiben Sie einen Satz: Was soll am Montag existieren, das es heute nicht gibt? Typische Antworten: vierzig Mitarbeitende, die jeweils einmal echte Feldforschung gemacht haben; drei Servicekonzepte in einem Bereich, den die Organisation bisher gemieden hat; eine abteilungsübergreifende Community of Practice. Lautet die Antwort „eine Lösung für Problem X“, brauchen Sie wahrscheinlich eher einen Hackathon oder eine Challenge.

2. Wählen Sie ein Thema, das weit, menschlich und geheim ist. Gute Themen sind ein Wort, ein Bild oder ein kurzer Klang, der sich auf viele Arten deuten lässt. Schlechte Themen sind getarnte Briefings („digitales Onboarding für KMU“). Nur zwei oder drei Personen sollten es kennen. Bereiten Sie die Enthüllung vor: ein kurzes Video oder eine einzige Folie, gezeigt zu einer festen Uhrzeit am ersten Abend.

3. Achten Sie bei der Auswahl auf Mischung, nicht auf Seniorität. Planen Sie Teams von vier bis sechs Personen mit unterschiedlichem Hintergrund: Mitarbeitende mit Kundenkontakt, Designer, Entwicklerinnen, Fachleute aus Politik und Verwaltung, ein paar Externe. Laden Sie Menschen als Einzelpersonen ein, nicht als Abteilungsdelegationen. Bitten Sie alle, sich für die vollen 48 Stunden zu verpflichten; Teilzeit-Jammer bremsen ihre Teams aus.

4. Organisieren Sie die Außenwelt im Voraus. Diesen Schritt lassen die meisten Veranstalter aus. Legen Sie vor der Veranstaltung Orte fest, die die Teams besuchen können (eine Filiale, ein Wartezimmer, einen Behördenschalter, eine Einkaufsstraße), und holen Sie bei Bedarf Genehmigungen ein. Informieren Sie die Mitarbeitenden vor Ort, dass Jammer kommen und Fragen stellen könnten. Bereiten Sie einen kurzen Einwilligungstext für Interviews und Fotos vor. Ohne das „recherchieren“ die Teams untereinander.

5. Richten Sie Raum und Material ein. Ein großer Raum mit Teamtischen, Wandflächen, Karton, Klebeband, Markern, einem Drucker, Requisiten für Rollenspiele und gutem Essen zu vernünftigen Zeiten.

6. Freitagabend: enthüllen, reagieren, Teams bilden. Holen Sie alle mit einem kurzen Warm-up zusammen. Enthüllen Sie das Thema. Geben Sie zehn Minuten stille, individuelle Reaktion (Woran lässt Sie dieses Wort denken, wer kommt Ihnen in den Sinn?). Bitten Sie die Teilnehmenden, in einem Satz ein menschliches Bedürfnis oder eine Frage zu pitchen, keine Lösung. Lassen Sie Teams um die Fragen entstehen, die die Menschen am spannendsten finden. Zum Abschluss des Abends schreibt jedes Team eine Wie-könnten-wir-Frage, der es nachgehen wird.

7. Samstag: raus aus dem Gebäude, dann bauen. Der Vormittag gehört der Recherche. Die Teams gehen hinaus, beobachten und sprechen mit echten Menschen – mit einer leichten Service Safari oder kurzen Stakeholder-Interviews. Bis zum Mittag sollten sie von mindestens fünf Menschen gehört haben, die keine Jammer sind. Der Nachmittag dient der Synthese und den ersten Prototypen: Storyboards, Rollenspiele, Papierversionen. Vor dem Abendessen testet jedes Team etwas Grobes mit jemandem außerhalb des Teams.

8. Sonntag: testen, iterieren, dokumentieren. Vormittags: ein oder zwei weitere Runden Testen und Ändern. Mittags: Den Prototyp einfrieren und so dokumentieren, dass ein Fremder ihn versteht (welches Bedürfnis, was das Team gelernt hat, was der Service ist, was getestet wurde und was dabei herauskam). Nachmittags: Jedes Team zeigt seinen Prototyp – am besten, indem das Publikum ihn erlebt, statt Folien zu sehen.

9. Planen Sie den Montag vor dem Freitag. Legen Sie im Voraus fest, wer die Ergebnisse erhält, wie Teams Zeit zum Weitermachen beantragen können und was ein Sponsor in den folgenden zwei Wochen tun wird. Ein Jam, der mit Applaus und sonst nichts endet, lehrt die Menschen, dass Innovation Theater ist. Siehe Was nach dem Hackathon zu tun ist; dieselbe Logik gilt hier.

Rollen, die Sie brauchen

• Host. Verantwortet die gesamte Veranstaltung, hält die Zeit, schützt die Regeln. Eine Person.
• Moderatoren oder Coaches. Eine Person für je zwei oder drei Teams. Ihre Aufgabe: Teams nach draußen schicken, fragen „Mit wem haben Sie das getestet?“ und endlose Diskussionen beenden. Sie gestalten nicht für die Teams.
• Fachliche Helfer. Zwei oder drei Personen, die den echten Service kennen (Vorschriften, Systeme, die Realität an der Front) und auf Abruf bereitstehen. Sie beantworten Fragen; sie bewerten keine Ideen.
• Dokumentation. Jemand, der fotografiert, Ergebnisse sammelt und dafür sorgt, dass die Arbeit jedes Teams das Wochenende überdauert.
• Sponsor. Eine Führungskraft, die die Veranstaltung eröffnet, am Sonntag zurückkommt, um die Prototypen zu erleben, und den Plan für Montag verantwortet.

Illustratives Beispiel

Illustrativ. Ein städtisches Verkehrsunternehmen in einer mittelgroßen europäischen Stadt wollte, dass Mitarbeitende aus Betrieb, Kundenservice und IT zum ersten Mal zusammenarbeiten. Es veranstaltete einen Jam von Donnerstagabend bis Samstag, damit niemand ein Wochenende verlor. Das am ersten Abend enthüllte Thema war die Tonaufnahme einer Bahnhofsdurchsage, die langsam verklingt. Die Teams deuteten es als „uninformiert zurückgelassen werden“, „der letzte Zug“ und „nachts allein unterwegs“.

Vor der Veranstaltung hatte der Host Zugang zu zwei Bahnhöfen und einem Nachtbusdepot organisiert und die Mitarbeitenden dort informiert. Am zweiten Morgen verbrachte ein Team drei Stunden an einer Haltestelle spät in der Nacht und sprach mit elf Fahrgästen und zwei Fahrern. Sein Prototyp war keine App: Es waren eine gedruckte Karte „Falls Ihr Anschluss ausfällt“, eine ausformulierte Fahrerdurchsage und ein im Rollenspiel durchgespielter Anruf bei einer Nacht-Hotline. Am selben Abend testete das Team das an derselben Haltestelle mit sechs Fahrgästen und änderte die Formulierung zweimal.

Am letzten Nachmittag erlebte die Betriebsleiterin jeden Prototyp persönlich. Zwei Konzepte bekamen eine vierwöchige Testphase, jeweils mit einer benannten verantwortlichen Person und einem kleinen Team von Jammern.

Do's and Don'ts

Do

• Halten Sie das Thema wirklich geheim. Wenn die Leute es am Mittwoch kennen, kommt die Hälfte mit einer fertigen Lösung.
• Organisieren Sie den Zugang zum Feld vor der Veranstaltung. Recherche ist das Herz eines Jams, und sie braucht Genehmigungen und einen Einwilligungstext.
• Machen Sie „zeigen statt erzählen“ zur Regel für die Abschlusssession. Lassen Sie die Menschen den Service erleben.
• Verpflegen Sie die Teilnehmenden gut und schicken Sie sie nachts nach Hause. Müde Teams bauen schlechtere Prototypen, keine mutigeren.
• Teilen Sie die Dokumentation offen. Das schafft Vertrauen für den nächsten Jam.

Don't

• Machen Sie aus dem Thema kein Briefing. „Warten“ ist ein Thema; „Wartezeiten in Filiale 12 verkürzen“ ist ein Projekt.
• Lassen Sie die Teams den Samstagvormittag nicht im Raum verbringen. Wenn bis Mittag niemand mit einem Fremden gesprochen hat, greifen Sie ein.
• Besetzen Sie Teams nicht mit nur einer Abteilung oder einer Hierarchieebene. Eine Direktorin in einem Team von Berufseinsteigern trifft stillschweigend jede Entscheidung.
• Bewerten Sie nicht nach Pitch-Qualität. Wenn Sie etwas auszeichnen müssen, belohnen Sie Belege aus Tests.
• Versprechen Sie keine Umsetzung, die Sie nicht leisten können. Versprechen Sie ein echtes Gespräch mit einer echten verantwortlichen Person zu einem festen Termin.

Häufige Fragen

Wie lang sollte ein Jam sein? Geht es auch an einem Tag? 48 Stunden, verteilt auf drei Tage, sind die klassische Form, weil sie eine Nacht zum Nachdenken und zwei Testrunden ermöglichen. Eine eintägige Version funktioniert als Einstieg, doch Sie verlieren den Großteil der Feldforschung und Iteration.

Müssen die Teilnehmenden Designer sein? Nein. Gemischte Teams funktionieren am besten, und Mitarbeitende mit Kundenkontakt bringen oft die schärfsten Erkenntnisse mit. Wichtig sind ein paar Moderatoren, die die Methoden kennen.

Was sollte ein Jam-Team am Ende abgeben? Eine kurze, schlichte Dokumentation: das gefundene Bedürfnis, mit wem es gesprochen hat, was es gebaut hat, wie es getestet wurde und was sich geändert hat. Fotos des Prototyps im Einsatz sind mehr wert als Folien. Ein einfaches Feedback-Capture-Grid pro Team macht das leicht.

Methoden für den Jam

Am Freitag rahmen Sie Fragen mit Wie-könnten-wir-Fragen. Am Samstag gehen Sie mit einer Service Safari hinaus und bauen dann mit einem Storyboard oder einem Rollenspiel. Teams, die zeigen wollen, wie ihr Service wirklich laufen würde, können mit einem groben Service Blueprint abschließen. Für das größere Bild der Formate beginnen Sie mit dem Überblick über Hackathons, Jams und Challenges.