Heute widme ich mich einem Thema, das in jedem Projekt von großer Bedeutung sein sollte, leider jedoch oft nicht ausreichend Beachtung findet: Der Projekt-Review oder der Lessons Learned-Workshop.
Im vergangenen Monat wurde die erste Phase eines meiner Projekte abgeschlossen. Dies war Grund genug die vergangenen Monate Revue passieren zu lassen, um herauszuarbeiten, was wir in der nächsten Phase in unserer Zusammenarbeit und der Weiterentwicklung der geplanten Lösung besser machen können. Dabei habe ich mich der klassischen Six Steps-Methode (einsteigen, sammeln, auswählen, bearbeiten, planen, abschließen) bedient. Ich sprach mit Bernd Joussen, der seit Jahren als agiler Coach, Team- und Organisationsentwickler in unterschiedlichsten Transformationen agiert, über seine Erfahrungen mit klassischen und agilen Review-Methoden.
Die Bedeutung des Projekt Review
Uwe Quiede: Zuallererst das Wichtigste: Egal mit welcher Methode – die Hauptsache ist, dass man überhaupt mit seinem Team über die vergangene Projektarbeit spricht und Maßnahmen zur Verbesserung erarbeitet. Es gibt jedoch verschiedenste Möglichkeiten, wie man diesen Weg beschreitet. Die Six Steps-Methode ist sicherlich die am meisten angewandte und auch nicht die schlechteste. In meinem Projekt konnten wir damit die Kernpunkte und Schwachstellen der bisherigen Projektarbeit erarbeiten und haben uns auf Maßnahmen zur Veränderung der Projektarbeit verständigt.
Bernd Joussen: Damit benennst Du bereits einen wichtigen gemeinsamen Aspekt. Auch in der agilen Arbeitsweise gilt es nämlich, diese Kernpunkte und Schwachstellen in der Zusammenarbeit regelmäßig zu benennen und Maßnahmen zur Verbesserung zu vereinbaren.
Wir nutzen mittels verschiedener Methoden und Frameworks das, was wir im agilen „inspect & adapt“ nennen. Nämlich regelmäßig gemeinsam zurück zu blicken: Was haben wir gelernt? Was können wir davon für die Zukunft nutzen?
Das Ganze sollte möglichst messbar und Veränderungen sollten nachvollziehbar sein: Sowohl WAS wir tun als auch WIE wir es tun.
Beispiel Scrum: Beim sogenannten Sprint Review wird öffentlich das Produktinkrement inspiziert und das Team stellt vor, was es bei der gemeinsamen Erstellung gelernt hat. Der Produktverantwortliche, seine Stakeholder und Kunden werden eingeladen, Feedback zu den umgesetzten Lösungen zu geben aber auch neue Ideen zur weiteren Entwicklung des Produkteszu liefern.
Somit ist dieser Termin ein ganz wichtiger für die weitere Produktentwicklung aber auch für die gesamte Organisation.
Meist schließt sich dann unmittelbar die sog. Teamretrospektive an. Hier steht die interne Zusammenarbeit und Verbesserung der Teamperformance auf dem Prüfstand. Das passiert im geschützten Raum unter Ausschluss der Öffentlichkeit, moderiert vom Scrum Master.
Selbstorganisation ist ein Muss in agilen Projekten
Uwe Quiede: Man muss beim Review sicherlich unterscheiden zwischen der Retrospektive, die nach jedem Entwicklungszyklus primär in der IT durchgeführt wird, und dem Review am Ende einer Phase oder eines Projektes. Die Retrospektive bezieht sich auf die Reflexion eines kurzen Zeitraums, der Projekt-Review betrachtet das „große Ganze“. Bei letzterem betrachtet man die teamübergreifende Zusammenarbeit, überprüft aber auch die eingesetzten Tools, die Rollen der einzelnen Teammitglieder, die Zusammensetzung der Projektorganisation und Art und Weise der Kommunikation im Projekt. Alles wird am Ende des Projektes oder einer Projektphase auf den Prüfstand gestellt. Fragen, wie: „Sind wir im Projektteam richtig aufgestellt?“, „Haben wir die erforderlichen Tools?“, „Sind die Aufgaben und Rollen allen Teammitgliedern bekannt?“, sind zu stellen und zu beantworten.
Der Review hat neben der Verbesserung der Arbeit im Projekt das Ziel, Learnings für das Unternehmen zu erarbeiten, welche in allen zukünftigen Projekten berücksichtigt werden können.
Bernd Joussen: Ich stimme Dir zu, Rollenklarheit und die richtigen Werkzeuge sind essenziell; gleichermaßen hilft es zu standardisieren und Bewährtes im Sinne der Effizienz zu übernehmen. Der Zeitpunkt, dies zu tun ist meines Erachtens nicht nur am Ende, sondern ein kontinuierlich begleitender Prozess.
Wir agilen Coaches unterstützen dabei die Teams besonders in der Selbstorganisation. Das umfasst ihre Rollenklärung und persönliche Entwicklung dahin. Dazu gehört aber auch, die Teams selbst auswählen zu lassen, welche Tools, Methode oder welcher Technologieansatz am besten zu ihnen und ihrem aktuellen Setup passt.
Abhängigkeiten technischer, fachlicher oder organisatorischer Art treten dabei genauso zutage wie im klassischen Projekt. Daher gilt es, Arbeit sichtbar zu machen und die Entwicklung der einzelnen Teams gegenseitig so zu unterstützen, dass nutzbarer Wert entsteht.
Es hilft z.B. dem Kunden wenig, wenn ein Team mit seiner Entwicklung für ein neues Feature fertig ist, jedoch ein anderes Team zuarbeiten muss aber geblockt ist und damit das Produkt nicht wie gewünscht nutzbar ist.
Erfolg durch Vertrauen, Offenheit und Mut
Uwe Quiede: Dein letztes Beispiel zeigt, wie wichtig es ist, bei der Auswahl der Review-Methode die zu betrachtende Ebene zu berücksichtigen: Die Retrospektive wird eher bei kurzen Feedback-Zyklen angewandt, während die Six Steps-Methode i.d.R. beim Projekt Review am Ende des Projektes Anwendung findet.
Allerdings sollte ein Projektmitglied nicht bis zum offiziellen Review-Termin warten, wenn eine akute Unstimmigkeit oder ein Problem auftritt. Dies sollte sofort angesprochen werden, entweder im 4-Augen-Gespräch oder mit dem Projektleiter als Mediator, sofern erforderlich.
An der Stelle möchte ich auf die wichtigsten Verhaltensregeln für einen Review hinweisen:
- Ansprechen was gut lief, aber auch die Dinge benennen, die nicht gut liefen
- Offen und lösungsorientiert sein
- Ich-Perspektive nutzen
- Zuhören und Kritik zulassen
- Respektvoll miteinander umgehen
Diese Verhaltensregeln sollten selbstverständlich sein, werden aber viel zu häufig missachtet.
Bernd Joussen: Ja, da hast Du sicherlich recht, wir reflektieren regelmäßig miteinander, in welchen Situationen uns dies gelingt – oder eben auch einmal daneben geht. Mut und Fehlerkultur sind wichtiger Bestandteil des gemeinsamen Lernens.
Insbesondere zu Projektbeginn müssen die Mitglieder und Stakeholder eines neuen Teams erst Vertrauen finden und sich darin üben, Feedback regelmäßig zu geben und zu erhalten.
Struktur und professionelle Moderation (beispielsweise während einer Retrospektive) helfen Gruppen, sich vertrauensvoll auf eine offene und ehrliche Auseinandersetzung miteinander einzulassen.
Als Teamcoach weiß ich, dass es unter Druck auch mal emotional oder etwas rauer zugehen kann. In diesen heißen Phasen der Zusammenarbeit können deshalb gemeinsam vereinbarte Regeln zum Umgang unterstützen, sich immer wieder auf die fachliche Zielsetzung zu fokussieren.
Reife Teams haben meiner Erfahrung nach eine gute Streitkultur und betrachten frühe und ehrliche Auseinandersetzung als gegenseitige Wertschätzung.
Uwe Quiede: Abschließend noch eine Frage an Dich: Welches Vorgehen hinsichtlich des Projekt Review würdest Du einem Projektmanager empfehlen? Kann man hier eine pauschale Aussage treffen oder ist dies von bestimmten Rahmenbedingungen abhängig, z.B. ob ein Projekt nach agiler oder klassischer Methode geführt wird?
Bernd Joussen: Natürlich kommt es immer auf den Kontext und die Organisation an, weil Du als Projektmanager damit auch deine Stakeholder und die Kultur deines Projektumfeldes im Auge behältst.
Grundsätzlich empfehle ich bewusstes Beobachten sowie kurze (am besten tägliche) Zyklen für den Austausch zum WAS und WIE. Dieser sollte von Mut, Fokus und Offenheit geprägt sein. Dies sind wichtige Werte (nicht nur) für die agile Zusammenarbeit.
Bernd, ich danke Dir für unser Gespräch, das neue Perspektiven in der Vorgehensweise beim Projekt-Review aufgezeigt hat und wünsche Dir weiterhin viele Erfolg in Deinen Workshops.