Der Scrum-Reiseführer. Tobias Renk

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.

      5.1.1 Von der Produktidee zur Produktvision

      Am Anfang steht die ProduktideeProduktidee, die mithilfe der ProduktvisionProduktvision beschrieben wird. Diese Produktvision soll die Projektstakeholder positiv auf die anstehenden Veränderungen, die sich mit der Einführung des Produkts ergeben, einstimmen. Sie schafft die tägliche Motivation, an einem Produkt zu arbeiten, das einen echten Zweck erfüllt. Eine Produktvision muss kurz und prägnant formuliert werden. Sie darf nicht langweilen und soll dabei die Neugierde auf das Produkt steigern. Das Projektteam sollte das Gefühl haben, an etwas Großem beteiligt zu sein. So darf die Produktvision beispielsweise nicht formuliert werden: „Mit einem Budget von 257.129 Euro wollen wir das Produkt Personalverwaltung I durch das Produkt Personalverwaltung II ersetzen. Beide Produkte haben exakt den gleichen Funktionsumfang, Personalverwaltung II ist nur schneller als Personalverwaltung I. Personalverwaltung II wird am 31.12.2055 produktiv gehen.“ Bei einer solchen Produktvision können sich die Projektmitarbeit schwer mit dem Produkt identifizieren. Sollten sie Zweifel gehabt haben, ob sie im richtigen Projekt sind, trägt dieser Vision eher dazu bei, dass sich die Mitarbeiter dazu motiviert fühlen, ein anderes Projekt zu suchen. Das Negativbeispiel ist nicht nur demotivierend formuliert, es ist auch eine Mischung aus Zielen, Erfolgsfaktoren