Die Grundlagen erfolgreicher Retrospektiven

Durch regelmäßige Retrospektiven lernen Teams sich aktiv mit ihrer Situation zu befassen, um diese zu verbessern. Teams übernehmen im Zuge der Retrospektive Verantwortung für das eigene Umfeld und können so einen großen Schritt in Richtung Selbstorganisation gehen.
Siehe auch: Verbesserung durch Retrospektive.

Wer Retrospektiven effektiv im eigenen Team einsetzen möchte, für den gibt es einige Grundlagen, an denen er sich orientieren kann. Die Grundlagen und ihre Wirkungsweise verleihen den Retrospektiven ihre Wirksamkeit.

Auf diese Grundlagen geht der Artikel in kurzen Abschnitten ein.

Akzeptanz der Methode

Der Mensch lässt sich nur auf Dinge ein, deren Sinn er versteht. Aufgezwungene Veranstaltungen bringen wenig und verursachen allzu leicht eine Abwehrhaltung. Es muss eine Aufklärung aller Teilnehmer, hinsichtlich des Vorgehens und der Ziele von Retrospektiven, erfolgen, um eine Grundlage für eben diese zu schaffen.

Auch Ergebnisse dieser Methode werden besser angenommen, wenn sie verstanden und akzeptiert ist.

Es zeigt sich, dass das Vermitteln von Verständnis für solche Veranstaltungen ein fortlaufender Prozess ist. Immer wieder müssen die Grundlagen und das Ziel der Retrospektiven erläutert werden. Die Erfahrung zeigt, dass eine Gruppe schnell wieder in alte Gewohnheiten fällt, sich mit der Komfortzone begnügt und nicht weiter an echten Veränderungen arbeitet. Dieses Verhalten wird von Lyssa Adkins, in ihrem Buch Coaching Agile Teams, als Muscle Memory bezeichnet.

Ausreichender Freiraum

Mitten im Tagesgeschäft sind Menschen und Gruppen kaum in der Lage ihre aktuelle Situation zu reflektieren. Der nötige Freiraum muss zur Verfügung stehen, damit sich das Team auf die Retrospektive konzentrieren kann. Zudem müssen Termin und Agenda früh genug bekannt sein, damit sich jeder darauf vorbereiten kann.

Idealerweise findet die Retrospektive regelmäßig zu einer festgelegten Zeit statt.

Menschen werden sich nur dann offen äußern, wenn sie keine Nachteile für die Äußerung ihrer Meinung befürchten müssen; weder durch die Gruppe noch von außerhalb. Für die Veranstaltung muss folglich ein entsprechend geschützter Bereich vereinbart werden. Ein geschützter Raum bezeichnet in diesem Zusammenhang einerseits einen echten Raum, in dem die Gruppe ungestört ist und andererseits die grundsätzliche Vereinbarung, dass Aussagen nicht nach außen getragen werden oder zum Nachteil der Teilnehmer verwendet werden.

Regelmäßigkeit sorgt dafür, dass Probleme innerhalb der Gruppe zeitnah angesprochen und gelöst werden können. Zudem ist es gut, wenn Gruppen offenes Feedback und das retrospektive Arbeiten regelmäßig üben. Die Erfahrung zeigt, dass eine Gruppe durch entsprechende Moderation beim Erlernen der offenen Kommunikation unterstützt werden sollte.

Die aktive Teilnahme

Retrospektiven sollen Veränderungen für und in der Gruppe herbeiführen. Da also potenziell jeder von diesen Veränderungen betroffen ist, sollten sich auch Alle an der Entscheidungsfindung beteiligen. Denn nachfolgend soll jeder Einzelne die resultierenden Aktionen im Alltag mittragen. Auch Widerspruch muss gehört werden und letztlich in einen Teamkonsens mit einfließen.

Zudem gilt, je vollständiger das Bild einer Situation ist, desto bessere Schlüsse lassen sich daraus ziehen. Ein möglichst vollständiges Bild einer Gruppe erhält man dann, wenn jeder seine Perspektive hinzufügt. Bleiben Meinungen oder Menschen unbeachtet, ist das Bild unvollständig. Das volle Potenzial der Gruppe wird dann nicht ausgeschöpft.

Aus der Erfahrung heraus sind das Gesamtbild und die aktive Teilnahme nur durch eine geeignete Moderation erreichbar. Häufig ist es nötig mit einzelnen Teilnehmern auch über die Grenzen der eigentlichen Retrospektive hinaus zu arbeiten, um sie gut einzubinden.

Konkrete Schritte

In einer Retrospektive ist es wichtig konkrete Maßnahmen zu identifizieren, die zeitnah umgesetzt werden können. Stellen sich Erfolge ein ist dies motivierend für das gesamte Team. Je schneller Erfolge erreicht werden, desto besser ist es.

Abstrakte Ziele oder große Veränderungen, die sich nicht zeitnah umsetzen lassen, sollten nach Möglichkeit in kleine Schritte zerlegt werden. Die angestrebten Veränderungen sollten hierbei stets in den Verantwortungsbereich des Teams fallen.

Beschlossene Anpassungen müssen, zusammen mit den gewünschten Ergebnissen, festgehalten werden. Die Verteilung von Aufgaben sollte ebenfalls dokumentiert werden. Offene Aktionen und Themen können zusätzlich in einem Verbesserungs-Backlog organisiert werden. Ein formloses Festhalten der konkreten Ergebnisse reicht hier völlig.

Immer wieder zeigt sich, dass es schwierig ist, konkrete Verbesserungen zu finden, die sich auch zeitnah realisieren lassen. Dies gilt insbesondere im Enterprise Umfeld. Dann ist es wichtig, dem Team transparent alle Vorgänge darzulegen und es in die weiteren Schritte mit einzubeziehen.

Bestätigung des Erfolges

Die gemachten Anpassungen müssen immer wieder auf den Prüfstand, um feststellen zu können, ob sie zu den geplanten Verbesserungen geführt haben. Durch die Überprüfung soll sichergestellt werden, dass Initiativen nicht im Sande verlaufen. Zudem können auf Basis bereits gemachter Erfahrungen weitere Verbesserungen erarbeitet werden.

Die Anwendung zeigt, dass sich die Akzeptanz für Retrospektiven nicht aufrechterhalten lässt, wenn sich keine Erfolge für das Team feststellen lassen. Ob es daran liegt, dass die Ergebnisse zu wenig konkret waren oder die Initiativen nicht konsequent verfolgt werden, ist letztlich unerheblich.

Sichtbarkeit der Veränderung

Veränderungen müssen sichtbar sein und transparent gemacht werden, sowohl innerhalb des Teams als auch nach außen. Sichtbarkeit bringt die beschlossenen Veränderungen immer wieder ins Gedächtnis und unterstützt den Veränderungsprozess. Erfolge angemessen zu würdigen, ist positiv für den Teamgedanken und stärkt die Motivation weiterzumachen.

Es geht darum, dass sich etwas bewegt und nicht so sehr wie groß die einzelnen Verbesserungen sind. Wichtig ist, dass das Team Veränderungen herbeiführt und diese positiv wahrnimmt.

Retrospektive der Retrospektive

Auch das Vorgehen bei der Retrospektive selbst sollten die Teilnehmer reflektieren, um es an die eigenen Bedürfnisse anzupassen. Damit kann ein Team seine Retrospektiven über die Zeit individueller und wirksamer gestalten. Zudem erhöht Mitgestaltung die Motivation der Teilnehmer.

Niemand möchte seine Zeit verschwenden und die Retrospektive muss als gute Investition der eigenen Zeit betrachtet werden. Mit einer kurzen ROTI (Return On Time invested) Abfrage lässt sich die Wahrnehmung der Teilnehmer schnell ermitteln.

ROTI Abfrage

Die Teilnehmer einer Veranstaltung werden um Feedback gebeten, ob sie die aufgewandte Zeit als gut investiert betrachten. Hierzu kann eine einfache Skala mit folgenden Werten genutzt werden:
sehr gelohnt; neutral; gar nicht gelohnt.
Diese Skala kann nach Belieben erweitert werden.

Betrachten die Teilnehmer die Retrospektiven als gute Investition ihrer Zeit, ist das ein Zeichen für eine hohe Akzeptanz und wiederum gut für die Motivation.

Fazit

Retrospektiven müssen als fortlaufende Prozesse verstanden werden, welche Verbesserungen für ein ganzes Team hervorbringen können. Die einzelnen Grundlagen der Retrospektiven bauen aufeinander auf und beeinflussen sich gegenseitig.

Grundlagen der Retrospektive

Aus diesem Grund muss immer wieder überprüft werden, ob alle Grundlagen möglichst gut erfüllt sind. Eine Retrospektive der Retrospektiven ist ein probates Mittel um Probleme aufzudecken und entsprechende Anpassungen vorzunehmen. Es entsteht ein klassischer „Untersuchen und Anpassen“ Zyklus (Inspect and Adapt).

 

Die Ergebnisse, die so erzielt werden können, motivieren weiter mit Retrospektiven zu arbeiten. Auch die Erfolge und die daraus resultierende Motivation sind wichtige Elemente des Prozesszyklus.
Sind diese beiden Zyklen in Takt, werden die Retrospektiven zu einer guten Basis für die Selbstorganisation des Teams!

Verbesserung durch Retrospektive

Aus der Vergangenheit für die Zukunft zu lernen, ist ein bekannter Ansatz. Retrospektiven sollen dabei helfen, Abläufe zu verbessern und das Betriebsklima aufzuwerten.

Ich blicke zurück, also werde ich besser! Der Ansatz ist gut, den Erfolg bestimmt allerdings die richtige Methodik.

Hierbei stellen sich zwei Fragen:

  • Welche Methoden gibt es und was kann man mit ihnen erreichen?
  • Was sind die Grundlagen bei der Anwendung dieser Methoden?

Dieser Artikel geht auf die erste Frage ein, während der zweiten Fragestellung ein anderer Artikel nachgeht.

Der Jahresrückblick

Der Rückblick auf ein ganzes Jahr ist eine verbreitete Maßnahme, um sich auf das Kommende vorzubereiten. Hierbei zeigt sich, dass eine detaillierte Bearbeitung einzelner Themen in der Regel nicht möglich ist. Die Anzahl verschiedener Themen und Projekte ist zu groß. Zudem sind wahrscheinlich nicht mehr alle Details aus zwölf Monaten präsent.

Bereits erreichte Erfolge zu vergegenwärtigen, motiviert für kommende Aufgaben!
Dies sollte nicht unterschätzt werden und rechtfertigt den Aufwand.

Post Mortem Analyse (PMA)

Nach dem Abschluss eines Projektes oder dem Erreichen eines Meilensteins wird in der Praxis häufig eine Post Mortem Analyse (PMA) gemacht. Mit den Erfahrungen, die das Team gesammelt hat, sollen Verbesserungen für künftige Projekte erreicht werden.

Der Umfang und der Ablauf einer PMA kann frei gestaltet werden. Es sollte jedoch genügend Zeit eingeplant werden, um den Projektverlauf zu reflektieren, eine Ursachenanalyse durchzuführen und Verbesserungen zu erarbeiten. Zudem sollten alle Personen, die an dem Projekt beteiligt waren, auch an dessen Nachbereitung mitwirken.

In der Praxis zeigt diese Methode allerdings markante Schwächen. Denn je mehr Probleme es während des Projektes gab, desto unwahrscheinlicher ist es, im Anschluss die benötigte Zeit, das Budget und die Leute noch zur Verfügung zu haben. Daraus ergibt sich, dass je mehr Probleme aufgearbeitet werden müssten, es umso schwieriger wird, dies zu erreichen. Hat das Arbeitsklima unter den Problemen gelitten, wird es zudem schwer, offenes Feedback von den Beteiligten zu erhalten.

Feedback ist zwar eine Grundlage und häufig auch der Ausgangspunkt für Verbesserungen, reicht aber allein gestellt nicht aus. Es fehlen weitere Schritte wie eine Konsolidierung der Themen sowie eine Analyse von Ursachen und Auswirkungen.

Eine methodische Herangehensweise innerhalb von Gruppen, die genau hier ansetzt, ist die Teamreflexion.

Teamreflexion

Im Fokus der Aufmerksamkeit stehen teamrelevante Themen (wie z. B. Kommunikation, Prozesse und Ziele). Erfahrungen des Teams werden gesammelt und reflektiert. Bei der Gewinnung neuer Erkenntnisse wird das Team durch Methoden wie Ursache-Wirkungs-Analysen unterstützt.

John Dewey Zitat

Ausgehend von den neuen Erkenntnissen wird ein Plan für die Etablierung von Verbesserungen erarbeitet. Nach einer entsprechenden Zeit werden die Umsetzung sowie die Wirksamkeit der Anpassungen überprüft. Untersuchungen haben gezeigt, dass die Teamreflexion am wirksamsten ist, wenn sie regelmäßig stattfindet, da auf diese Weise eine Feedbackschleife etabliert werden kann.

Teamreflexion Retrospektive

Es ist in der Praxis festzustellen, dass ein Team das gemeinsame Reflektieren mitunter erst lernen muss. Zudem lässt sich ein Teamprozess kaum in einem Durchgang optimal gestalten. Regelmäßige Teamreflexionen unterstützen das Team dabei.

In der Softwaretechnik, aber auch in anderen Bereichen, wurden Methoden entwickelt, die ebenfalls auf diesem Schema aufbauen.

Retrospektive in Softwareprojekten

Im Jahr 1997 schreibt Alistair Cockburn in seinem Buch Surviving Object-Oriented Projects: „Work in increments, focus after each“. Im Jahr 2001 beschreibt er einen „Reflection Workshop“ als regelmäßige Veranstaltung, um Verbesserungen für das Team und den Prozess zu erarbeiten.

Etwa zur gleichen Zeit wurde die Erstfassung des agilen Manifests unterzeichnet. Darin heißt es: „At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Bob Martin lud Cockburn ein, um an diesem Manifest mitzuarbeiten. Es ist also nicht überraschend, dass sich seine Ideen hier wiederfinden.

Retrospektive in Softwareprojekten

Scrum folgt diesem Prinzip und sieht hierfür die Retrospektive als Ereignis vor. Das Team inspiziert das Ergebnis des Sprints und den eigenen Prozess. Hierbei werden die positiven und negativen Aspekte gleichermaßen betrachtet.

John Dewey Zitat

Ziel einer Retrospektive ist es, konkrete Aktionen zu identifizieren, die im kommenden Sprint umgesetzt werden sollen. Es wird sogar (Beispiel Scrum Alliance) als „Major Pitfall“ bezeichnet, eine Retrospektive enden zu lassen, ohne konkrete Aktionen zu beschließen.

Die Erfahrung zeigt, dass die Retrospektive eine sehr gute Möglichkeit ist, Teams bei der Weiterentwicklung zu unterstützen. Das Team reflektiert immer wieder die eigenen Erfahrungen und sucht nach möglichen Verbesserungen. Über die Zeit wird man feststellen, dass ein Team besser darin wird, sich selbst zu inspizieren und Erfahrungen zu reflektieren. Es steigert seine eigene Reflexivität.

Teamreflexivität

Reflexivität ist die Fähigkeit, über sich selbst nachzudenken. Man geht davon aus, dass Teams mit einer guten Reflexivität in komplexen Situationen besser und nachhaltiger agieren, weil sie sich gut anpassen können. Zudem verfügen sie über ein tiefer gehendes Verständnis des eigenen Umfeldes, Qualitätsbewusstsein und eine aktive Arbeitseinstellung.

Fazit

Wenn ein Umfeld komplex oder technologisch anspruchsvoll ist, muss sich ein Team mitunter schnell anpassen können. Eine gute Teamreflexivität ist also unverzichtbar. Auch selbstorganisierte Teams profitieren von dieser Fähigkeit. Ein Team muss methodisch dabei begleitet werden, wenn es diese Dinge entwickeln soll. Hierfür sind die Teamreflexion und die Retrospektive als Methoden gut geeignet. Der große Vorteil dieser Ansätze ist es, dass der laufende Prozess untersucht wird und Verbesserungen schnell zum Tragen kommen.

Auch andere Methoden, wie die PMA, haben ihre Berechtigung und werden von einer guten Teamreflexivität positiv beeinflusst. Um diese aufzubauen, eignen sie sich in aller Regel jedoch nicht.

Welche Grundlagen bei der Anwendung dieser Methoden beachtet werden sollten, wird in einem weiteren Artikel “Grundlagen erfolgreicher Retrospektiven” behandelt.

Scrum: Die Rolle des Product Owners

Für die erfolgreiche Produktentwicklung innerhalb des Scrum Frameworks nimmt der Product Owner als Treiber der Wertgenerierung und Katalysator der Kommunikation zwischen allen Beteiligten des Projektes (Stakeholder) eine entscheidende Rolle ein.

Er ist die zentrale Person, die die Entwicklung des Produktes verantwortet sowie umfassend auf die Maximierung des Produktwertes (value) fokussiert und diese vorantreibt.

Visualisierung der Product Owner Rolle

In diesem ca. 15 Minuten langen Video wird sehr eingängig visualisiert, wie der Product Owner von einer Vision, die sich im Product Backlog abbildet, über einen andauernden Lernprozess zu einem wertvollen Produkt kommt.

Die Produktvision im Product Backlog

Der Product Owner bewahrt die Vision des Produktes. Hierzu verwaltet er das Product Backlog als geordnete Liste der Anforderungen die, wenn sie vollständig entwickelt wurden, die Vision in die Realität umzusetzen. Die Verwaltung des Product Backlogs ist eine stetige Verfeinerung und Ausarbeitung der einzelnen Features, welche die Vision ausmachen. Die einzelnen Features werden so mehr und mehr an Klarheit gewinnen, wodurch Ungewissheit und Unklarheit zunehmend beseitigt werden.

Stetiges Lernen

Je länger ein Product Owner mit der Produktvision arbeitet und diese zunehmend verfeinert, desto mehr lernt er über das Produkt und darüber, welche Features von Wert sind.

Zu Beginn basiert jede Entscheidung auf Annahmen, die durch Feedback validiert werden müssen. Die fortlaufende Bewertung, Aufbereitung und Priorisierung der Features, ihre Umsetzung, Bereitstellung und das Einholen von Feedback führen zu neuen Erkenntnissen und Chancen, den Wert des Produktes iterativ zu steigern.

Grundsätzlich birgt jedes Feedback für alle Beteiligten die Möglichkeit zu lernen, welche Features wertvoll sind und welche nicht und somit eine Chance den Produktwert zu steigern. Stetiger Wissensgewinn hilft, Unnötiges zu vermeiden und sich auf das Wesentliche zu fokussieren.

Je später Entscheidungen und Verfeinerungen im Product Backlog stattfinden, desto umfassender ist das zu Grunde liegende Wissen und umso potentiell wertvoller ist das Ergebnis. Folglich ist es sinnvoll, Features im Product Backlog erst dann zu verfeinern, wenn sie zeitnah umgesetzt werden sollen.

„Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“ [AM]

Der Wert eines Produktes

Durch seine Priorisierung und das Aufbereiten potentiell wertvoller Tasks im Backlog sorgt der Product Owner dafür, dass jeder Sprint es wert ist durchgeführt zu werden. Der Product Owner agiert mit dem Vertrauen darauf, dass das Sprintziel durch das Entwicklungsteam in höchstmöglicher Qualität erstellt wird.

„Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“ [AM]

„Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.“ [AM]

Der Wert eines Produktes ist in Scrum nicht definiert, jedoch lässt er sich implizit mit Kunden- oder Anwenderzufriedenheit gleichsetzen.

„Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.“ [AM]

Betrachtet man bei der Bewertung eines Produktes zusätzlich seine Qualität, so ist die „Definition of Done“ eines Scrumprojektes ein wesentliches Artefakt, dessen sich der Product Owner bewusst sein muss und deren Weiterentwicklung er beeinflusst, um die Qualität seines Produktes zu steigern.

“Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.” [AM]

Zudem lässt sich ein Produkt bewerten, indem die „Total Cost of Ownership“ (TCO) dem „Return on Invest“ (ROI) gegenüberstellt wird. Die TCO kann der Product Owner minimieren, indem Features abgelehnt werden, deren Wartungsaufwand und Betriebskosten durch ihren Wert nicht zu rechtfertigen sind.

Weiterführende Ansätze zur Ermittlung des Wertes

Eine weiterführende Methode, um den Wert eines entwickelten Produktes zu messen, gibt das von Scrum.Org entwickelte Framework „Evidence Based Management“, welches die drei Aspekte „Current Value“, „Time to Market“ und „Ability to Innovate“ eines Produktes betrachtet.

Einen anderen Ansatz, um den Wert von Produkten im agilen Umfeld zu bewerten, bietet Roman Pichler mit seiner Bewertungsmethode „Product Scorecards“. [RP]

Kommunikation des Product Owners

Im Zentrum des Wirkens eines Product Owners steht die andauernde Kommunikation und Interaktion mit allen Beteiligten, die er nachhaltig etabliert und fördert.

Er muss allen Beteiligten die Vision und die nötigen Schritte zur Umsetzung in geeigneter Weise vermitteln. Zudem hat er Kunden, potentielle Anwender und weitere Projektbeteiligte in einer Form einzubinden, die bewusst macht, dass jedes Feedback essentiell für die Weiterentwicklung ist. Hierbei muss er das Feedback zwischen verschiedenen Interessengruppen und deren Zielen ausbalancieren.

„Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“ [AM]

Der Product Owner und die Werte von Scrum

Courage ist sicherlich eine wichtige Basis für das Handeln des Product Owners. Er steht zu einem minimal marktfähigen Produkt mit wenigen aber entscheidenden Funktionen. Er verantwortet ein frühes Bereitstellen, um seine Annahmen validieren zu können und um Ungewissheiten und Risiken schnell und nachhaltig zu reduzieren. Er fokussiert sich auf das, was von Wert für die Umsetzung der Vision ist und baut hierbei auf sein gewonnenes Wissen.

Er lehnt Features ab, die nicht zur Produktvision gehören und bewahrt das Product Backlog davor, zu einer ungeordneten Wunschliste zu werden. Jedes Feature, das nicht zur Lauffähigkeit der Vision beiträgt, kann potentiell verworfen werden.

Er sieht sich als Teil des Teams und arbeitet möglichst eng mit ihm zusammen. Er strebt nach einem gemeinsamen Verständnis der Vision und erarbeitet die Schritte zur Umsetzung gemeinsam mit seinem Team.

“Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.” [AM]

 

Fazit

Wenn Scrum das Rahmenwerk bietet [SG], so sind stetiges Lernen und das Verfeinern der Vision im Product Backlog der methodische Inhalt während die offene Kommunikation eine nachhaltige Triebkraft des Prozesses bildet.

Werden diese Verfahrensweise und die Werte von Scrum durch den Product Owner verinnerlicht, erfüllt er seine Rolle bei der Verwirklichung der Vision und der Generierung von Werten.

Quellen:

[AM] http://agilemanifesto.org/

[SG] http://www.scrumguides.org/

[SORG] https://www.scrum.org/

[RP] http://www.romanpichler.com/

Weiterführende Empfehlungen

Buch „Agile Product Management with Scrum“ http://www.romanpichler.com/romans-books/agile-product-management-with-scrum/

Webcasts von ScrumOrg

https://www.scrum.org/About/All-Articles/articleType/ArticleView/articleId/1063/Product-Owner-vs-Product-Manager

https://www.scrum.org/About/All-Articles/articleType/ArticleView/articleId/1001/Cage-Fight-Product-Owner-vs-Product-Manager–ScrumPulse-Webcast-12