E-Learning: Review

• Inkrement bei Stakeholdern/Kunden präsentieren 
• Neue Wünsche zu Anforderungen aufnehmen
• Rückmeldungen für die nächsten Iterationen nutzen

Zweck eines Reviews ist es, bei den Projektanforderungen, die beim Agilen Projektmanagement als änderbar begriffen werden, passend nachzusteuern. Das letztendliche Ziel dabei ist eine möglichst hohe Zufriedenheit der Kunden mit dem Produkt.

Beispiel: Für die Marketingkampagne eines Pharmaunternehmens wurden in der ersten Iteration Medikamentenaufsteller für Apotheken entwickelt. In einem Review bewerten mehrere Referenzapotheken, ob der Aufsteller für ihre Zwecke brauchbar ist. Es zeigt sich, dass viele Apotheker den Aufsteller auf ihrer Theke platzieren möchten, wozu er jedoch zu groß ist. 

Das Beispiel zeigt sehr schön eine wesentliche Ursache für unklare Anforderungen: Die Kunden verstehen ein Produkt meist erst dann besser, wenn sie es – zumindest teilweise – ausprobieren können. 

Darüber hinaus können auch noch weitere Faktoren zu Änderungen an den Anforderungen beitragen. Dazu zählen insbesondere Veränderungen im Umfeld des Kunden oder schlichte Missverständnisse bei den Anforderungen.

Welche Ursache auch immer die Änderungswünsche während eines Reviews haben – entscheidend ist, sie ernst zu nehmen. Daher sollten alle Wünsche, die der Kunde nennt, auch schriftlich festgehalten werden, und zwar völlig unabhängig davon, ob die Änderungen später auch tatsächlich in die Anforderungen einfließen werden. Zunächst müssen dem Kunden die Auswirkungen der Änderungen auf den Projektverlauf verständlich gemacht werden. Dann kann er entscheiden, welche Änderungen ihm wirklich wichtig sind. Oft verwerfen Kunden eigene Ideen auch wieder, wenn sie die Kosten oder zeitlichen Auswirkungen der neuen Anforderung überblicken können. 

In der Softwareentwicklung hat es sich bewährt, bereits zu Beginn einer Iteration mit dem Kunden abzusprechen, welche Tests er in dem Review nach der Iteration mit dem Teilprodukt durchführen will. Dies gibt dem Review-Prozess eine klarere Struktur. 

Ein Review kann auf verschiedene Art und Weise durchgeführt werden. Es muss nicht immer in Form eines Meetings stattfinden. Es kann auch sein, dass für ein Review das Produkt dem Kunden eine gewisse Zeit zum Test überlassen wird. 

Beispiel: Ein Kfz-Zulieferer entwickelt ein neues elektronisches Bauteil für die Fahrzeugsteuerung. In einer Iteration wurde als Inkrement ein Gehäuse mit Anschlüssen entwickelt. Dieses Teilprodukt überlässt er nun für eine gewisse Zeit dem Kunden, damit dieser den Verbau des Teils in verschiedenen Fahrzeugtypen testen kann. 

Für den Erfolg eines Reviews ist es mitentscheidend, die geeigneten Personen dafür zu finden. Hier helfen die folgenden Fragen: Wessen Feedback zum Produkt ist entscheidend? Wer muss wirklich dabei sein?

Vor allem im klassischen Projektumfeld kommt es häufig vor, dass mehrere Kundenvertreter im Raum sind, die unterschiedliche Interessen in Bezug auf das Produkt haben. Dann findet man sich schnell in der Rolle des Mediators für die unterschiedlichen Kundeninteressen wieder. Die Verantwortung dafür sollte aber auf jeden Fall beim Kunden verbleiben. Die Interessenskonflikte kann man immer wieder transparent machen und dann auf einer internen Klärung beim Kunden bestehen. Natürlich gibt es auch Fälle, in denen man selbst davon profitieren kann, wenn beim Kunden Uneinigkeit herrscht. Hier gilt es dann allerdings politisch klug zu agieren, damit sich das Blatt nicht irgendwann wendet und die Unzufriedenheit sich gegen den Auftragnehmer richtet. Erfahrene Projektmanager haben gelernt, mit solchen Situationen umzugehen, und zwar völlig unabhängig vom klassischen oder agilen Vorgehen.

Auf jeden Fall sollten für ein Review die folgenden Punkte beachtet werden:

• Durch eindeutige Absprachen im Vorfeld sollte sichergestellt sein, dass die Stakeholder die passenden Erwartungen an das Review haben. Es muss klar kommuniziert sein, welche Anwendungsfälle in dem Inkrement bereits umgesetzt sind und welche nicht. Sollte es während der Entwicklung zu Problemen gekommen sein und dadurch bekannte Lücken oder Fehler im Produktinkrement geben, so sollte offen und proaktiv damit umgegangen werden.
• Ebenfalls vorab ist zu klären, wer beim Kunden die entscheidenden Partner für ein Review sind. Alle wichtigen Stakeholder sollten zum Review eingeladen werden, da das Produkt sonst eventuell in die falsche Richtung steuert. 
• Gleichzeitig sollte der Kreis der Eingeladenen so klein wie möglich gehalten werden. Sonst entstehen nur unnötige, zeitraubende Diskussionen, weil alle mitreden wollen. Falls solche Diskussionen einfach nicht zu vermeiden sind, hilft eine strikte Moderation und die strenge Priorisierung der Änderungswünsche. 
• Das Review sollte eine klare Agenda haben. 
• Alle Entscheidungen sollten schriftlich in einem Protokoll festgehalten werden.

Im Allgemeinen werden Reviews am Ende einer Iteration abgehalten. Auf Basis ihrer Ergebnisse wird bei den Anforderungen nachgesteuert und die nächste Iteration geplant.

Im klassischen Projektumfeld gibt es bisweilen Konzepte, die einem Review grundsätzlich ähneln. So wird in manchen Projekten ein „Schulterblick“ praktiziert, bei dem jemand auf fertige Teilergebnisse eines Entwicklers schaut und dann Rückmeldungen zu diesen Ergebnissen gibt. Oder es gibt ein sog. Fast Feedback, bei dem Teilergebnisse aus der Entwicklung dem Fachbereich oder der Projektleitung vorgestellt werden. Falls in einem Projekt solche Konzepte bereits gelebt werden, so kann es sich als geschickt erweisen, sie beizubehalten oder zumindest den Namen aufzugreifen und in ein Review einzubetten. Auch wenn ein strukturiertes Review häufig mehr ist als ein klassisches Meeting, so kann man mit der Beibehaltung gewohnter Begriffe Projektteilnehmer manchmal besser abholen als mit der Neubenennung eines Meetings, obwohl dieses im Kern immer noch das gleiche Ziel verfolgt. Denn bei solchen Umbenennungen bekommen erfahrene Projektteilnehmer häufig das Gefühl, ihnen werde alter Wein in neuen Schläuchen vorgesetzt.