Mit Retrospektive zurück in die Zukunft

In regelmäßigen Abständen lohnt es sich zurückzublicken, die Retrospektive einzunehmen. Manchmal nur auf den letzten Sprint. Aber oft lohnt auch ein Blick darüber hinaus, insbesondere bei Projekten, die sehr lange laufen oder kontinuierlich sind. Aus diesen Zeitreisen lassen sich Erkenntnisse für die Zukunft gewinnen, beispielsweise für neue Projekte oder für Best Practices. Darüber hinaus kann dem Team wieder präsent werden, was sie gemeinsam und einzeln schon erreicht haben.

Rahmen der Retrospektive

Als Rahmen für die Retrospektive gilt die „oberste Direktive“ von Norman L. Kerth aus dem Buch „Project Retrospectives: A Handbook for Team Reviews“:

„Unabhängig davon was wir entdecken werden, verstehen und glauben wir aufrichtig, dass in der gegebenen Situation, mit dem verfügbaren Wissen und Ressourcen und unseren individuellen Fähigkeiten, jeder sein Bestes getan hat.“

Norman L. Kerth

Anschließend wird als Methodik die „Marty McFly Retrospektive“ verwendet, eine Hommage an die bekannte Filmtrilogie „Zurück in die Zukunft“ aus den 80ern:

Ihr sitzt entspannt am Computer und arbeitet, als es plötzlich einen lauten Knall gibt und eine riesige Staubwolke in eurem Zimmer ist. Ihr hustet und als sich der Staub verzieht, stellt ihr fest, dass ein Auto durch eure Hauswand gefahren ist. Ihr nähert euch vorsichtig, um zu sehen, was passiert ist. Das Auto sieht futuristisch aus und besitzt Flügeltüren. Ihr wischt den Staub von der Windschutzscheibe und erkennt: Es ist Marty McFly mit seinem DeLorean. Er scheint unverletzt, aber bewusstlos. Ihr wittert eure Chance und schiebt Marty auf den Beifahrersitz. Die Zeitmaschine scheint unbeschädigt: ihr wagt es und reist zurück an den Anfang eures Projektes: Grüne Wiese. Noch keine Zeile Code ist geschrieben. Jetzt habt ihr die Möglichkeit noch mal bei 0 zu starten: Was behaltet ihr auf jeden Fall bei? Was macht ihr diesmal anders? Was waren eure größten Lerneffekte?

Team-Erkenntnisse der Retrospektive

Wir haben diese Retrospektive mit einem unserer Produktteams durchgeführt und möchten die Erkenntnisse dieses Teams mit euch teilen. Jedes Teammitglied hat in 10 Minuten die wichtigsten Antworten auf die Fragen aufgeschrieben. Danach wurden diese durch das Teammitglied einzeln vorgestellt und kurz besprochen, falls es hierzu verschiedene Meinungen gab. Jedes Teammitglied durfte bestimmen, wer als nächstes an der Reihe ist:

Was behaltet ihr auf jeden Fall bei?

Offen für Neues bleiben
Code-Qualität durch einheitliche Vorgaben (z.B. Linter, JSDoc)
Asynchrone Pull-Requests
Pipelines
Fragen stellen in Pull Requests
„Prototyping“ & Design
Cloud Lösung
Atmosphäre im Team
Team Events (Gaming Abend, Köln etc.)

Was macht ihr diesmal anders?

ARC42- Softwaredokumentation gleich von Anfang an machen
Noch mehr auf Fiori-Konformität achten
Direkt ein ordentliches Wiki
Mehr Event Driven Architecture
Bitcoin kaufen!

Was waren eure größten Lerneffekte?

Wissen über verschiedene neue Frameworks
Qualitatives Coding
Niemand kann alles am Anfang
Wie entsteht wirklich brauchbare Software
Kleine und klar geschnittene Stories sind besser als große Grobe
Nicht immer sich verkünsteln (mega dynamisch, mega komplex denken…)
Teams ist gut, früher nutzen mit Cam (!)
Mob Programming
Groß denken – klein anfangen
Sich zwingen, Arbeiten zu übernehmen, auf deren Gebiet man sich kaum auskennt, erzeugt den größten Lerneffekt.

Wie man sieht, ist das Team einen umfangreichen persönlichen und technischen Entwicklungsprozess durchlaufen. Das Team startet mit einem ihnen unbekannten Tech Stack, für den lediglich die Basis-Technologien bekannt waren. Grundlegende Entwicklungsprozess-Leitplanken waren vorhanden, mussten aber individuell für das Team und die Technologien ausgeprägt werden. Ebenso verhielt es sich auf der fachlichen Seite. Mit der Zeit wuchs das Team auf 7 Personen an und integrierte noch einen Werkstudenten und einen Masteranden ins Team.

Die Team-Erkenntnisse der Retrospektive lassen sich kategorisieren:

Prozesse

Der Rahmen eines Entwicklungsprozesses wurde mitgegeben, das Team hat ihn aber für sich selbst individuell als Ergebnis aus der Retrospektive angepasst. So wurden beispielsweise Code Reviews anfangs synchron durchgeführt, später asynchron über Bitbucket. Es kam zu der Erkenntnis, dass die Reviews nicht nur für Qualität wichtig sind, sondern auch als Möglichkeit zu Lernen dienen können. So wurden in Pull Requests auch Fragen gestellt, weshalb Lösungsansatz X statt Lösungsansatz Y gewählt wurde. Durch Konzepte wie Mob Programming konnte gemeinsam an komplexen Problemen gearbeitet werden und Wissen sich im Team verbreiten. Ein Designer ist dafür verantwortlich, dass UI/UX beachtet werden und die Software gut bedienbar ist.

Technologien

Durch den neuen Tech Stack musste das Team insbesondere am Anfang viel Neues lernen, was sehr anstrengend war und sich auf die Entwicklungsgeschwindigkeit niederschlug. Im Laufe des Projektes kamen wieder neue Technologien und Frameworks hinzu und haben bestehende ersetzt. Das führte während der Retrospektive immer wieder zu neuen Herausforderungen, aber am Ende zu Produktivitätssteigerung im Team. Schrittweise wurde automatisiert mit einem Linter und in Form von Unit- und Frontend-Tests, die von der Pipeline ausgeführt werden.

Persönliches (Soft Skills und Teamzusammenarbeit)

Das Team hat im Laufe des Projektes und der Retrospektive Wege gefunden, seine interne Kommunikation zu optimieren und das erlangte Wissen zu dokumentieren, um es für neue Teammitglieder verfügbar zu machen. E-Mail wurde abgeschafft, die Kommunikation über Teams-Channels oder Tickets geregelt und nachvollziehbar dokumentiert. Das Team traf sich zu Team Events und später zu virtuellen Gaming-Sessions. Ein Wiki wurde gestartet.

Fazit und Learnings der Retrospektive

Der Weg dieses Teams ist sicherlich noch nicht zu Ende, aber die Retrospektive hat das Team mit Stolz erfüllt, was sie bereits alles erreicht haben. Dies gerät oft im Stress des Alltags in Vergessenheit. Zusätzlich konnten andere Teams der INTENSE von den Erkenntnissen profitieren.

Themen im Kontext „Qualitätsmanagement, Dokumentation und Testing“, die anfangs eher mit Skepsis betrachtet wurden, werden im Rückblick als sehr positiv bewertet. Das Team erkannte, dass je besser sie in diesen Bereichen aufgestellt sind, desto einfacher ihre Arbeit in der Zukunft ist. Die „Metrik“ hierfür ist recht einfach: Im Sprint Planning hört man nicht „Oh nein, jetzt müssen wir DAS noch mal anfassen“, sondern „Okay, das betrifft dieses Modul, lass uns einmal in die Architekturdoku schauen, wie wir das gut integrieren. Tests sind ja bereits definiert.“. Unser Learning aus der Retrospektive lautet daher: Anfängliche Hürden sind zu meistern, doch sind sie erst mal abgebaut, verlaufen Projekte fließender von der Hand.

Der Autor

Dominik Panzer

Dominik verantwortet als Entwicklungsleiter die technische Produktentwicklung der Intense AG und unterstützt Teams als Technical Agile Coach in den Bereichen Prozesse, Testautomatisierung, Methodiken und Clean Code. Er ist Initiator der Clean Code Advocate Initiative der INTENSE AG.