Was wir bei 25th-floor über Firmen-Hackathons gelernt haben


Post Image

Im Jänner 2015 haben wir uns bei 25th-floor entschieden, jedes Monat einen firmeninternen Hackathon zu veranstalten. Wir hatten zwar schon in der Vergangenheit den einen oder anderen “Hack-Day”, allerdings ohne fühlbares Ergebnis. Diese vorangegangenen Versuche haben wir nur sporadisch, ohne Struktur und eine klare Idee darüber, wie so etwas denn gemacht werden könnte, durchgeführt.

Lange Zeit hatten wir auch versucht, die berühmte 20%-Zeit zu kultivieren und dafür Platz zu schaffen. Jeder hätte 20% seiner monatlichen Arbeitszeit für F&E-Projekte aufwenden können – was für ein kleines Unternehmen wie 25th-floor ziemlich viel ist. Obwohl jeder Feuer und Flamme für die Idee war und sein Bestes dazu beigetragen hat, scheiterte dieser Versuch am Ende aus den unterschiedlichsten Gründen. Im Nachhinein betrachtet haben wir viel zu lange an dieser Idee festgehalten, anstatt schon viel früher mit anderen Ideen zu experimentieren.

Die folgenden Tipps geben einen kleinen Einblick in unsere Firmenkultur, unseren aktuellen Ansatz Hackathons als fixes, monatliches Event zu etablieren und die ständige Auseinandersetzung mit neuen Themen – abseits des persönlichen Engagements – zu fördern.

1. Kontinuierliche Auseinandersetzung mit möglichen Themen

Ein Bereich einer unserer großen Wände im Büro (dieselbe, die auch für den Beamer verwendet wird) ist auschließlich für Post-Its mit potentiellen Hackathon-Themen reserviert. Jeder ist eingeladen, den Platz mit neuen Ideen zu füllen und bereits vorhandene Themen durchzudenken.

Dabei kann es sich um alles Mögliche handeln: die Integration von D3.js in ein bestehendes Produkt, ausprobieren einer neuen Sprache oder eines Frameworks, React mit AngularJS via ngReact zu verbinden, und so weiter. Man findet auch projektbezogene Themen, wenn Teammitglieder immer schon ein bestimmtes Feature bzw. eine Erweiterung in einem Kunden-Produkt/-Projekt sehen wollten.

2. Zeit nehmen und regelmäßig durchführen

Wir haben auch die Art und Weise geändert, wie wir so einen Hackathon einplanen und Zeit dafür reservieren. Anstatt nur darüber zu lamentieren, dass es doch gut wäre, wieder einmal was zu machen, legen wir nun gemeinsam während jedem zweiten Sprint Planning (alle 4 Wochen) fest, wann der Hackathon im angehenden Sprint stattfinden wird. Diese Vorgehensweise hat bis Juni 2015 bereits zu 5 erfolgreichen Hackathons geführt – nur einen mussten wir wegen zu vieler Urlaube ausfallen lassen.

3. Rechtzeitig mit Kunden und Partnern kommunizieren

In jedem Unternehmen gibt es Daily Business und Dinge, die erledigt werden müssen. Da wir agil arbeiten, fällt es uns nicht schwer, beim Sprint Planning von der normalen Arbeitszeit einen Tag wegzudenken, um für den Hackathon Platz zu schaffen . Dazu kommen aber noch Support-Anfragen, Mails die gelesen und beantwortet werden müssen, Telefonate und Kundengespräche, usw.

Informiert eure Kunden und Partner rechtzeitig darüber, dass euer Unternehmen/euer Team/eure Abteilung an diesem Tag nur bedingt erreichbar ist, Mails erst am nächsten Tag beantwortet werden und der Support auf das Minimum reduziert ist.

Abgesehen davon, dass Kunden dadurch nicht vor den Kopf gestoßen werden wenn z.B. der Product Owner trotz Anwesenheit mal nicht erreichbar ist, kommuniziert ihr euren Kunden und Partnern gleichzeitig, wie wichtig euch die kontinuierliche Weiterentwicklung und das ständige Lernen ist.

4. Alle zusammenbringen

Bei 25th-floor legen wir einen besonderen Fokus auf die Teamkultur. Das mag jetzt nach Werbung klingen – ist aber so. Ihr könnt euch gerne selbst davon überzeugen. Deshalb war und ist es bei uns ein Leichtes, alle zusammenzubringen. Erleichternd kommt hinzu, dass wir ein kleines Team sind.

Bei einem Hackathon kommt es auf die “shared experience” an, weshalb möglichst die ganze Firma/die ganze Abteilung/das ganze Team diese Veranstaltung gemeinsam gestalten und leben sollte. Warum sollten Kollegen vom Support, Backoffice, Management usw. ausgeschlossen bleiben? Mit Sicherheit gibt es in diesen Bereichen auch Hackathon-Themen oder die Kollegen und Kolleginnen können einmal ganz ungeniert bei technischen Themen ihre Sichtweise einbringen.

5. Einen “Open Space” ermöglichen

Am Tag des Hackathons – meistens ein Freitag – hat jeder eine grobe Idee aller möglichen Themen auf der Post-It-Wand und was sein/ihr Thema für den Tag sein könnte. Der Hackathon selbst beginnt um 10.00 Uhr (sharp) damit, dass Leute sich ein Post-It mit einem Thema, das sie angehen möchten, aussuchen und kurz nochmal allen erklären, was sie erreichen wollen. Jemand der kein Thema “führt”, wird eingeladen, einem anderen Thema beizutreten, um ein kleines Team zu bilden und gemeinsam daran zu arbeiten.

Themensammlung

Am Ende dieser Phase gibt es bei uns sowohl Hackathons mit (fast) nur Ein-Mann/Frau-Teams, oder ein paar kleinere Gruppen aus 2-3 Leuten rund um dasselbe Thema – Vorgaben oder Regeln gibt es dafür keine.

6. Durch den Tag iterieren

Eine Iteration, ein Sprint wenn man so will, dauert 90 Minuten. Am Ende jedes Sprints treffen sich alle in der Küche (in unserem Fall gleichzeitig der sehr große Besprechungsraum) und halten ein kurzes Daily. Irgendjemand beginnt einfach damit, seinen Fortschritt bzw. den Fortschritt des jeweiligen Teams, erste Erfahrungen und/oder Probleme mit dem Thema bzw. der Herangehensweise mit dem gesamten Team zu teilen.

Manchmal stellt sich heraus, dass das Thema zu weit herggeholt war, überschätzt wurde, zu kompliziert oder zu einfach war, mehr Vorbereitungszeit bräuchte etc. In diesem Fall, wenn das nicht schon innerhalb der 90 Minuten passiert ist, werden Post-Its weggeworfen, als erledigt markiert oder einfach wieder an die Wand zurückgeklebt und gegen ein neues getauscht. Auch wechseln spätestens zu diesem Zeitpunkt Teammitglieder schon mal zu anderen Themen und formen eine neue Gruppe.

Ein Hackathon besteht aus 4-5 dieser Sprints. Zwei vor dem gemeinsamen Mittagessen und nochmal zwei bis drei bis zum Ende des Tages. Die kostbare Zeit beim Mittagessen wird dazu genutzt, auch gleich ein Daily zu halten, bevor es mit dem nächsten Sprint weitergeht.

Hackathon-Road

7. Fehlschläge und Scheitern – so what?

“I have not failed 10,000 times; I’ve successfully found 10,000 ways that will not work” – Thomas Edison

Wer agil denkt, der verinnerlicht schnell die Maxime “fail fast, fail often”. Ganz in dieser Tradition verwurzelt, haben wir diese Einstellung auch in unsere Hackathons übernommen. Das bedeutet nicht, dass wir ohne Ziel und Plan an die Sache herangehen. Vielmehr bedeutet es, dass wir nach jedem Hackathon etwas Neues dazulernen, auch wenn manchmal am Schluss bei einzelnen Themen kein greifbares Resultat herauskommt. Zum Beispiel wollten wir beim letzten Hackathon eine Angular-D3 Library veröffentlichen, nur um am Ende festzustellen, dass sich einer unserer Kollegen verrannt hatte. Gelernt haben wir aus dieser Erfahrung aber allemal. Die Library hatte ihre Grenzen erreicht.

Fehlschläge und Scheitern sind wichtige Teile der ganzen Erfahrung und etwas wovor man keine Angst haben darf. Wir versuchen laufend neue Dinge zu lernen, was auch bedeutet, dass wir dabei und damit manchmal scheitern.

8. Teilen und wertschätzen

Der Tag endet mit der Präsentation der einzelnen (Team-)Ergebnisse. Jede(r) sitzt mit seinem/ihrem MacBook in der Küche und ist meistens stolz darauf, die Arbeit des Tages allen anderen zeigen zu können.

Die Ergebnisse unserer bisherigen Hackathons können sich sehen lassen. Wir hatten Hackathon-Projekte, die großartige Talks bei lokalen Entwickler-Meetups und Konferenzen inspiriert, zu Forks und Pull-Requests bzw. dem Erstellen neuer, öffentlicher Projekte auf GitHub geführt haben.

Wir wurden in manchen Fällen sogar im Nachhinein von Kunden finanziell wertgeschätzt, obwohl wir das neue Feature so oder so in das jeweilige Produkt einfließen hätten lassen – unsere Kunden fanden die Idee und die Umsetzung großartig und haben eine Rechnung über den Betrag, der es ihnen wert war, bekommen.

Abgesehen davon ist es ein großartiges Thema, um in unserem ersten Blog-Post darüber zu schreiben!

9. Den Erfolg auch mal feiern

Lasst den Tag angenehm und locker ausklingen. Eine Movie-Night mit dem HD-Beamer, auf der Playstation gemeinsam GTA zocken, ein After-Work-Drink mit dem Team, die alten Office-LAN-Party-Zeiten wieder hochleben lassen …

10. Experimentieren und den eigenen Weg finden

Jedes Unternehmen und jedes Team, das dieses F&E-Format ausprobieren will, ausprobiert hat oder schon lange als Teil der Firmenkultur übernommen hat, wird das Konzept und die Herangehensweise jedes mal aufs Neue verfeinern – und das ist gut so.

Es können daraus noch großartigere, noch spannendere Events entstehen, wie z.B. 24-Stunden-Hackathons (z.B. //SEIBERT/Media), Zwei-/Drei-Tages-Hackathons oder gleich eine ganze Woche am Balaton (z.B. Camp404 von DieSocialisten.at). Die Gestaltungsmöglichkeiten sind endlos!





Share this page