Perspektivenwechsel - eine agile Kolumne

Voll Retro!

Es ist ja geradezu „retro“, mit welcher Häufigkeit Retro-Wellen die Modewelt überschwemmen. Plötzlich sieht man wieder Kleidungsstücke wie Schlaghosen oder Moonboots in den Schaufenstern und auf den Straßen, wo man die doch gerade erfolgreich verdrängt hatte. Aber auch im Musikbusiness wird regelmäßig „gecovert“. Aus alten Hits werden neu aufgepeppte oder manchmal auch überraschend wenig veränderte neue Versionen.

Das mag wohl daran liegen, dass es gar nicht so einfach ist, immer wieder etwas Neues zu erfinden. Wir machen also regelmäßig Anleihen in der Vergangenheit, aber nicht alle diese Anleihen bringen auch tolle Renditen. Das gilt für Neuerfindungen ebenso: Ob sie erfolgreich werden, wissen wir ers

t später. Also dann, wenn wir hinterher in die Vergangenheit schauen. Und morgen ist bekanntlich heute schon gestern. Wenn wir also vorher nicht wissen, welche Faktoren zum Erfolg führen: Bleibt uns nichts anderes übrig als blind loszurennen und zu hoffen, dass etwas Vernünftiges daraus geworden sein wird?

Retro-Perspektive

Erfolg zeigt sich erst retrospektiv. Das gilt für Softwareentwicklungsprojekte ganz besonders, weil der Erfolg von vielen Faktoren abhängt: War die Deadline wirklich relevant? Wenn ja: Was konnten wir zur Deadline liefern? Waren die Anforderungen alle relevant? Haben wir zumindest die wichtigsten Inhalte/Anforderungen umgesetzt? Wussten wir denn, welches die wichtigsten Anforderungen waren? Hat das Team harmoniert? Passte die gewählte Technologie? Ist der entstandene Code wartbar? Wurden Tests erstellt und laufen sie?

Wir stellen also Fragen an die Vergangenheit. Ähnlich wie die Musiker, die sich fragen, was in der Vergangenheit ein toller Hit war, den es zu covern lohnt. Aus den Antworten auf diese Fragen wollen wir etwas für die Gegenwart (oder eigentlich für die Zukunft) lernen. Wir müssen überhaupt erst einmal beurteilen können, ob es denn funktioniert hat. Wie messen wir denn Projekterfolg mitten im Projekt? Am Ende scheint es leicht, aber unterwegs bedarf es dafür Rückkopplungsmechanismen, die uns Indikatoren für Erfolg liefern. Das können komplett umgesetzte Anforderungen oder Tests sein oder auch einfach die Teamstimmung. Wobei Letztere als alleiniges Erfolgsmaß meist nicht ausreicht. Wir müssen aber auch verstehen, warum und unter welchen Bedingungen etwas in der Vergangenheit gut oder schlecht funktioniert hat. Der Song, der schon einmal ein Hit wurde, hat eine gewisse Chance, nach einer Weile in Vergessenheit wieder gut anzukommen (beim etwas gealterten Publikum und eventuell einer nachgewachsenen Generation). Viele Softwareprojekte, die als Migrationsprojekte große alte Host-Systeme ablösen, sind leider über die Originalität einer Coverversion nicht hinausgekommen: Statt Cobol-Legacy besitzen viele Unternehmen jetzt Java-Legacy.

Intro-Perspektive

Natürlich stellt sich die Frage, ob es uns viel nützt, wenn wir erst hinterher schlauer sind. Zum Glück gilt aber in Abwandlung des alten Sepp-Herberger-Spruchs: Vor dem Projekt ist nach dem Projekt. Zumindest aus unserer bisherigen Erfahrung haben wir hoffentlich gelernt und Ideen entwickelt, welche Dinge wir im Vorweg festlegen können und müssen. Für unsere größten verbleibenden Unsicherheitsfaktoren brauchen wir dann schnelle Rückkopplung. So können wir aus möglichst wenig neuen Erfahrungen möglichst schnell größere Sicherheit darüber gewinnen, ob wir auf dem rechten Weg sind. Gerade diese projektbegleitenden, häufigen Retrospektiven sind es, die bei agiler Softwareentwicklung risikominimierend wirken und gleichzeitig die Chance zur kontinuierlichen Verbesserung bieten.

Versteh mich bitte nicht so schnell

Viele Leute glauben, Retrospektiven zu kennen aus so genannten „Lessons Learned“, die auch in nicht-agilen Projekten häufig durchgeführt werden. Aber Retrospektiven sind mehr als nur eine Sammlung von Empfehlungen für die weitere Arbeit. Zurückschauen ist ein Prozess, dessen Organisation in fünf Schritten prima beschrieben ist im Buch „Agile Retrospectives“ von Derby und Larsen [1]: Beginnend mit einem Intro (Schritt 1) folgt die Datensammlung (Schritt 2), bei der Pläne, Taskboards, Velocity-Diagramme etc. betrachtet werden. Außerdem versucht das Team sich gemeinsam zu erinnern, welche Ereignisse im Projekt stattgefunden haben, also z. B. neue Anforderungen, Workshops, neue Teammitglieder oder Abgänge, besonders viele Fehler oder tolle Releases. Über diese Daten gilt es in Schritt 3 Einsichten zu gewinnen: Warum lief es so und nicht anders? Diese Einsichten sind so wichtig, weil man oft zu kurz greift, wenn man einfach nur einen Effekt betrachtet und sofort mit einer Lösung (generisch: Effekt abstellen) daherkommt. Mit Einsichten kommt man zu den besseren Lösungen und Entscheidungen, die in Schritt 4 getroffen werden. Schritt 5 ist schließlich ein Abschluss der Retrospektive. Dabei sollen Retrospektiven durchaus auch das Miteinander im Team betrachten. Auch deswegen ist es eine gute Idee, wenn man Retrospektiven moderieren lässt. Sinnvollerweise nicht von einem Teammitglied (und auch Vorgesetzte haben sich an der Stelle eher nicht bewährt).

Checkliste für erfolgreiche Retrospektiven
• Gibt es einen Moderator, und ist jedem klar, wer das ist?
• Bereitet der Moderator die Retrospektive vor?
• Hält sich der Moderator aus der inhaltlichen Diskussion heraus?
• Setzt der Moderator Hilfsmittel wie Moderationswände und -karten angemessen ein?
• Variiert der Moderator die konkrete Durchführungsform der Retrospektive?
• Wird die Timebox für die Retrospektive eingehalten?
• Findet die Retrospektive in einer angstfreien, energiegeladenen Atmosphäre statt?
• Partizipieren alle Teilnehmer aktiv an der Retrospektive?
• Werden die Ursachen für Probleme analysiert?
• Generiert die Retrospektive konkrete, umsetzbare Maßnahmen (möglichst definiert nach dem SMART-Schema)?
• Werden die beschlossenen Maßnahmen schnell umgesetzt?
Extro

Kaum ein Projekt ist wie das andere. Deswegen gibt es immer wieder viel zu lernen und genau hinzuschauen. Schließlich lernen wir aus jedem Projekt, und nicht zuletzt entwickeln sich die Technologien rasant weiter. Aber warum sollten wir erst am Ende lernen? Lernen wir doch einfach unterwegs! Retrospektiven sind dafür unser Mittel der Wahl.

Henning Wolf ist Geschäftsführer der it-agile GmbH in Hamburg. Er verfügt über langjährige Erfahrung aus agilen Softwareprojekten (XP, Scrum, FDD) als Entwickler, Projektleiter und Berater. Er ist Autor der Bücher „Software entwickeln mit eXtreme Programming“ und „Agile Softwareentwicklung“. Henning Wolf hilft Unternehmen und Organisationen, agile Methoden erfolgreich einzuführen.
Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.