Der Projektmanager machte etwas vollkommen Ungewöhnliches. Was dann passierte, werden Sie nicht glauben!

Ok, zugegeben, diesmal steckt hinter der Clickbait-Überschrift wirklich Inhalt.

Stellen Sie sich folgendes Setting vor: Ein Raum mit einem großen Besprechungstisch, mehrere Personen sitzen am Tisch und erzählen von ihren negativen Erlebnissen der letzten 1 bis 2 Jahre. Der Besprechungsleiter präsentiert Zahlen und Fakten. Am Ende ist man froh, das Meeting ohne Schuldzuweisungen überstanden zu haben.

Klingt wie eine Selbsthilfegruppe, war aber ein Lessons Learned-Workshop nach einem Projekt. Die Darstellung ist zwar etwas überspitzt, ich denke jedoch, dass jeder schon ein oder mehrere Workshops dieser Art erlebt hat. Aber warum sehen durchschnittliche Lessons Learned-Workshops so aus? Warum werden die beabsichtigen Ziele des Workshops oft nicht erreicht?

Wann findet der Lessons Learned Workshop normalerweise statt? Am Ende vom Projekt. Man arbeitet ein bis zwei Jahre an etwas und am Ende spricht man darüber, was nicht so gut gelaufen ist. Abgesehen davon, dass es für die Beteiligten schwer sein wird, den gesamten Projektverlauf zu rekapitulieren und die Problemfelder zu identifizieren, werden die Probleme auch nicht dann angesprochen, wenn sie entstehen. Das birgt mehrere Nachteile in sich:

1. Es ist nicht gewährleistet, dass derselbe Fehler im Projekt nicht noch einmal begangen wird
2. Es ist nicht gewährleistet, dass derselbe Fehler zwischenzeitlich nicht in einem anderen Projekt begangen wird.

Obwohl die Nachteile eigentlich auf der Hand liegen, finden Lessons Learned-Workshops weiterhin am Ende des Projekts statt. Und ehrlich gesagt, ich habe keine Ahnung warum.

Oft geht es darum, dass gesammelt wird, was nicht gut gelaufen ist. Meistens hört es dann allerdings aber schon auf. Es wird nicht erarbeitet, warum etwas nicht gut gelaufen ist und viel schlimmer, was man zukünftig tun kann, um die Wiederholung des Fehlers zu vermeiden.

Nur weil ich weiß, dass etwas nicht optimal war, habe ich noch lange nicht daraus gelernt. Um zu lernen, muss man verstehen, was die Ursachen für das Problem waren und dann Maßnahmen oder Verhalten abzuleiten, die zur Vermeidung einer Wiederholung des Problems dienen.

Oft wird irgendetwas in Dokumenten niedergeschrieben, die dann im Projektportal abgelegt werden und ihrer Wiederentdeckung entgegenfiebern. Die Überleitung von Maßnahmen aus dem Projekt in die Organisation ist schwer und scheitert in den meisten Fällen. Meistens ist der Zeitpunkt des wiederholten Auftretens desselben Problems früher als die Wiederentdeckung der Dokumentation des Lessons Learned-Workshops.

Meiner Meinung nach ist die Ursache im späten Zeitpunkt des Lessons Learned-Workshops und der damit verbundenen zeitlichen Entfernung der Probleme zu suchen. Sie sind schlichtweg nicht mehr so wichtig, wie zu dem Zeitpunkt ihres Auftretens – aus den Augen, aus dem Sinn. Daher sind sie nicht mehr in den Köpfen präsent und keiner denkt mehr daran, dass dieses oder jenes Problem schon einmal besprochen wurde.

Eine der besten Dinge an Scrum sind meiner Meinung nach die Sprint Retrospektiven oder kurz Retros. Die Köpfe hinter dem agilen Manifest haben verstanden, dass es nichts bringt sich erst am Ende darüber zu unterhalten, was man hätte besser machen können. Deshalb haben sie folgendes agiles Prinzip definiert:

In regelmäßigen Abständen reflektiert das Team,

wie es effektiver werden kann und passt sein

Verhalten entsprechend an.

Hier geht es nicht um Erhöhung der Arbeitsleistung, sondern darum besser zu werden. In Scrum werden dazu die Retrospektiven am Ende jedes Sprints genutzt. Dieser Ansatz ist viel umfänglicher als der „normale“ Lessons Learned-Workshop. Hier geht es nicht darum darüber zu jammern, was alles schlecht war, sondern um gezielte Verbesserung. Dazu zählt selbstverständlich auch das Aufarbeiten von aufgetretenen Problemen oder gemachten Fehlern. Aber auch eine Verbesserung von Prozessen und Arbeitsweisen, die bisher vielleicht gut laufen.

In den Retrospektiven zeigt sich auch der Vorteil der Rolle des Scrum Master oder gerne auch des Agile Coaches, der dieses Meeting moderiert und eine neutrale Außensicht einbringen kann. Dieser Faktor fehlt bei den meisten „klassischen“ Lessons Learned-Workshops auch, da hier die Moderation normalerweise durch den Projektmanager geschieht, dieser aber eigentlich Teil des inhaltlichen Arbeitens sein sollte.

Wir setzen seit einigen Monaten agile Methoden in unseren Produktteams ein und haben sehr gute Erfahrungen mit den Retrospektiven und dem Einsatz eines Coaches gemacht. Die Teams haben sich merkbar weiterentwickelt, Fehler oder Probleme wurden angesprochen und schnell gelöst oder Maßnahmen zur Vermeidung abgeleitet.

Die Retrospektiven wirken sich aber auch sehr positiv auf die Teambuildingprozesse aus und fördern diese. Selbst wenn eine Retrospektive einmal etwas „heftiger“ war, ist das Team nachher meist gestärkt und hält besser zusammen.

Damit Retrospektiven effektiv sein können, muss der richtige Rahmen geschaffen werden. Störende Elemente sollten vermieden werden. Dazu zählen auch Führungskräfte im Meeting, da dann das Feedback der Mitarbeiter gehemmt werden kann. Es muss genug Zeit vorhanden sein, um Diskussionen nicht abbrechen zu müssen. Der Moderator muss die Retrospektive vorbereiten und strukturieren, wobei er genug Spielraum für Unvorhergesehenes haben muss. Retrospektiven sind keine Meetings, wo nur über Probleme gesprochen wird, sie sind aktiv gestaltete kreative Meetings. Auf der Website https://plans-for-retrospectives.com/ gibt es sehr gute Tools, um Retrospektiven interessant zu gestalten.

Die ersten Retrospektiven, die Sie im Unternehmen durchführen werden, sind wahrscheinlich nicht sehr effektiv und effizient. Teams müssen lernen, wie Retrospektiven funktionieren und sich darauf einlassen. Nach zwei oder drei Terminen werden Sie sehen, dass das Ergebnis aus der Retro besser wird und der gesamte Verlauf runder wird.

Egal wie Sie Ihre Retrospektiven gestalten, zwei Grundregeln müssen immer eingehalten werden:

• Was in der Retro passiert bleibt in der Retro. Einzig und allein, wenn das gesamte Team zustimmt, dass etwas nach außen getragen wird, wird hier eine Ausnahme gemacht. Dabei handelt es sich meist um Probleme, die das Team nicht selbst lösen kann.
• Es gibt keine Schuldzuweisungen. Probleme existieren und Fehler sind gemacht worden, es geht nicht darum einen Schuldigen zu finden und diesen an den Pranger zu stellen. Retrospektiven sind lösungs- und zukunftsorientiert.

Diese zwei Grundregeln alleine haben den Effekt, dass sich die Teilnehmer mehr öffnen werden und schaffen (auch gemeinsam mit den Rahmenbedingungen weiter oben) eine angstfreie Umgebung, die zur Verbesserung der Projektteams und auch des gesamten Unternehmens dient.