Kitabı oku: «Der Scrum-Reiseführer», sayfa 3
4.4 Product Owner als Wertmaximierer
Die Rolle des Product OwnersProduct Owner ist – im Vergleich zu den beiden anderen Rollen – innerhalb eines Scrum Teams diejenige, die durchaus unterschätzt wird. Außerdem stehen Fachbereiche vor personellen Herausforderungen, wenn sie einen ihrer Fachexperten für eine andere Tätigkeit abstellen müssen. Folgende zwei Kernaspekte entwickeln sich aus diesen Reibungspunkten:
1 Der Product Owner ist eine Rolle innerhalb der Organisation, die gegebenenfalls neu geschaffen werden muss! Optimal ist es, wenn sich der Product Owner vollständig auf die Tätigkeiten im Scrum Team fokussieren kann und keine zusätzlichen, anderweitigen Aufgaben erhält.
2 Der Product Owner ist eine (!) Person, keine Gruppe oder Komitee. Gleichzeitig kann er die Interessen mehrerer Personen vertreten. Die finale, produktbezogene Entscheidung obliegt jedoch immer dem Product Owner.
Welche Entscheidungen sind gemeint und was sind nun die konkreten Aufgaben eines Product Owners? Der Grundgedanke ist einfach: Der Product Owner trägt die Verantwortung dafür, den Wert zu maximieren, den das Produkt für das Unternehmen erzeugt. So generisch dies klingen mag, so vielfältig sind auch die Methoden, die ein Product Owner dabei anwenden kann.
Ein effektives Management des Product Backlogs bildet dabei das Herzstück, um den maximalen Wert aus dem Produkt zu kitzeln. Dazu gehören insbesondere das Herausarbeiten und Kommunizieren eines Produktziels. Hier kann es zu den ersten Differenzen kommen, die den Erfolg des Scrum Teams negativ beeinflussen. Das Team möchte schnelle sichtbare Ergebnisse erzielen. Das kann dazu führen, dass der strategische Part stiefmütterlich behandelt und aus den Augen verloren wird. Hier ist also besondere Aufmerksamkeit erforderlich: Stellen Sie im Laufe Ihres Projektes eine ungewünschte Veränderung der Ergebnisse fest, werfen Sie doch nochmal einen Blick auf die Ausarbeitungen und die Kommunikation des Produktziels. Nehmen Sie sich dafür Zeit, sie wird sich rentieren! User Stories zu erzeugen und zu kommunizieren ist ein weiterer Aufgabenbereich des Product Owners. Er bringt diese in eine sinnvolle Reihenfolge, was in der Praxis eine Herausforderung sein kann. Besonders in diesem Teilschritt treten veraltete, hierarchisch geprägte Denkweise ans Tageslicht, die dem agilen Grundgedanken widersprechen. Nehmen wir zur Illustration ein beispielhaftes Projekt, das sich mit dem Erstellen von Berichten beschäftigt. Es liegt nahe, zunächst einmal User Stories anzulegen, die sich lediglich mit dem Sammeln und Anbinden von Datenquellen beschäftigen, um dann, in einem zweiten Schritt, mit der Erstellung der Berichte zu beginnen. Das jedoch ist genau die traditionelle Wasserfall-Denkweise, die ein sequenzielles und kein inkrementelles Vorgehen vorsieht. Geht ein Product Owner so vor, würde er der Maxime Wertgenerierung entgegenarbeiten. Denn eines ist klar: Wert wird erst dann geschaffen, wenn mindestens ein Bericht von der Fachabteilung im operativen Betrieb genutzt werden kann. Deshalb wäre es ein – im Sinne eines Product Owners – geschickteres Vorgehen, zunächst einen wichtigen, wertgenerierenden Bericht auf Basis weniger Datenquellen zu erzeugen, um anschließend darauf aufbauend die Daten- und Berichtslandschaft zu erweitern Eine weitere, grundlegende Funktion des Product Owners ist, ein für alle Teammitglieder nachvollziehbares und transparentes Product Backlog sicherzustellen.
Diese Fülle an Aufgaben macht deutlich, weshalb die Rolle eines Product Owners nicht einfach mal so nebenbei erledigt werden kann. Ein Product Owner kann zusätzlich bei den oben beschriebenen Aufgaben von anderen unterstützt werden. Die Prämisse dafür ist, dass allen zu jeder Zeit bewusst ist, dass am Ende der Product Owner die Verantwortung für diese Tätigkeiten trägt.
Einen erfolgreichen Product Owner zeichnet aus, dass seine Entscheidungen innerhalb der Organisation respektiert und akzeptiert werden. Daher ist es notwendig, dass ein Product Owner ein Entscheidungsmandat erhält. Ist dies nicht gewährleistet, kann es zu Situationen kommen, in denen die Entscheidungen infrage gestellt werden, was die Produktivität des Scrum Teams negativ beeinflusst.
4.5 Führung und Teambildung in agilen Teams
Das Entstehen eines Spitzenteams durchläuft vorab verschiedene Phasen, genauso wie bei der Buchung eines langersehnten Traumurlaubs. Zunächst wird ein passender Zeitraum und das zur Verfügung stehende Budget festgelegt. Anschließend werden Urlaubsziele miteinander verglichen und das bestmögliche ausgesucht. Ein Hotelzimmer oder eine Pension wird reserviert. Reisen Sie per Flugzeug, kaufen Sie Flugtickets und je näher das Abreisedatum rückt, umso tiefer stecken Sie in den letzten Vorbereitungszügen. Die Wanderstiefel werden geputzt oder der Bikini noch einmal kritisch auf seinen Sitz beäugt. Der Nachbar ist bereits im Besitz des Hausschlüssels und hat sich freundlicherweise dazu bereit erklärt, zweimal die Woche die Pflanzen zu gießen. Das Taxi wird vorbestellt und auch der Mietwagen am Zielflughafen ist bereits organisiert. Jetzt kann der Urlaub richtig losgehen!
Ähnlich verhält es sich auch mit agilen Teams (beziehungsweise mit Teams im Allgemeinen, agil macht hier keinen Unterschied). Bringt man Personen aus unterschiedlichen Bereichen zusammen, um gemeinsam an einem Projekt zu arbeiten, durchläuft die Gruppe zwangsläufig gewisse Schritte, bevor sie zu einem Höchstleistungsteam wird. Der US-amerikanische Psychologe Bruce Tuckman hat die Dynamiken von Teams auf dem Weg hin zu Hochleistungsteams untersucht. Er entwickelte in den 1960er Jahren ein vierphasiges ModellTeam-Building-Phasen, welches er 1977 um eine weitere, fünfte Phase ergänzte. Die fünf von Tuckman festgelegten Phasen lauten Forming, Stroming, Norming, Performing und Adjourning (Mourning). Sie sind in Abbildung 7 dargestellt und werden nachfolgend näher erläutert.
In jeder Phase finden bestimmt Teambildungsentwicklungen statt. Die Phasen sind je nach Team unterschiedlich lang. Allgemeingültige Aussagen über die Entwicklungsdauer können also nicht getroffen werden und wären allenfalls unzuverlässig. Dabei spielt es keine Rolle, ob die Gruppe neu zusammengewürfelt wird oder ob eine bereits bestehende Gruppe mit nur einer weiteren Person ergänzt oder ausgetauscht wird. Der Phasenzyklus beginnt immer von vorne, allerdings nicht jedes Mal im gleichen Ausmaß. Bereits die Kenntnis dieser Phasen innerhalb eines Teams hilft, mit Schwierigkeiten konstruktiver umzugehen. Konflikte, Streitigkeiten und kontroverse Diskussion werden dann nicht mehr als ein Zerfall des Teams angesehen, sondern als etwas Normales und Notwendiges, als ein Teil der gemeinsamen Reise.
Abbildung 7:
Team-Building-Phasen nach Tuckman
Forming
Viele Teammitglieder sind in dieser Phase voller Vorfreude auf die neue Aufgabe. Gleichzeitig ist diese positive Aufregung gepaart mit Unsicherheit, da man sich und seinen Platz im Team noch nicht einschätzen kann. Es gibt viele unbeantwortete Fragen in Bezug auf das Miteinander und den Umgang untereinander. Verantwortlichkeiten und Prozesse sind noch nicht bekannt. Manchmal weiß das Team zu diesem Zeitpunkt noch nicht einmal, dass es bestimmte Prozesse überhaupt benötigt. Das Gebot der Stunde heißt Beobachten und Verstehen. Konflikte werden (noch) nicht offen angesprochen, da eine Unsicherheit darüber besteht, wie das Team mit Bedenken und Konfliktsituationen umgeht. Oft benötigt es ein paar couragierte Vorstöße einzelner, bevor auch andere Teammitglieder sich trauen, offen Kritik zu äußern.
Storming
Nach einiger Zeit wird den Teammitgliedern bewusst, dass nicht alle Erwartungen an das Team zu erfüllen sind; zumindest nicht, wenn sich nichts ändert. Einige Teammitglieder werden jetzt die Gunst der Stunde ergreifen und ihre Unzufriedenheit offen ansprechen. Andere werden sich eher in sich zurückziehen und Abstand vom Team nehmen. Gründe für Unzufriedenheit gibt es viele und sind von Team zu Team verschieden. Einige Teammitglieder können genervt darauf reagieren, dass ihre Arbeitsergebnisse und deren Fortschritt als Teil des Sprint Backlogs transparent gemacht werden. Sie erkennen darin nichts anderes als ein Kontrollinstrument des „Managements“. Einige werden mit dem Gesamtfortschritt unzufrieden sein und nicht selten nach Gründen außerhalb ihres Einflussbereichs suchen, um sich selbst vor anderen – aber auch vor sich selbst – abzusichern und rechtfertigen zu können. In solchen Situationen meinen Teammitglieder zu lernen, dass sie sich nicht auf andere im Team verlassen können. Vorwürfe werden laut und die Verantwortung wird von sich selbst weggestoßen. Themen werden vermehrt „in kleiner Runde“ diskutiert, womit unweigerlich Allianzen innerhalb des Teams gebildet werden. Dem entgegen wirkt, den Fokus der einzelnen Teammitglieder weg von den individuellen Leistungen hinzu einer intensiven Zusammenarbeit zu lenken. Erkennt jeder im Team an, dass die Kollegen besondere Vorzüge und individuelle Schwächen mitbringen, von denen das Team in seiner Gesamtheit profitiert, hilft dies allen, die Situation besser zu verstehen und damit konstruktiv umzugehen.
Norming
Durch viele Diskussionen und Konflikte lernen sich die Teammitglieder besser kennen. Sie erkennen und verstehen die Wertegerüste der anderen Teammitglieder und lernen, wie das Team über die formellen Rollen hinaus funktioniert. Die Teammitglieder bilden nur Taktiken aus, um die Zusammenarbeit zu stärken, Gemeinsamkeiten zu fördern und Stärke der einzelnen Teammitglieder besser zu integrieren. Ein überraschendes Ergebnis, das durchaus nachdenklich stimmen kann, wurde von Google im Rahmen des Projektes Aristotle veröffentlicht. Demnach kommt es bei einem Hochleistungsteam nicht darauf an, ob es sich an allgemein anerkannten guten Werten und Prinzipien orientiert, wie beispielsweise Teammitglieder ausreden lassen und ihnen nicht ins Wort fallen, sondern dass alle im Team die gleichen Werte und Prinzipien teilen! Von außen betrachtet ist es also für jemanden sehr schwer, auf Grund des Umgangs miteinander im Team direkt auf die Leistungsfähigkeit des Teams zu schließen. Ein Team, in dem sich die Mitglieder gegenseitig anschreien, kann durchaus Höchstleistungen erbringen, solange alle im Team diesen Umgang als den für das Team richtigen erachten.
Performing
Nach ausgetragenen Konflikten, die viel Kraft und Energie gekostet haben, steigt die Stimmung im Team. Die Teammitglieder beginnen, sich weniger mit sich selbst und den anderen zu beschäftigen, sondern konzentrieren sich mehr auf Inhalte. Das grundsätzliche Gerüst der Zusammenarbeit steht, der Fokus liegt jetzt darauf, wie gemeinsame Ziele nach und nach immer besser und schneller erreicht werden können. Das Team hat dazu Rituale etabliert, die ebenfalls dabei helfen, neu auftretende Konflikte lösungsorientiert anzugehen. Es entsteht ein „inner circle“, der es für Außenstehende schwer macht, Teil des Teams zu werden.
Adjourning
Wird das Teamgefüge nun substanziell verändert, zum Beispiel dadurch, dass das Team in kleinere Teams aufgeteilt wird oder dass neue Teammitglieder auf Schlüsselrollen hinzukommen, entstehen bei vielen Teammitgliedern Sorgen und Bedenken. Vor allem mögliche – und bis dato unbekannte – Veränderungen der eigenen Rolle sorgen für Unsicherheiten einzelner Teammitglieder.
Teambildung benötigt Zeit. Obwohl das von Tuckman definierte Phasenmodell bis heute nichts von seiner Gültigkeit verloren hat, ist der Druck auf Teams, in immer kürzeren Zyklen mehr Ergebnisse zu liefern, gestiegen. Haben Unternehmen heute also noch Zeit für Teambildung? Kann das Thema Teambildung beschleunigt werden? Ein Begriff, der in diesem Zusammenhang immer häufiger gebraucht wird, ist der des Empowerments. Führungskräfte geben dabei einen Teil ihrer Entscheidungshoheit auf und übertragen diesen auf ihre Mitarbeitenden. Dadurch, dass Teams bestimmte Entscheidungen innerhalb der Gruppe treffen dürfen, wird die Motivation gesteigert, was sich positiv auf die Lieferung von Ergebnissen auswirkt und gleichzeitig die Dauer des Teambildungsprozesses verkürzen kann. Dieser zuerst einfach anmutende Weg birgt jedoch Konfliktpotenzial. Mal abgesehen davon, dass viele Führungskräfte diesem Prinzip misstrauen, weil sie dadurch selbst weniger „mächtig“ sind und befürchten, Kontrolle zu verlieren, müssen Mitarbeitende erst lernen und wollen, Entscheidungen zu treffen. Um dies zu erreichen, sind zunächst noch weitere Schritte notwendig.
General Stanley McChrystal beschreibt in seinem Buch Team of Teams ein einfaches Konzept, das den Zusammenhang zwischen Komplexität und Anpassungsfähigkeit verdeutlicht. Diese zwei Aspekte sind es, die agile Entwicklungsmethoden wie Scrum so beliebt gemacht haben. Obwohl dem Buch ein militärischer Hintergrund zugrunde liegt, sind die Erkenntnisse durchaus auf Scrum Teams anwendbar. Komplexität wird in diesem Modell maßgeblich durch die Komponenten Geschwindigkeit, also die sich rasend schnell ändernden Umweltbedingungen, und gegenseitigen Abhängigkeiten derselben bestimmt. Um auf diese komplexen Probleme reagieren zu können, braucht es ein anpassungsfähiges Team. Dieses wird wiederum durch ein gemeinsames Bewusstsein innerhalb des Teams sowie durch Empowerment der Teammitglieder erreicht. Entscheidend ist dabei, dass eine gewisse Reihenfolge berücksichtigt wird. Zunächst sollte ein gemeinsames Bewusstsein geschaffen werden. Erst mit dieser einheitlichen Basis kann innerhalb eines Teams Empowerment stattfinden. McChrystal geht in seinem Buch sogar noch weiter, wenn er schreibt, dass Empowerment ohne ein gemeinsames Bewusstsein gefährlich sei. Er führt als Beispiel die Finanzkrise 2008 an, die zu einem großen Teil von jungen, unerfahrenen Bankern ins Rollen gebracht worden war, die zu viel Entscheidungsspielraum und zu wenig Anleitung bekommen hatten. Empowerment funktioniert demnach nicht, wenn innerhalb einer Organisation oder eines Teams die Verantwortung einfach „nach unten“ geschoben wird. Es ist sogar in hohem Maße gefährlich. Vielmehr müssen die Teammitglieder bereit und willens sein, Verantwortung zu übernehmen. L. David Marquet beschreibt diesbezüglich eine Episode in seinem Buch Turn the Ship Around!, in der sich Abteilungsleiter beim Executive Officer abmelden und fragen, ob es für sie noch etwas zu tun gäbe. Die Verantwortung für die Arbeiten der Abteilungsleiter bleibt damit laut Maquet beim Executive Officer. Vielmehr sollten Abteilungsleiter erklären, was sie bereits geschafft haben und was sie planen, als nächstes zu tun. Marquet bezeichnet das als „Leadership at all levels“ oder Intent-based Leadership, womit wir erneut beim Thema Selbstorganisation wären. Die beiden wichtigsten Zutaten, die den Kern des Konzepts von McChrystal bilden, fehlen jedoch noch. Diese sind ein gemeinsames, sinnhaftes Ziel und Vertrauen. Nur wenn alle Teammitglieder das gemeinsame Ziel kennen und teilen und den Sinn darin verstehen, können sie die einzelnen Stärken zielgerichtet einbringen und auf Aktionen anderer entsprechend reagieren. Dies erfordert ein gewisses Maß an Vertrauen innerhalb des Teams.
Wie wichtig Vertrauen unter Teammitgliedern ist, um Höchstleistungen erzielen zu können, ist auch daran erkennbar, dass Vertrauen die grundlegende Funktion im Modell von Patrick Lencioni ist. Es beschreibt fünf Funktionen und Dysfunktionen von TeamsDysfunktionen von Teams, die in Abbildung 8 dargestellt sind. Dieses Modell dient der Standortanalyse im Rahmen von Teamentwicklungsprozessen. Dabei gilt es Funktionen sicherzustellen und Dysfunktionen zu beenden, denn in dem Maße, wie sich Funktionen positiv auf die Leistungsfähigkeit von Teams auswirken, können Dysfunktionen den nachteiligen Effekt haben.
Abbildung 8:
Fünf Dysfunktionen von Teams
Vertrauen
Amy Edmundson, Professorin für Leadership an der Harvard Business School, hat den Begriff „psychologische Sicherheit“ geprägt. Damit beschreibt sie ein Umfeld des Vertrauens, in dem sich Teammitglieder sicher fühlen. Ihre Forschung hat ergeben, dass in solchen Teams vermeintlich mehr Fehler gemacht werden als in Teams, in denen kein gegenseitiges Vertrauen vorherrscht. Das ist allerdings ein Trugschluss. In Wahrheit hat das Umfeld der psychologischen Sicherheit zu einem anderen Umgang mit Fehlern geführt. Diese wurden offener angesprochen und das Team hat als Ganzes daraus gelernt. Es entstand eine offene Fehlerkultur, die am Ende zu hochperformanten Teams führen kann. Im Gegensatz dazu werden in Teams, in denen diese Kultur fehlt, Fehler und Missstände eher verheimlicht und vertuscht, was sich am Ende nachteilig auf das gesamte Team auswirkt.
Konfliktbereitschaft
Konflikte sind per Definition nichts Schlechtes. Ganz im Gegenteil, sie sind notwendig, um Neues entstehen zu lassen und Innovation voranzutreiben. Dieses Bewusstsein zu schärfen, ist ein wichtiger Bestandteil von Hochleistungsteams.
Selbstverpflichtung
Selbstverpflichtung bedeutet, sich als Teammitglied zur gemeinsamen Sache zu bekennen. Es beinhaltet auch, Verantwortung für das Team und das gemeinsame Ziel zu übernehmen. In Hochleistungsteams halten sich Teammitglieder keine Hintertüren offen. Das gemeinsame Ziel ist wichtiger als individuelle Ziele. Es gilt demnach, den Gemeinschaftssinn zu stärken.
Gegenseitige Verantwortlichkeit
Darf man sich in die Angelegenheiten anderer Teammitglieder einmischen? Im Sinne des gemeinsamen Ziels ist dies sogar erwünscht, sollten Beiträge einzelner nicht zielführend sein. Das gemeinsame Lernen und Erreichen des Ziels stehen im Vordergrund. Natürlich entwickelt sich dadurch eine gewisse Gruppendynamik, die zunächst irritieren mag, vor allem, wenn man als einzelner nicht daran gewöhnt ist. Da sich Anforderungen in heutiger Zeit rasend schnell ändern können, ist es notwendig, mit diesen zu wachsen, und zwar zusammen, da die Komplexität vieler Anforderungen die Zusammenarbeit vieler benötigt.
Zielorientierung
Klare und eindeutige Zieldefinitionen vermeiden, dass Status und Ego einzelner zu sehr wuchern. Vermehrt hört man heutzutage, dass auf Grund von Agilität klare und eindeutige Zielformulierungen nicht möglich sind. Das ist schlichtweg nicht richtig. Natürlich ist es nicht einfach, aber ein wesentlicher Teil von Führung – und das beschränkt sich nicht auf einen rein agilen Kontext – bedeutet auch, dem Team Sinn und Orientierung in der Arbeit zu vermitteln. Das kann in der Praxis beispielsweise durch eine klare und offene Kommunikation geschehen, wobei natürlich inhaltlicher Kontext genauso wichtig ist.
5 Scrum Artefakte – Die Übersicht behalten
Die Scrum ArtefakteScrum Artefakte gibt es inzwischen seit 25 Jahren und sie haben bis heute nicht an Bedeutung verloren. Wie in Kapitel 3.3 beschrieben, werden im aktuellen Scrum Guide die Artefakte Product Backlog, Sprint Backlog und Produktinkrement unterschieden. Mit dem Scrum Guide 2020 gibt es nun eine klare Zuordnung von Vereinbarungen („Commitment“) zu diesen drei Artefakten (siehe Abbildung 9).
Abbildung 9:
Zuordnung von Vereinbarungen zu Artefakten
Das Produktziel (Product Goal) wird als neue Begrifflichkeit eingeführt. Mit diesem Ziel soll beschrieben werden, was der Sinn des zu erstellenden Produkts ist. Zudem wird sichergestellt, dass das Product Backlog nicht zu einem Sammelsurium beliebiger User Stories, Tasks und Defects verkommt. Nun steht also das Produktziel als Leitbild über dem Product Backlog und mit jedem Sprint soll das Produkt näher an dieses Produktziel herangebracht werden. Wie wird aber das Produktziel festgelegt? Lassen Sie uns dazu einen kurzen Abstecher in die Historie des Projektmanagements machen, in eine Welt voller Visionen und Ziele.
5.1 Von der Vision zum Product Backlog
Früher wurden Visionen, Strategien und Taktiken formuliert, um ein Projekt vollständig zu beschreiben. Übergeordnet war die MissionMission, mit der festgelegt wurde, worauf das ganze Handeln ausgerichtet ist. Eine Mission bezieht sich daher nicht auf ein einzelnes Projekt oder Produkt. Im Gegensatz dazu beschreibt die Produkt- beziehungsweise Projektvision ein in der Zukunft liegendes, relativ konkretes Bild dessen, was mit dem jeweiligen Produkt oder Projekt angestrebt wird. Hiermit sollen die Unternehmensmission und die Unternehmensvision realisiert werden. Abbildung 10 verdeutlich den Zusammenhang zwischen der übergeordneten Unternehmensmission und der Produktvision.
Abbildung 10:
Mission und Produktvision
In der Vergangenheit wurde bei der Anwendung agiler Methoden die Formulierung einer Produktvision oder einer Produktstrategie gelegentlich vernachlässigt, obwohl diese von entscheidender Bedeutung ist. Insbesondere bei Scrum liegt der Schwerpunkt auf der taktischen Planungsebene. Mit der Etablierung des Produktziels wird nun endlich der Planungshorizont erweitert. In der Theorie klingt das einfach. Im alltäglichen Projektleben ist es jedoch nicht so trivial, ein Produktziel zu formulieren und an alle gleichermaßen zu vermitteln, da die Stakeholder häufig unterschiedliche Vorstellungen davon haben, was mit dem Projekt erreicht werden soll. In der Welt der Entwickler ist das Produktziel eine Ansammlung funktionaler und nichtfunktionaler Anforderungen, die von ihnen umgesetzt werden müssen. Aus Kundensicht wird ein Produkt in der Regel mit dem Ziel entwickelt, den Bedarf einer bestimmten Zielgruppe zu befriedigen und letztlich den Unternehmensgewinn zu steigern. Erschwerend kommt hinzu, dass die Formulierung eines Produktziels an der Produktvision ausgerichtet werden muss. Starten wir daher mit einer kurzen Abhandlung zur Produktvision, Produktstrategie und Taktik. Hierbei gehen wir insbesondere darauf ein, wie diese Themen zusammenhängen. Eine tiefergehende Begriffsdiskussion erfolgt nicht.