Ein Hackathon ist eine gute Idee, um über den Tellerrand zu schauen. Diese Art der Weiterbildung soll bei agido vermehrt Einzug halten. Den ersten Hackathon konnten wir erfolgreich durchführen und beenden. Es hat allen Spaß gemacht und sicher ist: Das machen wir noch einmal! Als Ergebnisse können Wissenszuwachs, Experimentieren mit neuen/anderen Werkzeugen, ein Tool zur Unterstützung der täglichen Arbeit verbucht werden. Dabei kam auch die soziale Komponente nicht zu kurz.
Kurzum: Der Hackathon deckte viele Bereiche für eine erfolgreiche Firmenkultur ab.

1. Hackathon bei agido

Ein Hackathon im ursprünglichen Sinne (lt. Definition in Wikipedia) ist eine Veranstaltung, bei der Entwickler und andere, an der Softwareentwicklung beteiligte Personen, zusammenkommen, um gemeinsam ein Projekt innerhalb eines Zeitraums von 24 Stunden bis 1 Woche möglichst weit nach vorne zu bringen. Hackathons sollen primär soziale oder weiterbildungsnahe Events sein, die zu entwickelnde Software hat jedoch häufig außerdem den Anspruch, für einen späteren Nutzen tauglich zu sein. Des Weiteren erheben Hackathons oft den Anspruch eines gewissen Ziels. Dieses Ziel ist nicht näher definiert und kann alles sein (Programmiersprache, Framework, Zielplattform, Betriebssystem, Datenbank, Vorgehensweisen, API, aber auch z.B. Anwendungsbereiche oder Zielgruppen). Zum Schluss werden die Ergebnisse der Teams vorgestellt und verglichen. Grundsätzlich beschränkt sich ein Hackathon laut Definition aber auf die Softwareseite.

Der Ablauf eines Hackathons beginnt in der Regel mit der Vorstellung des Events und des Projekts, das entwickelt werden soll. Danach spalten sich die Teilnehmer nach ihren Eigenschaften und Interessen in verschiedene Teams auf. Nun kann die eigentliche Arbeit beginnen, das Coding. Schlafen und Essen ist Nebensache. Nach Ablauf der Coding-Zeit präsentiert jedes Team seine Ergebnisse und ggf. wird ein Sieger gewählt und Preise vergeben.

(Quelle: http://en.wikipedia.org/wiki/Hackathon)

Als agido Geschäftsführer Thomas Louis von der Idee des Hackathons hörte, konnte er sich gleich dafür begeistern und schlug eine solche Veranstaltung der Belegschaft vor. Diese war zwar zunächst etwas skeptisch bezüglich des Ablaufs etc., jedoch waren die meisten sofort interessiert. Schnell wurde ein Tag und die Zeitspanne von ca. 24 Stunden festgelegt. Donnerstags sollte es um 10 Uhr losgehen, die Präsentationen wurden für Freitag um 11 Uhr geplant. Alle Kollegen, die mitmachen wollten, planten ihre „normale“ Arbeit entsprechend, so dass Zeit für den Hackathon blieb. Die Geschäftsführung kam den Mitarbeitern in Sachen Abrechnung der Arbeitszeit entgegen, so dass niemand für das Event Urlaub nehmen musste. 

Zur Vorbereitung wurden 3 noch nicht namentlich erwähnte Projekte in Github angelegt, um die spätere Arbeit und den Austausch der Ergebnisse zu erleichtern.

Dann kamen die 25 Stunden des Hackathons.

Donnerstag, 10:00 Uhr:

Alle teilnehmenden Mitarbeiter treffen sich zur Eröffnung des Hackathons. Das Event wird vorgestellt und die letzten Unklarheiten werden beseitigt. Bei schwierigen Fragen setzt man auf demokratische Abstimmung, so dass zum Schluss die Mehrheit der Belegschaft die Entscheidungen trägt.

10:30 Uhr:

Die Projekte für den Hackathon werden vorgestellt. Statt nur eines Projekts, das von unterschiedlichen Teams in einer Art Challenge bearbeitet wird, gibt es 3 mögliche Projekte, die bearbeitet werden sollen: Time Tracker, Fußball-App, Planning Poker.

• Time Tracker: Unsere Arbeitszeiterfassung soll überarbeitet und erweitert werden. Dabei soll das reaktive Manifest zum Einsatz kommen, neue Technologien sollen auf ihre Tauglichkeit geprüft werden etc.
• Fußball-App: Es soll eine App entwickelt werden, die Fußballergebnisse zusammen stellt und Nutzern die Möglichkeit für Spiel-Kommentare gibt. Sie soll jedoch zunächst aus Zeitgründen auf ein Minimum an Features reduziert werden. Welche Features das sind, ist im Rahmen des Projekts zu erörtern. Fest steht eine Anbindung an Magnolia als CMS.
• Planning Poker: Bei unserer täglichen Arbeit ist es innerhalb der Teams notwendig, den Zeitbedarf für Implementierungen abzuschätzen, um sie anbieten zu können. Alle Teammitglieder schätzen dabei, wie viel Zeit für Analyse, Kommunikation, Umsetzung und Test benötigt wird. Angeboten wird später ein „realistischer“ Mittelwert, d.h. Ausreißer in den Schätzungen werden ignoriert, aus dem Rest wird ein Mittelwert gebildet. Um dies nicht immer manuell oder mit Excel machen zu müssen, wäre eine App hilfreich, die die zu schätzenden Aufgaben aus dem Ticket-System ermittelt. Jedes Teammitglied kann dann über sein Smartphone die Aufwände schätzen, die App ermittelt die mittleren Werte.

11:00 Uhr:

Die Projektvorstellungen sind durch. Es gibt eine kurze Pause, in der sich die Mitarbeiter überlegen sollen, bei welchem Projekt sie einsteigen wollen.

11:20 Uhr:

Die Teambildung startet. Es wird relativ schnell klar, dass 2 Projekte eigentlich ausreichend sind. Da nicht die gesamte Belegschaft am Hackathon teilnehmen kann, sind wir 13 Entwickler und verteilen uns 5:8 auf die Projekte Planning Poker und Fußball-App. Nachdem dies geklärt ist, fangen wir an, unsere PCs und Notebooks in die Teambüros zu verlagern und die technische Infrastruktur bereit zu stellen.

12:00 Uhr:

Die Teams haben sich in ihren Büros eingerichtet, die Analysephase der Projekte beginnt.

Beim Fußball-App-Team wird zunächst recherchiert, was es schon gibt, was wünschenswert für einen Anwender wäre und was realistischer Weise umgesetzt werden kann.

Das Planning Poker-Team kann die Recherche weitestgehend überspringen, da man aus der täglichen Arbeit bereits die Anforderungen kennt. Hier kann man damit starten, sich über die Architektur Gedanken machen. In diesem Team entbrannte daher eine Diskussion, ob man überhaupt eine Serverkomponente brauche oder ob sich die Clients direkt unterhalten. Man kam jedoch relativ schnell überein, dass eine Serverkomponente benötigt wird.

In beiden Teams müssen zudem Entscheidungen zu den einzusetzenden Technologien fallen. Da das Wissen über AngularJS in der Firma verbreitert werden soll, steht die Programmiersprache auf Clientseite recht schnell fest.

Weitere Entscheidungen sind bei der Fußball-App: evtl. MongoDB als Data Storage (Hadoop wurde relativ schnell verworfen, da das Aufsetzen eines Hadoop Clusters zu viel Zeit in Anspruch genommen hätte), alternativ soll eine HSQL-Datenbank eingesetzt werden. Als Versionsverwaltung soll Git eingesetzt werden, das bereits aus dem Arbeitsalltag bekannt ist. Genutzt werden sollen in diesem Zusammenhang eines der zuvor in Github angelegten Projekte. Die IDE soll nicht Eclipse sein, da dies allen bekannt ist. Es soll WebStorm ausprobiert werden, was die Programmierung mit AngularJS gut unterstützt. Die Client-Server-Kommunikation soll über WebSockets realisiert werden. Als Importfile für die Angaben zu Fußballspielen soll openliga.db ausprobiert werden. Da auch ein User Generated Content angeboten werden soll, kommt als CMS Magnolia 5 mit ins Boot. Es soll außerdem die Anbindung von Magnolia mit Angular ausprobiert werden.

Eingesetzte Technologien im Planning Poker sollen sein: IntelliJ statt Eclipse, aus denselben Gründen wie beim anderen Team. Für die Konfiguration der Anwendung soll statt Maven Gradle eingesetzt werden. HSQL soll die Datenbasis liefern. Gebaut wurde im Endeffekt eine Spring Boot Anwendung. Die Anbindung an das Ticket-System Jira soll mit JSQL (Anbindung mit der Atlassian JIRA API) gemacht werden.

13:00 Uhr:

Das Team der Fußball-App wird um ein Teammitglied dezimiert. Der Kollege hat einen nicht verschiebbaren Termin. Er übergibt die Diskussionsleitung einem anderen Teammitglied. Man steckt noch mitten in der Recherche.

Das Team des Planning Pokers fängt mit dem Design auf dem Whiteboard an. Dort stehen 2 Worte: Client und Server, dazwischen ein Strich. Es geht nun primär darum, die Schnittstelle zwischen Client und Server zu definieren. Der Plan ist, dass nach der Definition die Teammitglieder in ein Client- und ein Server-Subteam aufgeteilt werden. Zunächst will man sich aber um das Mittagessen kümmern.

13:45 Uhr:

Das Fußball-App-Team ist mit der Recherche und der Festlegung der zu implementierenden Features fertig. Man beschließt, kurz etwas zu essen und dann mit Ausprobieren und Hacken anzufangen.

Das Planning Poker Team wartet auf die Pizzabestellung. Bevor die Schnittstelle definiert wird, wird wild herum probiert, was man wie einsetzen könnte. Es wird viel recherchiert und experimentiert. Es entsteht ein Grundgerüst einer clientseitigen AngularJS App und einer serverseitigen Spring Boot App, die mit Gradle als Buildsystem erstellt wurden. Nun kann gegessen und im Anschluss definiert werden.

14:00 Uhr:

Das Fußball-App-Team ist satt und beginnt, ein Angular-Projekt mit Git aufzusetzen. Außerdem muss die IDE installiert und alles weitere für das eigentliche Hacken vorbereitet werden.

15:00 Uhr:

Das Fußball-App-Team nimmt das Hacken nun auch in Angriff. Auf allen Rechnern ist WebStorm installiert, die Codebasis wurde aus Git importiert und es konnte los gehen. Die Features wurden definiert und finden sich auf dem Whiteboard. Ebenfalls findet sich dort eine Darstellung des Datenflusses. Zunächst geht es aber darum, AngularJS kennen zu lernen und einfach auszuprobieren, was möglich ist und wie Angular arbeitet. Da es einen Mitarbeiter gibt, der sich mit Angular auskennt, unterweist dieser die anderen, so dass der Einstieg einigermaßen leicht fällt.

Auch beim Planning Poker ist die Pizza vernichtet. Die Schnittstelle ist fertig und das Team teilt sich noch einmal auf (s. o. Client-Team, Server-Team). Dank der Schnittstellendefinition kann jeder die Gegenseite mocken und fröhlich drauf los hacken.
Das Team stürzt sich begeistert in die Arbeit.

15:45 Uhr:

Der Chef hatte ein Vorstellungsgespräch und führt den Bewerber durch die Firma. Er bietet ihm an, spontan am Hackathon teilzunehmen, um die Angestellten besser kennen zu lernen. Da am Whiteboard des Planning Poker-Teams nur zwei einsame Worte stehen, entscheidet sich der Bewerber, bei den Fußball-App-Leuten mitzumachen.

16:30 Uhr:

Ziel beim Planning Poker ist es, nun möglichst schnell den geplanten Workflow zu implementieren. Einzelne Komponenten können dabei zunächst auch "simpel" gelöst werden.

Das Fußball-App-Team wird um ein Teammitglied dezimiert. Die Kollegin hat noch einen privaten Termin, will aber voraussichtlich wieder kommen.

17:00 Uhr:

Beim Planning Poker entwickelt ein Teammitglied eine temporäre Speicherung der Daten. Dies ist die Eigenimplementierung einer InMemory-DB, die nach ihrem Schöpfer liebevoll die “Schallab-DB” genannt wird. Eine persistente Speicherung der Daten ist für die Anwendung nicht unbedingt nötig.

Das Fußball-App-Team wird wieder um ein Teammitglied ergänzt. Der eine Kollege hat alle privaten Termine erledigt und stößt wieder zum Entwicklungsteam dazu. Zwischenzeitlich haben die restlichen Teammitglieder angefangen, den Workflow umzusetzen.

18:00 Uhr:

Das Planning Poker-Team wird um ein Teammitglied dezimiert. Der Student muss zur Uni, was er bedauert, sich aber nicht ändern lässt. Außerdem wurde mittlerweile beschlossen, dass eine persistente Datenspeicherung doch ganz schön wäre, um später Dinge noch einmal nachzuvollziehen. Die “Schallab-DB” soll gegen HSQL getauscht werden. Hier stellt das Team fest, dass der Austausch dank Spring Data recht einfach ist.

21:30 Uhr:

Erneut stößt wieder ein Teammitglied des Fußball-App-Teams dazu. Das Team hat bereits eifrig weiter gearbeitet. Der Wiedereinstieg fällt einigermaßen leicht.

Der Großteil der Anwesenden aus beiden Teams beschäftigt sich aber bereits geistig mit dem in Bälde beginnenden WM-Eröffnungsspiel. Der Fernseher im Konferenzraum wird schon mal vorgewärmt und der Grill angeschmissen.

22:00 Uhr:

Fast alle holen sich was Schönes vom Grill und gucken das Eröffnungsspiel der WM 2014. Der verbliebene Rest hackt noch ein bisschen rum und gesellt sich dann zu den Fußball-Guckern oder geht ermüdet nach Hause.

Freitag, 00:00 Uhr:

Das Planning Poker Team probiert die Schnittstelle zum ersten Mal aus. Bemerkenswert ist dabei, dass beide Sub-Teams ungefähr gleich schnell waren, so dass sie etwa zur gleichen Zeit fertig waren.

Die Fußball-App Leute erstellen eine Client-Server-Schnittstelle auf Zuruf.

Freitag, 3:00 Uhr:

Der harte Kern hat nach dem Spiel noch die letzten Implementierungen gemacht. Beim Planning Poker handelte es sich hier leider um eine eher denk-intensive Komponente, die einiges an Gehirnschmalz erforderte. Um 3 Uhr war das Ende der Fahnenstange erreicht: Denken war nicht mehr möglich, das Ergebnis war für die fortgeschrittene Stunde sehr ordentlich. Daher brachen alle auf, um vor der Präsentation der Projekte am nächsten Morgen noch ein Mützchen Schlaf einzufahren.

9:00 Uhr:

Die “Hacker”, die früh nach Hause gegangen sind, kommen wieder. Da man den weiteren Verlauf des vorigen Abends nicht ganz mitbekommen hat, wundert man sich, wo alle sind. Die Präsentation der Ergebnisse ist für 11 Uhr angesetzt. Bis dahin ist noch Zeit, alles wieder umzuräumen und sich vorzubereiten.

Planning Poker baut noch schnell ein paar optische Features ein und haut die letzten Bugs raus.

11:00 Uhr:

Beide Teams präsentieren ihre Ergebnisse. Es wird über die Erfahrungen diskutiert. Im Anschluss gibt es noch eine Feedbackrunde.

13:30 Uhr:

Wir sind fertig und freuen uns auf das Wochenende. Alle ziehen eine positive Bilanz.

Das Fußball-App Team probiert die Schnittstelle zum ersten Mal während der Präsentation aus - sie läuft! Primäres Ziel dieser Mannschaft war der Wissenszugewinn und Lerneffekt.

Das Planning Poker Team stellt ein gut laufendes System vor, das sogar mehr Features hat, als ursprünglich geplant. Primäres Ziel dieser Mannschaft war neben dem Lerneffekt ein produktiv einsetzbares Werk für die Unterstützung der täglichen Arbeit zu schaffen.

Der Hackathon hat bei allen Mitarbeitern großen Anklang gefunden. Da agido die Veranstaltung zum ersten Mal durchgeführt hat, gab es natürlich noch einiges, was beim nächsten Mal anders gemacht werden kann oder soll. Grundsätzlich besteht aber Einigkeit, dass es ein nächstes Mal geben soll (wenn nicht muss). Denn: Nach dem Hackathon ist vor dem Hackathon.

Die Ergebnisse im Einzelnen:

Fußball-App:

Eingesetzte Technologien:

• Frontend: AngularJS, CSS, JaxB, JSON
• Backend: WebSockets, Spring
• Versionsverwaltung: GIT
• Datenspeicherung: HSQL DB, Magnolia 5
• Datenquelle: openliga.db, football24
• IDE: WebStorm

Teammitglieder: 8

Planning Poker:

Eingesetzte Technologien:

• Frontend: AngularJS
• Backend: Spring Boot, Spring Data
• Build-Automatisierung: Gradle
• Datenspeicherung: “Schallab-DB”, HSQL DB
• Datenquelle: Jira -> JQL für Zugriff
• IDE: IntelliJ

Teammitglieder: 5

Die Feedbackrunde am Ende hat folgende Erkenntnisse geliefert:

PRO:

• Idee des Hackathons ist toll
• Bezüglich der Arbeitszeitverrechnung wurde ein guter Kompromiss gefunden
• Überraschend viel Neues kennengelernt
• Viel gelernt
• Gute Organisation
• Team Planning Poker ist weiter gekommen, als die Mannschaft erwartet hätte
• Team Planning Poker lobt die gute Teamarbeit und Projektorganisation
• Tolle Atmosphäre, besonders bei der Nacht-Programmierung
• Teamgröße mit 5 Leuten war gut
• Eigene Ziele und Vorstellungen konnten erreicht werden
• Kreatives Chaos

CONTRA:

• Teamgröße mit 8 Leuten war zu groß, 4 wäre besser
• Thema der Fußball-App war oversized, der Umfang der Projekte muss eingeschränkt werden
• Teamarbeit bei Fußball-App verbesserungsbedürftig
• Vorher das Team in Sub-Teams teilen, damit feststeht, wer was macht (-> Produktivitätsgewinn)
• Vor dem Hackathon eine Grundvorbereitung machen, Schwerpunkte setzen o.ä. (-> bringt uns mehr für den Arbeitsalltag)
• Es war sehr viel unklar. Die Rumprobiererei war teilweise nicht zielführend und verursachte dadurch eher Frust. Die eigene Produktivität war nicht zufriedenstellend.
• 24 h waren zu kurz, bzw. die Rüstzeit bis man zum eigentlichen Hacken kam war zu lang. Könnte man länger hacken, ergäbe sich wahrscheinlich ein besseres/produktiveres Ergebnis.
• Im Fußball-App-Team gab es zu wenig Kommunikation, darunter litt das Ergebnis
• Die Koordination war teilweise nicht besonders gelungen
• Es war z.T. zu viel Neues. Schön wäre bei neuen Technologien, wenn man anfangs einen Coach hätte, der in das Thema einführt und die ersten Schritte erleichtert.