Am sechsten September des Jahres 1620 (nach gregorianischem Kalender) stach das Segelschiff „Mayflower“ mit den Pilgervätern unter englischer Flagge in See. Ziel war es, von Plymouth aus Virginia zu erreichen; stattdessen lief man vor der Küste Cape Cods auf. Die Überfahrt war mit vielen Entbehrungen und Schicksalsschlägen verbunden. Dennoch gilt gerade jene Schiffsreise als das Exempel europäischer Besiedlung des amerikanischen Raums schlechthin.
Fast 400 Jahre später treffe ich die sagenumwobene Fleute aus meinem Englisch-Lehrbuch der Mittelstufe wieder: Ich studiere BA Informatik Game Engineering an der Hochschule Kempten und darf im Rahmen des Praxis-Semesters ein Praktikum bei einer Softwareentwickler-Firma absolvieren. Auf lange Suche nach einer Anstellung im Bereich Game Development und einem herben Rückschlag auf einem sehr obskuren Kahn folgt plötzlich die große Chance für mich …
Aus dem Segelschiff Mayflower ist ein angesehener Software-Dienstleister geworden. Ich sehe die Möglichkeit, dort als Schiffsjunge anzuheuern und bewerbe mich. Es soll mittlerweile sogar drei Schiffe … äh, Standorte geben: Berlin, Würzburg und München; an letzteren schicke ich meine Bewerbungsunterlagen. Nach einer Einladung an Deck der Mayflower München bin ich hellauf begeistert: Mich interessiert der Prozess von der Anforderung zum fertigen Produkt. Man zeigt Interesse an mir und meinem Fortkommen und stimmt meiner Aufnahme zu. Mitte September 2019 (welch wundervoller Zufall) breche ich mit der Mayflower zu neuen Ufern auf. Im Folgenden möchte ich etwas über meine bisherige Zeit an Bord erzählen.
An Bord der Mayflower
Mayflower hat sich der agilen Softwareentwicklung verschrieben und fährt unter der Flagge, vielmehr dem oft und viel angebrachten Visionsspruch:
„Wir führen Unternehmen in die Zukunft – mit modernen Technologien und agiler Organisation.“.
Man arbeitet primär nach Scrum und Kanban, beides wichtige Vorgehensmodelle des Projekt- und Produktmanagements. Im Projekt gibt es dann einen oder mehrere Scrum Master, Product Owner und das Entwickler-Team. Während meiner Reise auf See darf ich Einblicke in die Geheimnisse agiler Entwicklung und Arbeit an Kundenprojekten erhalten und bekomme sogar einen Anteil des erbeuteten Goldes. An Land habe ich in diversen Hochschul-Modulen (Stichwort: Softwaretechnik I und II!) theoretische Inhalte der Softwareentwicklung vermittelt bekommen, die ich auf hoher See nun praktisch erleben und selbst durchführen darf.
Ich habe einen „Paten“ bekommen, der mich in der Anfangszeit nach Kräften unterstützt und angeleitet hat. Er ist schon lange Jahre bei Mayflower, hat dort sogar selbst sein Praktikum gemacht. Er hat mich mit meinem eigenen Device und nötigem Handwerkszeug ausgestattet.
Aber wie darf man sich ein Praktikum bei Mayflower genau vorstellen? Wie sieht eine Woche im Büro aus? Was erwartet einen Praktikanten oder eine Praktikantin an Deck? Genau darüber möchte ich jetzt mehr berichten.
Arbeit am Kundenprojekt oder: Dein Arbeitstag bei Mayflower
Nach dem ersten Kontakt mit einem potenziellen Klienten wird verhandelt, ob ein neues Softwareprojekt zustande kommt. Ist das der Fall, werden in intensiven Gesprächen und Workshops die Anforderungen des Kunden an die zu entwickelnde Software erarbeitet. Sie werden dann in User Stories verwandelt und in einem Speicher, dem sogenannten Backlog, in Form von Tickets festgehalten. Dort kann man sie dann in „Sprints“ sukzessive angehen und den Backlog leeren. Apropos …
Was ist ein Sprint?
Ein Sprint ist ein iterativer Arbeitsschritt innerhalb eines zeitlich festen Rahmens. Das können zum Beispiel 30 Tage oder auch „nur“ zwei Wochen sein. Jeder Sprint zielt darauf ab, einen Teil des Backlogs abzuarbeiten. Aber wie läuft ein solcher Sprint eigentlich ab? Das lässt sich leichter erklären, wenn wir mit dem Abschluss eines solchen beginnen.
Zum Ende eines Sprints werden im Zuge des sogenannten Sprint-Wechsels zwei wichtige Meetings abgehalten: Zum Einen die Sprint Review, bei der das Team dem Kunden im Beisein der Scrum Master und POs die neu implementierte Funktionalität vorstellen. Zum Anderen wäre da die (Sprint-)Retrospektive für das Team. Man teilt seine Erfahrungen mit den anderen Team-Kollegen, thematisiert positive Aspekte und aufgekommene Schwierigkeiten, an denen man im nächsten Sprint-Zyklus arbeiten möchte.
Sprint Plannings für den nächsten Abschnitt schließen sich an, am Folgetag beginnt dann auch endlich der neue Sprint. Jeden Tag (bis auf den des Wechsels) wird im Team ein Meeting aller Mitglieder, das sogenannte Daily, einberufen. Im Daily spricht jeder Kollege über das Ticket, an dem er gerade arbeitet, was er bereits geschafft hat und welchen Stand er für das darauffolgende Daily plant. Oft geschieht das in Video-Konferenzräumen, aber auch physisch an einem festen Ort.
Dabei übernimmt man ein Ticket und setzt es um. Es gibt ein Scrum-/Kanban-Board, auf dem die Tickets in ihrem Life Cycle mehrere Stationen durchlaufen. Dazu jetzt ein kleines Bisschen mehr.
Das Board
Jedes Ticket aus dem Backlog befindet sich anfangs an der Station „To Do“. Aus der Station nimmt sich ein Teammitglied ein Ticket und bearbeitet es. Dann kann es auf dem digitalen Brett dem entsprechenden Kollegen zugeordnet und unter „In Progress“ verbucht werden. Ist der Entwickler der Meinung, das Ticket implementiert zu haben, berichtet er das – im Optimalfall beim darauffolgenden Daily – und schiebt es in die nächste Sektion, „Ready for Review“.
Ein anderes Mitglied schnappt sich die Story nun und testet den geschriebenen Code im Code Review. Dann kann das Ticket wieder disponiert werden, diesmal zur Station „In Review“. Ist der Code einer hinreichenden Überprüfung unterzogen worden, kann der Tester sie bei aufgekommenen Fehlern zurückschicken oder absegnen (Daily!) und dann als „Done“ aus den Issues des aktiven Sprints entfernen.
Ein wichtiges wöchentliches Ereignis im Sprint stellt das Refinement dar. Wie funktioniert das?
Das Refinement
Beim Refinement werden die Story Points einer jeden Story aus dem Backlog bezüglich ihres Aufwands geschätzt. Da nicht immer alle Entwickler vor Ort sein können, hält man die Konferenz für gewöhnlich remote ab. Die einzelnen Stories werden von den POs vorgestellt, ein Scrum Master achtet auf Zeit und Einwürfe der Teilnehmer. Hier kommt der interessante Aspekt der Meetings.
Die Stories wollen ja geschätzt werden, wofür man ihnen eine Punktzahl zuordnet. Das geschieht beim Planning Poker. Jeder Teilnehmer bekommt ein Set Karten; auf jeder Karte ist eine Zahl –nach Fibonacci von eins bis 13 –, eine Karte enthält ein Fragezeichen. Für die Schätzung wählt jeder den Kartenwert, den er persönlich dem Aufwand der jeweiligen Story zuordnen würde; man sammelt die Ergebnisse und diskutiert, um eine Einigung herbeizuführen.
Die Remote-Teilnehmer tun das ebenfalls, allerdings mit virtuellen Karten auf einer Scrum Poker-Website. Das durfte ich selbst einmal übernehmen. Ich habe die Stories im Programm benannt, Schätzungen freigegeben, die Schätzergebnisse gesammelt und an die POs weitergeleitet. Sind alle im Zeitrahmen geschätzten Stories abgehandelt, hat man einen guten Überblick über den jeweiligen Aufwand einer solchen und kann darauf basierend weiter planen.
Mein Praktikum
Ich habe in den letzten Wochen an Pair Programmings, Code Reviews und Architektur-Workshops teilgenommen und durfte tief in die Materie der agilen Softwareentwicklung einsteigen. In Eigenstudium habe ich mir die Arbeit mit Git, Docker, WordPress und CSS (Cascading Style Sheets) angeeignet und meine Erfahrungen in Form von Wochenzusammenfassungen niedergeschrieben.
Ein neues Projekt wurde in‘s Leben gerufen. Seit dessen Bildung bin ich als Webentwickler dabei, interagiere in enger Zusammenarbeit mit dem Kunden. Wir halten uns an Scrum mit Kanban-Board, alles sorgfältig strukturiert und agil. Was ich hier lerne, wird mich optimal auf‘s Berufsleben vorbereiten, da bin ich mir sicher.
Mayflower hat mir viele starre Konzepte aus den Modulen der Hochschule lebendig und in professioneller Version gezeigt: Dass man eben beispielsweise Scrum nicht stur by the book, sondern an das Kundenprojekt angepasst, sprich agil, durchführt; dass das Daily aus mehr als den drei obligatorischen Fragen besteht; wie wichtig Team Play wirklich ist; und, dass niemand allein gelassen wird. Wir sind ein Team, Du gehörst dazu. Lass‘ uns das anpacken.
Mayflower achtet auf seine Kollegen. Jeder hat einen Platz und Stellenwert. Gibt es Probleme, kann man sich jederzeit an die anderen wenden, nicht nur Dein Pate hilft Dir. Du bist hier jemand, egal, welche Voraussetzungen Du mitbringst. Hier gelten flache Hierarchien. Damit kommen wir zu einem weiteren Aspekt, der Mayflower neben der Agilität zentral auszeichnet …
Über Firmen-Veranstaltungen und die Mayflower-Kultur
Freitage sind stets besondere Ereignisse an den drei Standorten. Jeden ersten Freitag finden das Sync-Meeting und der anschließende Jour Fixe statt. Beim Sync tauschen sich die Kollegen eines Standorts intern über die Neuigkeiten sowohl in ihrem jeweiligen Projekt als auch in puncto Marketing, Akquise, Administration et cetera aus.
Die Ergebnisse des Syncs werden im Jour Fixe dann standortübergreifend an die jeweils beiden anderen weitergeleitet, damit alle Niederlassungen ausreichend informiert sind. Meine Aufnahme ist übrigens auch in einem solchen beschlossen worden. Einer der Geschäftsführer, Albrecht Günther höchstpersönlich, hat mir die frohe Kunde überbracht.
Weiterhin veranstalten wir auch Barcamps und Weihnachtsfeiern, beraten Kunden, zeigen auf großen Konferenzen Präsenz. In ganz besonderem Maße interessant fand ich das OKR All-Hands. Darauf möchte ich im Folgenden ein wenig näher eingehen. Zunächst einmal will ich kurz erklären, was OKRs eigentlich sind.
OKR und All-Hands
Die Abkürzung OKR steht für Objectives and Key Results. Ein Objective dient hierbei der Beschreibung dessen, was konkret erreicht werden soll. Die Key Results, sprich die Schlüsselergebnisse, stellen eine Metrik mit Ausgangs- und Zielwert dar. Letzterer misst den Fortschritt des zugehörigen Objectives. Das (OKR) All-Hands ist ein Meeting, bei dem alle Kollegen der jeweiligen Teams, die nicht anderweitig verhindert sind, zusammenkommen, um die von ihnen gewählten OKRs für den kommenden Zyklus, in unserem Fall Tertiale, zu präsentieren.
Sind die OKRs vorgestellt, geht es an’s Challenging. Dabei stehen einige Fragestellungen im Fokus: Gibt es einen triftigen Grund, warum das Team ein oder mehrere OKRs nicht angehen sollte? Braucht das Team Unterstützung bei den OKRs und kann ich ihm dabei helfen? Gibt es Zusammenhänge zwischen OKRs der Teams, bei denen sie sich gegenseitig über den Fortgang abstimmen sollten?
Ich hatte die Gelegenheit, remote an einem All-Hands teilzunehmen. Dessen Grundgedankengut, also die ständige Reflexion und Verbesserung, die Suche nach Synergien, empfinde ich nun, da ich selbst einmal dabei war und es miterleben durfte, als eminent wichtig für die Firmenstruktur als Ganzes. Eines meiner persönlichen Highlights habe ich aber noch gar nicht angesprochen. Genau das will ich jetzt ändern.
MayDay, MayDay!
Jedes Schiff muss irgendwann einmal im Hafen anlegen und Rast machen. Eine ganz besondere Gelegenheit für Landgänge der Mayflower-Crew ist meiner Meinung nach der sogenannte MayDay. Der findet jeden zweiten Freitag statt und bietet den Kollegen Raum, sich fernab der kundenorientierten Arbeit mit aktuellen Entwicklungen und Technologien zu beschäftigen und im Team weiterzubilden, vielleicht sogar im Rahmen persönlicher Projekte. Die können dann wiederum als MayDay-Session angeboten und wahrgenommen werden.
Ich selbst habe seit Beginn meines Praktikums an jedem MayDay einen eigenen kleinen Workshop angeboten. Anfang September, vor Beginn, durfte ich schon an einem MayDay teilnehmen und mein Hobby-Projekt vorstellen: Ich arbeite mit großer Passion mit Unity, einer Game Engine für 2D- und 3D-Spiele. Aktuell bastle ich mir damit privat ein kleines Game zusammen.
Ten weeks later
Ich habe jetzt die Halbzeit meines Studienpraktikums erreicht und fühle mich so wohl wie am ersten Tag. Mein Wissensstand hat seitdem enorm zugenommen. Ich arbeite in echten Teams an realen Kundenprojekten. Man begegnet mir mit Verständnis und Zuversicht, begleitet mich auf meinem Weg.
Nun, das wär‘s soweit von meiner Seite. Hoffe, Dir hat mein kleiner Bericht gefallen. Ich freu‘ mich schon auf‘s nächste Mal, wenn es wieder etwas zu erzählen gibt.
Wir sehen uns!
Schreibe einen Kommentar