Retrospektive

Die Retrospektive ist der dritte wichtige Steuerkreis des Agilen.

• Durch die Arbeit des Product Owner werden die Anforderungen der Stakeholder gesteuert und als Aufgaben an das Leistungserstellungsteam weitergereicht.
• Durch das Review werden die Ergebnisse der Leistungserstellung überprüft und gesteuert.
• Über die Retrospektiven wird der Leistungserstellungsprozess des Teams von ihm selbst überprüft und gesteuert.

Im Verlauf der Retrospektive untersuchen die Leistungsersteller, incl. Scrum Master und Product Owner, den Prozess, der angewendet wurde, um das Produkt zu erstellen. Wir befinden uns auch hier in dem typischen Plan-Act-Check Vorgehen der agilen Methoden. 

In der Retrospektive wird überprüft, ob der Prozeß der Leistungserstellung verbessert werden kann und wie das möglich ist. Dann wird der Plan in dem nächsten Sprint umgesetzt. Mit der nächsten Retrospektive erfolgt die Überprüfung des Planes. Die Retrospektive gehört damit auch zu den Planungsinstrumentarien des agilen Vorgehens.

Während der Retrospektive werden Verbesserungen erarbeitet. Diese werden dann nach der Retrospektive im nächsten Teil des Leistungserstellungsprozesses umgesetzt.

Die Retrospektive bietet die Möglichkeit für eine kurze Zeit aus dem Druck der Leistungserstellung auszusteigen, zu verharren und über das Getane in Ruhe zu reflektieren. In dieser Zeit denkt das Team darüber nach, was es getan hat. Es reflektiert, diskutiert und überprüft so seine Arbeitsweise, Arbeitsmittel und den Prozess in dem es arbeitet, die Kommunikation untereinander und mit den Stakeholdern. Außerdem überprüft es die Werkzeuge, die es verwendet, die Nützlichkeit der Artefakte, etc.

Die Retrospektive findet nach jeder Timebox statt und nicht erst am Ende des Leistungserstellungsprozesses. Das gibt dem Team die Möglichkeit, Verbesserungen frühzeitig in den Leistungserstellungsprozess einfließen zu lassen. So ergeben sich die Möglichkeiten, im nächsten Sprint mit den Veränderungen zu experimentieren. Basierend auf diesen Erfahrungen kann der Leistungserstellungsprozess kontinuierlich verbessert werden.

Möglicher Ablauf einer Retrospektive

Es gibt keinen festen Ablauf einer Retrospektive. Der hier beschriebene Ablauf zeigt lediglich ein mögliches Vorgehen. 

Gerade am Anfang, wenn ein Team dabei ist sich zu bilden, gibt es eine Vielzahl an Themen über die gesprochen werden muss. Jeder der Teilnehmer hat viele Themen, die ihm am Herzen liegen und die er aus seiner persönlichen Perspektive betrachtet haben möchten. Das Review liegt in der Verantwortung des Product Owners. Die Retrospektive in der Verantwortung des Scrum Masters. Wie wir schon bei dem Review gesehen haben, bedeutet das aber nicht, dass diese Rolleninhaber die Veranstaltung leiten müssen. Insbesondere bei der Retrospektive ist es extrem wichtig, dass der Scrum Master die Retrospektive nicht dominiert. Jeder Beteiligten muss sich hier voll einbringen können.

Damit hat jede Besprechung zu Retrospektive die besten Chancen genauso zu verlaufen, wie jede andere schlecht vorbereitete Besprechung. Chaotisch, konfliktträchtig und ergebnislos. Zu jeder Retrospektive gehört also eine entsprechende Vorbereitung. 

Eine Themensammlung, eine Agenda, ein zeitlicher Ablauf, die Fakten zu den jeweiligen Themen, etc. sollten im Vorfeld der Retrospektive gesammelt werden – oder spätestens am Anfang dieser Besprechung. 

Retrospektiven sind zeitlich begrenzt und werden eher kurz gehalten. Es kann also sinnvoll sein, eine Retrospektive auf einen bestimmten Focus, der von dem Team als „besonders regelwert“ empfunden wird, zu beschränken. – Allerdings besteht dann auch das Risiko, dass die Menschen, die innerhalb des Teams dominant sind, die Themen bestimmen und die Fragestellungen der anderen Teilnehmer nicht berücksichtigt werden. 

Ein möglicher Ablauf könnte so aussehen:

• Den Focus bestimmen, z.B. durch eine vorherige Themenauswahl, Punktwertverfahren zum Abstimmen über Themen, Agenda oder sonstigem.
• Übung auswählen, die die Teilnehmer in das Thema herein bringt, eine entsprechende Atmosphäre schafft und zum Nachdenken anregt. Beispiele für solche Übungen finden sich in den Moderationsverfahren für große Gruppen. Ein Brainstorming, Ergebnis Zeitstrahl, Emotionaler Seismograph und ähnliche Methoden können hier unterstützen. 
• (Objektive) Daten sammeln, als Basis für die weitere Diskussion. Der Begriff Objektive ist hier bewusst eingeklammert. Die Wahrnehmung eines Sachverhaltes kann bei unterschiedlichen Teilnehmern durchaus sehr unterschiedlich sein. Auch die Interpretation „objektiver Daten“ kann bei den Teilnehmern unterschiedlich sein. Viel wichtiger ist es, zunächst einmal die Unterschiede der Wahrnehmung heraus zu arbeiten. Die Behauptung, dass „dies objektive Daten sind“, wird zu häufig benutzt, um jede Diskussion zu verhindern und die eigen Ansicht unangreifbar zu machen. 
• Subjektive Wahrnehmung der Teilnehmer und das subjektive Erleben der Teilnehmer in Bezug auf die objektiven Daten transparent machen und nach Möglichkeit eine gemeinsame Wahrnehmung erreichen.
• Verbesserungsmöglichkeiten, bzw. Änderungsmöglichkeiten diskutieren und eine Auswahl dieser Verbesserungsmöglichkeiten treffen. 
• Die Verbesserungsmöglichkeiten schriftlich fixieren und dann in den nächsten Prints umsetzen.

Eine gute Möglichkeit, den ganzen Prozess für alle Teilnehmer transparent zu machen, findet sich in der Methode Fakten und Konsens. Damit sich das Team die Entwicklung über den Sprint vergegenwärtig und die Gefühle, die innerhalb dieses Sprints aufgrund der Ereignisse gegenseitig verdeutlicht, kann die Methode Ereignisse und Gefühle genutzt werden. Viele der Coaching Methoden, die sich auf dieser Web-Site finden, können für die Gestaltung der Retrospektive situationsabhängig genutzt werden. Die meisten Methoden sind zwar für ein Einzelcoaching entwickelt worden, lassen sich aber leicht auf Gruppen übertragen.

Ein sehr einfacher, aber wirkungsvoller Ablauf für die Retrospektive kann in vier Fragen bestehen:

1. Was ist gut gelaufen? Was hat funktioniert?
2. Was ist schlecht gelaufen? Was hat nicht funktioniert?
3. Was wollen wir beibehalten?
4. Was soll wie geändert werden?

{article 245}[text] {/article}

Agile Methode: Review

Die Reviews sind ein fester Bestandteil der agilen Methoden. Sie sind das wichtigste Steuerungsinstrument der Produktentwicklung. 

Nach jeder Timebox oder wie in Scrum am Ende jeder Timebox wird ein Review durchgeführt, bei dem die Ergebnisse der Arbeit von den Stakeholdern begutachtet werden. 

Basierend auf dieser Begutachtung findet eine Überarbeitung des Product Backlogs statt. Anderes formuliert: bei jedem Review werden die Anforderungen neu betrachtet, verfeinert, verändert und den Gegebenheiten angepasst. Das Review wird damit für alle Beteiligten zur wichtigsten Lernschleife. 

Die Stakeholder erhalten Einblick in den realen aktuellen Zustand des bisher fertigen Produktes. Sie erleben konkret die Weiterentwicklung des Produktes. Sie sehen und erleben, wie sich das Produkt durch die Arbeit in der Timebox entwickelt hat.

Sie sehen also nach jeder Timebox die Entwicklung an dem Produkt selber. Das konfrontiert sie mit dem direkten Produkt und dessen Entwicklung. Dieses direkte Erleben des Produktes verhindert böse Überraschungen, erhöhte Erwartungen. Die Stakeholder sehen Fehlentwicklungen unmittelbar und können diese verhindern.

Aus diesem Erleben heraus geben sie ein unmittelbares Feedback und verändern das Product Backlog innerhalb dieses Reviews aufgrund des unmittelbar erlebten. 

Auch die Leistungsersteller kommen in einen direkten, persönlichen Face to Face Kontakt zu den Stakeholdern und erhalten ein entsprechend direktes Feedback von den Menschen, für die das Produkt entwickelt wird. Das fördert das gegenseitige Verstehen und schafft das Gefühl für „richtige Menschen“ zu arbeiten und diese Menschen als solches zu Verstehen und nicht nur als „abstrakte“ Kunden oder „diffuse Gruppe“ von Nutzern, die wärend der Produktentwicklung niemals in reale Erscheinung treten.

Die Teilnehmer des Reviews

Das Review lebt von den Teilnehmern und der Interaktion zwischen ihnen. Ohne diese Teilnehmer und zwar Vertreter aller Gruppen, die hier genannt werden, ist ein Review mehr oder weniger wirkungslos. Oder anders formuliert: wie auch immer diese Treffen genannt werden, es ist kein Review im Sinne der agilen Leistungserstellung.

An dem Review sollten alle an der Leistungserstellung beteiligten teilnehmen. Also insbesondere alle Mitglieder des Entwicklerteams und der Product Owner. Natürlich auch der Scrum Master, wenn wir in einer Scrum Organisation sind. Das Review ist die Veranstaltung des Product Owners. Er leitet das Review. Die Präsentation der Inkremente sollte nach Möglichkeit von allen Leistungserstellern übernommen werden. Es sind interne Stakeholder, wenn die Produktentwicklung von einer Auftrag nehmenden Organisation durchgeführt wird. Hier sind insbesondere die Stakeholder erwünscht, die für die Finanzierung der Produktentwicklung zuständig sind und die Personen, die fachlich für die Ergebnisse mitverantwortlich sind. 

Die externen Stakeholder sind zunächst einmal die Vertreter der Auftraggeber die eine finanzielle Verantwortung haben und die Fachabteilungen, in deren Auftrag das Produkt entwickelt wird. Wenn das Produkt für die Kunden des Auftraggebers hergestellt wird, sollten auch diese Endanwender um ein Feedback gebeten werden. Wenn es weiter externe Stakeholder gibt, dann kann es nützlich sein auch Vertreter dieser Gruppe einzuladen. 

Was und wie sollte präsentiert werden?

In dem Review wird das fertige Produktinkrement vorgeführt. Ziel ist es den Teilnehmern ein „Look and Feel“ Gefühl des Produktes zu vermitteln. Eine Powerpoint Präsentation verhindert genau dieses Gefühl. Auch eine umfangreiche Präsentation der kaufmännischen Entwicklung des Leistungserstellungsprozesse, abstrakt und mit vielen Charts – wie sie bei den üblichen Präsentationen „Projektleiter präsentiert vor dem Management“ Besprechungen gemacht wird, wiederspricht der Idee eines Reviews. 

Ziel eines Reviews ist eine intensive Diskussion der Teilnehmer über die Leistungseigenschaften an dem realen Objekt.

Abnahme durch den Product Owner

Der Product Owner bekommt von dem Team das Inkremen, das der Definition of Done entspricht, geliefert. Er prüft dieses Inkrement und bestätigt dem Team, dass das Inkrement der Definition of Done entspricht. 

Dieser Prozeß muss vor dem Review stattfinden.

{article 245}[text] {/article}

Agile Methode: Kosten ermitteln

Auf den ersten Blick scheinen Kosten in der agilen Produktentwicklung nur eine untergeordnete Rolle zu haben, während sie im klassischen Projektmanagement sehr dominant sind. Dieser Eindruck täuscht allerdings. Wenn wir uns mit der Priorisierung von Anforderungen beschäftigen, dann basiert der Wert einer Funktionalität auf der klassischen kaufmännischen Sichtweise:

Wert = Nutzen – Aufwand.

Der Aufwand wird dabei in Story Points, Idealtagen und ähnlichem geschätzt. Irgendwann innerhalb der Planung, wird dann ein Zusammenhang zwischen einem Personentag und den Story Points, oder anderen Schätzgrößen hergestellt. 

Der nächste Schritt von dem Personentag zu den Personentagessätzen ist dann nur noch sehr klein – und damit sind wir wieder in der üblichen Welt der altbekannten Projektkostenrechnung angekommen. 

Die Kosten für eine Timebox sind sehr leicht zu berechnen.

• Die Dauer einer Timebox ist bekannt und bleibt über die Dauer der Produktentwicklung fix.
• Das Team (incl. Product Owner und Scrum Master) bleibt (im Idealfall) über den gesamten Produktentwicklungsprozess zusammen.
• Alle Mitarbeiter im Team sind der Produktentwicklung zu 100% ihrer Arbeitszeit zugewiesen.

Damit können die Personalkosten innerhalb einer Timebox leicht ermittelt werden. Die altbewährte Berechnung der Personenstunden kann hier genutzt werden. Über die Zahl der geplanten Timeboxes ergibt sich die Höhe der Gesamtkosten.

Wenn die durchschnittliche Höhe der Story Points pro Timebox als Team Velocity bekannt ist, können auch die erwarteten Kosten pro Story Point errechnet werden. 

Die Kostenberechnung ist also recht einfach, soweit primär Mitarbeiterkosten entstehen. Wenn das Produkt, das erstellt werden soll, zusätzlich teure Materialen oder Dienstleistungen benötigt, die bei den einzelnen Funktionalitäten variieren, dann wird die Berechnung der Kosten wesentlich schwieriger. 

Nehmen wir einmal die unspezifische Anforderung: „Wir brauchen ein Auslieferungsfahrzeug.“

Wenn wir klassisch vorgehen würden, dann würden wir jetzt genau festlegen, wie das Fahrzeug beschaffen sein könnte und dann berechnen lassen, wie hoch die Materialkosten sind. Wir könnten auch verschiedene Kostenvoranschläge einholen, die basierend auf einem genauen Pflichtenheft erstellt werden. Die Unsicherheiten und Ungenauigkeiten und der Aufwand bei der Erstellung und Änderung solcher Berechnungen sind ja hinlänglich bekannt. Ich werde sie hier also nicht erörtern. Wir erhalten als Kalkulationsbasis eine Zahl, die auf der Multiplikation von Wahrscheinlichkeiten mit Wahrscheinlichkeiten basiert. Die genauen Kosten bleiben bis zur Fertigstellung des Daches unsicher.

Wenn wir agil vorgehen, dann steht diese unspezifische Anforderung zunächst einmal im Product Backlog und wird dann genauer spezifiziert, wenn wir wissen, wie genau das Fahrzeug beschaffen sein soll und wie sich die Materialpreise entwickelt haben. Erst dann erfolgt eine genaue Beschreibung. Danach erfolgt eine Kalkulation der Kosten, die wesentlich weniger unsicher ist, als die „frühe Kalkulation“. Die genauen Kosten kennen wir auch in dieser Situation erst nach der Fertigstellung des Daches.

Was verändert sich durch das agile Vorgehen?

In dem klassischen Vorgehen wird, bevor mit dem Projekt begonnen wird, genau spezifiziert und berechnet, was gebraucht werden wird. Die Kosten sind – mit den üblichen Unsicherheiten bekannt. Im Verlauf des Projektes erkennen wir, dass wir etwas anderes brauchen. Spezifizieren genau und berechnen die Kosten mit den üblichen Unsicherheiten. Dann erkennen wir, dass wir etwas anderes brauchen, spezifizieren genau und berechnen die Kosten mit den üblichen Unsicherheiten. Und so weiter. In dem letzten Zyklus spezifizieren und kalkulieren wir genau und erstellen die Funktionalität. Ist sie fertig, kennen wir die Kosten genau.

Im agilen Vorgehen leben wir mit der Unsicherheit, berechnen, spezifizieren erst kurz vor der Leistungserstellung mit sehr hoher Sicherheit. Erst wenn die Funktionalität fertig ist, kennen wir sie genau.

Welches Vorgehen ist jetzt besser?

• Bei dem klassischen Vorgehen, ist die Unsicherheit kleiner, da wir zumindest eine „grobe Richtung“ der Kosten haben. Dafür ist der Aufwand zu Anfang größer.
• Im Verlauf des klassischen Vorgehens ändern wir die Spezifikation / Kostenschätzungen mehrmals mit zusätzlichem Aufwand.
• Bei dem agilen Vorgehen ist die Unsicherheit größer, denn es gibt noch nicht einmal eine „grobe Richtung“. Es entsteht kein Aufwand.

Die letztendliche Spezifikation ist in beiden Fällen sehr ähnlich. Die Endkosten sind identisch. Das agile Vorgehen ist mit weniger Aufwand und einer größeren Unsicherheit verbunden.

Aber: Ist das „agile Vorgehen“ genau wie in dem Bild oben beschrieben?

• Im Product Backlog wird jede Anforderung in eine Hierarchie gebracht und der Aufwand wird geschätzt. Lediglich die Schätzung ist nicht so genau, wie in dem klassischen Vorgehen.
• Erfolgt eine Änderung einer Anforderung, dann wird das Product Backlog geändert. Im agilen Vorgehen reden wir von Backlog Pflege. Im Rahmen dieser Backlog Pflegen, erfolgt natürlich auch eine „Neuschätzung“ des Aufwandes. 
• Die Änderungen im Product Backlog erfolgen in Abstimmung des Product Owners mit den Stakeholdern und den Leistungserstellern.

Und schreibt das „klassische Projektmanagement“ (nach PMI, Prince2, GPM-IPMA) das Vorgehen vor, dass in dem Bild oben beschrieben wurde?

• Die Anforderungen der Stakeholder werden in einer Leistungsbeschreibung erfasst. Hier folgt eine Hierarchisierung der Ziele und in der Planung ein Schätzung des Aufwandes, der notwendig ist, um diese Ziele zu erreichen.
• Der Aufwand der Anforderungen wird im Verlauf des Planungsprozesses geschätzt. Die Anweisung in allen Systemen: „so genau wie nötig, so grob wie möglich“. Es wird immer empfohlen bei frühen Schätzungen eine „von … bis“ Spanne anzugeben.
• Eine Änderung der Anforderungen und des Planes ist jederzeit möglich, sofern der Änderungsprozess eingehalten wird. Der besagt: Änderungen müssen mit den Stakeholdern besprochen und von den Auftraggebern genehmigt werden. Ein Änderungsantrag beinhaltet: Beschreibung der Änderung, Beschreibung der Folgen der Änderung in Bezug auf Kosten, Budget, Risiken, etc…

Wie unterschiedlich sind die Vorgehensweisen also wirklich? Liegen die Probleme, die in dem klassischen Vorgehen liegen, wirklich in den Projektmanagement-Methoden begründet? Und ist die Problemlösung, die im agilen Vorgehen liegt, so unterschiedlich von dem „klassischen Projektmanagement“?  

Oder sind die Probleme in der Interpretation des Vorgehens zu suchen? Und besteht dann nicht das Risiko, dass genau die gleichen Interpretationsprobleme bei der Anwendung der agilen Methoden erneut gemacht werden?

Die Frage, welches Vorgehen jetzt besser ist, bleibt weiterhin bestehen.

Die wesentlichen Fragen reduzieren sich auf die klassische Abwägung, die bei Schätzungen immer im Mittelpunkt stehen:

• Wie sicher ist eine Vorhersage?
• Wie dringend brauche ich eine sichere Vorhersage?
• Mit welchem Aufwand kann ich die Sicherheit der Vorhersage erhöhen?

 {article 245}[text] {/article}

I