eBooks

Der Scrum-Reiseführer

Herausforderungen in der Praxis meistern

0809
2021
978-3-7398-8117-1
978-3-7398-3117-6
UVK Verlag 
Jörg Brüggenkamp
Peter Preuss
Tobias Renk

Agile Projektmanagement-Methoden, die vor allem in Startups zu finden sind, werden im Zuge der digitalen Transformation auch für größere Organisationen immer interessanter und wichtiger. In diesem Buch wird untersucht, welche konkreten Herausforderungen es bei der Einführung der Projektmanagement-Methode Scrum gibt und wie man diese bewältigen kann. Folgende Fragen werden mit dem Buch beantwortet: Was genau ist bei der Einführung der Scrum-Prozesse zu beachten? Wie ist das Scrum-Rollenverständnis und wie etabliert man diese Rollen in bestehenden Organisationen? Wie erreicht man, dass die Scrum-Events erfolgreich durchgeführt werden? Welche Metriken eignen sich besonders gut, um den Fortschritt agiler Projekte zu messen? Wie können Projektrisiken minimiert und Probleme frühzeitig erkannt werden? Welche Skalierungsframeworks gibt es, um Scrum auch für größere Projektteams und Organisationen nutzen zu können?

EIN BAND AUS DER GPM-REIHE PROJEKTMANAGEMENT NEU DENKEN GPM TREND Layout Layout ISBN 978-3-7398-3117-6 Dipl. Inf. Jörg Brüggenkamp ist geschäftsführender Gesellschafter der PMC - ProjektManagement- und Controlling GmbH in der Schweiz. Prof. Dr. Peter Preuss lehrt Wirtschaftsinformatik an der FOM Hochschule für Oekonomie & Management in Stuttgart. Er ist zertifizierter Project Management Professional (PMP) nach PMI und Professional Scrum Master. Dr. Tobias Renk ist Global Service Owner für den Bereich B2C Pricing der BP Europa SE. Er ist als Experte und Keynote Speaker zu den Themen Innovation, kultureller Wandel und digitale Transformation unterwegs. Agile Projektmanagement-Methoden, die vor allem in Startups zu finden sind, werden im Zuge der digitalen Transformation auch für größere Organisationen immer interessanter und wichtiger. In diesem Buch wird untersucht, welche konkreten Herausforderungen es bei der Einführung der Projektmanagement-Methode Scrum gibt und wie man diese bewältigen kann. Folgende Fragen werden mit dem Buch beantwortet: Was genau ist bei der Einführung der Scrum-Prozesse zu beachten? Wie ist das Scrum-Rollenverständnis und wie etabliert man diese Rollen in bestehenden Organisationen? Wie erreicht man, dass die Scrum- Events erfolgreich durchgeführt werden? Welche Metriken eignen sich besonders gut, um den Fortschritt agiler Projekte zu messen? Wie können Projektrisiken minimiert und Probleme frühzeitig erkannt werden? Welche Skalierungsframeworks gibt es, um Scrum auch für größere Projektteams und Organisationen nutzen zu können? Brüggenkamp, Preuss, Renk Der Scrum-Reiseführer Jörg Brüggenkamp, Peter Preuss, Tobias Renk Der Scrum- Reiseführer Herausforderungen in der Praxis meistern Herausgegeben von der PROJEKTMANAGEMENT NEU DENKEN Die Autor: innen der Reihe Projektmanagement neu denken zeichnen sich durch einen hohen Erfahrungsschatz in der Projektmanagementpraxis und fundierte Kenntnisse der Theorien in diesem Themengebiet aus. In den Bänden werden insbesondere neue Fachthemen und neue Herangehensweisen behandelt. Dabei steht der konkrete Nutzen für die praktische Anwendung im Vordergrund. Leser: innen dürfen sich demnach sowohl auf einen Wissenszuwachs als auch Tipps für den Praxisalltag freuen. Dipl. Inf. Jörg Brüggenkamp ist geschäftsführender Gesellschafter der PMC - ProjektManagement- und Controlling GmbH in der Schweiz. Er ist als Spezialist mit über 20 Jahren Erfahrung in den Bereichen Turnaround-/ Interims-Management im klassischen und agilen Umfeld tätig. Prof. Dr. Peter Preuss lehrt Wirtschaftsinformatik an der FOM Hochschule für Oekonomie & Management in Stuttgart. Er ist zertifizierter Project Management Professional (PMP) nach PMI und Professional Scrum Master. Parallel zu seiner Lehrtätigkeit ist Peter Preuss geschäftsführender Gesellschafter der Unternehmensberatung People Consolidated GmbH. Dr. Tobias Renk ist Global Service Owner für den Bereich B2C Pricing der BP Europa SE. Er ist als Experte und Keynote Speaker zu den Themen Innovation, kultureller Wandel und Digitale Transformation unterwegs. Außerdem ist er als Dozent für Unternehmensführung an der Dualen Hochschule Baden-Württemberg in Stuttgart tätig. Jörg Brüggenkamp, Peter Preuss, Tobias Renk Der Scrum-Reiseführer Herausforderungen in der Praxis meistern UVK Verlag · München © UVK Verlag 2021 ‒ ein Unternehmen der Narr Francke Attempto Verlag GmbH + Co. KG Dischingerweg 5 · D-72070 Tübingen Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Internet: www.narr.de eMail: info@narr.de CPI books GmbH, Leck ISSN 2748-4629 ISBN 978-3-7398-3117-6 (Print) ISBN 978-3-7398-8117-1 (ePDF) ISBN 978-3-7398-0142-1 (ePub) Umschlagmotiv: © iStockphoto pixdeluxe Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http: / / dnb.dnb.de abrufbar. 1 9 1.1 9 1.2 10 2 11 3 13 3.1 13 3.2 14 3.3 16 3.4 17 4 19 4.1 19 4.2 22 4.3 24 4.4 26 4.5 28 5 35 5.1 35 5.1.1 37 5.1.2 38 5.1.3 42 5.1.4 45 5.2 54 5.3 59 5.4 65 5.5 67 5.6 71 5.6.1 73 5.6.2 75 5.6.3 79 5.6.4 80 Inhalt Geleitworte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hanna Hennig (Siemens AG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dr. Silvia Rummel (Festo SE & Co. KG) . . . . . . . . . . . . . . . . . . . . . . . . . . Prolog - Agilität als Kernkompetenz für moderne Unternehmen . . . . . . . . . . Scrum Framework - Eine kurze Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Fundament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scrum Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scrum Artefakte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scrum Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scrum Rollen - Die Idealbesetzung eines Scrum Teams . . . . . . . . . . . . . . . . . Passende Rollenbesetzung als Erfolgsschlüssel . . . . . . . . . . . . . . . . . . . Entwickler als T-Shaped Professionals . . . . . . . . . . . . . . . . . . . . . . . . . . Scrum Master als Servant Leader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Product Owner als Wertmaximierer . . . . . . . . . . . . . . . . . . . . . . . . . . . . Führung und Teambildung in agilen Teams . . . . . . . . . . . . . . . . . . . . . . Scrum Artefakte - Die Übersicht behalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . Von der Vision zum Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . Von der Produktidee zur Produktvision . . . . . . . . . . . . . . . . . . . . . . . . . Von der Produktvision zur Produktstrategie . . . . . . . . . . . . . . . . . . . . . Von der Produktstrategie zu den Produktzielen . . . . . . . . . . . . . . . . . . . Von den Produktzielen zu den Sprintzielen und zurück zur Vision . . Product Backlog Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aufbau, Priorisierung und Sortierung des Product Backlogs . . . . . . . . Sprint Backlog -ToDo-Liste für den laufenden Sprint . . . . . . . . . . . . . Produktinkrement - Herausforderung in der Umsetzung . . . . . . . . . . Das Product Backlog und die Backlog Refinement-Aktivitäten . . . . . . Die drei Stufen der Detailierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Stories, Tasks und deren Schätzung . . . . . . . . . . . . . . . . . . . . . . . . Das Orakel und die Story Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Analyse als Allheilmittel vor der Planung . . . . . . . . . . . . . . . . . . . . 5.6.5 83 5.6.6 83 6 87 6.1 87 6.2 92 6.3 97 6.4 100 6.5 104 7 109 7.1 111 7.1.1 111 7.1.2 113 7.1.3 114 7.2 117 7.2.1 117 7.2.2 128 7.3 132 7.3.1 132 7.3.2 138 7.3.3 143 7.3.4 146 7.4 148 7.4.1 150 7.4.2 154 7.4.3 157 7.4.4 158 7.4.5 158 8 161 8.1 161 8.2 171 8.3 172 8.4 173 8.5 178 8.6 181 8.7 185 8.8 192 Business Value im Backlog Refinement . . . . . . . . . . . . . . . . . . . . . . . . . . Das Business Value-Trilemma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scrum Events - Effektive und effiziente Scrum Meetings . . . . . . . . . . . . . . . . Inkrementelle Produktentwicklung in Sprints . . . . . . . . . . . . . . . . . . . Sprint Planning - Was wird wie im Sprint gemacht? . . . . . . . . . . . . . Daily Scrum - Synchronisation des Entwicklerteams . . . . . . . . . . . . . . Sprint Review als zentrale Feedbackschleife . . . . . . . . . . . . . . . . . . . . . Kontinuierlich besser werden mit der Sprint Retrospektive . . . . . . . . Status-Reporting und Metriken - Risiken und Probleme managen . . . . . . . . Zielgruppen und Informationsbedarf . . . . . . . . . . . . . . . . . . . . . . . . . . . Grundlagen zu Kennzahlen im agilen Umfeld . . . . . . . . . . . . . . . . . . . . Metriken und Zielgruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zielgruppenbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kennzahlen im agilen Umfeld verstehen und festlegen . . . . . . . . . . . . Standard Metriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ermittlung von Metriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metriken als Präventionsmaßnahme gegen Fehlentwicklungen . . . . . Backlog-Gesundheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kapazität und Auslastung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fortschrittsstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sprint Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Herausforderungen, Widerstände und Lösungsansätze . . . . . . . . . . . . Herausforderung „agile Methoden“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Herausforderung „Team“ und „Werkzeuge“ . . . . . . . . . . . . . . . . . . . . . . Herausforderung „Ausrichtung/ Skalierung“ und „Führung“ . . . . . . . . Herausforderung „Produktnutzen“ und „Produktfinanzierung“ . . . . . Herausforderung „Reorganisation“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agile Skalierung - Auf dem Weg zur lernenden Organisation . . . . . . . . . . . . Wenn mehr als ein agiles Team benötigt wird . . . . . . . . . . . . . . . . . . . . Beispiel: Autonome Zwei-Pizzen-Teams bei Amazon . . . . . . . . . . . . . . Welchen Zweck erfüllen Skalierungsframeworks? . . . . . . . . . . . . . . . . Scrum skalieren mit LeSS und LeSS Huge . . . . . . . . . . . . . . . . . . . . . . . Scrum skalieren mit Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Neuaufstellung der Organisation mit dem Spotify-Ansatz . . . . . . . . . . Agile Skalierung für große Organisationen mit SAFe . . . . . . . . . . . . . . Wahl des richtigen Skalierungsframeworks . . . . . . . . . . . . . . . . . . . . . . 6 Inhalt 9 195 197 199 Epilog von Dr. Christopher Jud (Kaufland Digital) . . . . . . . . . . . . . . . . . . . . . . . Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Inhalt 1 Geleitworte 1.1 Hanna Hennig (Siemens AG) Unsere VUCA-Welt verlangt Unternehmen einiges ab: Sie sollen mit zunehmend kom‐ plexen und unsicheren Bedingungen umgehen lernen. Sie sollen resilienter werden. Sie sollen mit der digitale Transformation Schritt halten und Zukunft vorausdenken können. Verändern sich die Zukunftsbedingungen, sollen sie die neuen Parameter zügig in ihr „System“ adaptieren. Was dies tatsächlich bedeuten kann, hat nicht zuletzt die Corona-Pandemie drastisch vor Augen geführt. Von jetzt auf gleich waren Betriebe gefordert, Zusammenarbeit neu zu denken. Wer sich schnell ein- und umstellen konnte, hatte einen klaren Vorteil am Markt. Wo Zukunft sich auf Tagesbasis verändern kann, ist Flexibilität Schlüssel zum Erfolg. Agile Konzepte wie Scrum stellen dafür ein methodisches Gerüst. Doch „Agile“ ist längst mehr als nur flexibles, prozessorientiertes Arbeiten. Es hat sich von einer Methode zu einer Kultur entwickelt, die Unternehmen durch und durch prägen kann. Als „Business Agility“ nimmt es nun auch Einfluss auf die strategische Ausrichtung und auf das Verständnis von Leadership. Auch bei Siemens setzen wir auf Agilität. Die Digitalisierung eröffnet großartige Chancen zur Innovation, von denen unsere Kunden und wir vielseitig profitieren können. Indem wir unsere Software- und Produktentwicklung und das Projektma‐ nagement agil aufsetzen und begleitende Abläufe digital optimieren, können wir die Go-to-Market-Time für Produkte, Lösungen und Services wesentlich beschleunigen. Das digitale Zeitalter ist agil geprägt. Gerade großen Konzernen mit komplexen, oft verfestigten Strukturen bietet Scrum ideale Instrumente, die Neues zulassen, das Bewährte jedoch nicht gefährden. Und Startups ermöglicht Scrum eine hoch effiziente Methode der Ideenentwicklung bis zur Marktreife. Bei der Einführung agiler Methoden sind jedoch manche Hürden zu nehmen, das haben auch wir „by doing“ gelernt: von falsch verstandenen Rollen, über Probleme in der Kommunikation und Kooperation bis zum gänzlichen Abhandenkommen des „Big Picture“. Es gilt, Gründer, Entscheider, Projektmanager und Innovationstreiber auf diese neue, agile Art von Arbeiten besser vorzubereiten. Ich freue mich, dass sie in diesem Leitfaden eine wunderbar komprimierte Einführung in die Scrum-Methodik mit sehr wertvollem, anwendungsorientiertem Know-how finden. Hanna Hennig CIO Siemens AG 1.2 Dr. Silvia Rummel (Festo SE & Co. KG) Aufgrund von Digitalisierung und Datenverfügbarkeit ändern sich mit atemberauben‐ dem Tempo die Kundenanforderungen und die Wettbewerbsbedingungen. Die heute zur Verfügung stehenden digitale Produkte und Services ermöglichen es den Kunden, ein noch nie dagewesenes Spektrum an Funktionalitäten zu nutzen. Dabei ist es egal, an welchem Ort sich die Nutzer befinden oder zu welcher Zeit die Services benötigt werden, den Möglichkeiten sind keine Grenzen gesetzt. So faszinierend und beeindruckend es auch ist, diesen Wandel zu beobachten, so herausfordernd ist es gleichzeitig für die Unternehmen, die diese Produkte herstellen. Wo bis dato das physische Produkt und dessen einmaliger Erwerb im Vordergrund stand, rücken nun Services mit der Generierung von Mehrwerten in den Mittelpunkt für die Konsumenten. Dieser drastischen Veränderung des Produkt- und Konsumen‐ tenverhaltens sind bisherige Organisationsansätze kaum gewachsen. Über Dekaden hinweg wurden Entwicklungsprozesse dahingehend optimiert, physische Produkte in Form von Projekten innerhalb von kürzester Zeit und mit technischer Raffinesse zu realisieren. Mit Erfolg - doch nun gilt es, dieses Vorgehen auf ein neues Level zu bringen und Software als Bestandteil des Produktes zu sehen, um den veränderten Kundenanforderungen gerecht werden. Durchschreitet eine Organisation diese Veränderung und nimmt sich der digitalen Transformation in all ihren Facetten an, wird dies auch zu einem Umdenken bei der Projektarbeit führen. Erfahrene Teams kommen mit traditionellen Projektmanage‐ ment-Methoden hier schnell an ihre Grenzen. Um dennoch den vorgegebenen Zielkor‐ ridor (Zeit, Budget und Qualität) zu erreichen, sind alternative Methoden erforderlich. Die Lösung: Scrum als agile Form des Arbeitens. Dies ermöglicht ambitionierten und motivierten Teams schnell Erfolge zu erzielen und dennoch strukturiert vorzugehen. Mit dem vorliegenden Buch bekommen Führungskräfte, Projektmanager und Pro‐ jektleiter in Organisationen, welche sich dem Thema digitale Transformation bereits angenommen haben oder sich gerade auf dem Weg dahin befinden, einen Praxisleitfa‐ den an die Hand. Es wird ein umfangreicher Einblick in das Scrum Rollenverständnis, die Scrum Artefakte und die Scrum Events gegeben. Dabei wird viel Wert auf Verständ‐ lichkeit und Praxisbezug gelegt. Den Autoren ist mit dem „Scrum-Reiseführer“ ein übersichtliches und zugleich zielgerichtetes Buch für die Unternehmenspraxis gelungen. Ich wünsche mir für die Autoren, dass das Verständnis und die Anwendbarkeit agiler Projektmanagement-Me‐ thoden in Organisationen weiter zunehmen. Mit diesem Buch wird Managern und Projektteams die „Hürde der Veränderung“ hin zu mehr agilem Vorgehen genommen und durch Systematik und anschauliche Erläuterungen zugänglich gemacht. Dr. Silvia Rummel Head of Energy Efficency & CO2 Footprint Portfolio Festo SE & Co. KG 10 1 Geleitworte 2 Prolog - Agilität als Kernkompetenz für moderne Unternehmen Man hört, sieht und liest es überall. Unsere Welt ist im ständigen Wandel. Das war schon immer so und ist nicht überraschend. Der Wandel selbst verändert sich stetig und erhöht seine Geschwindigkeit merklich. Bis in die 1990er Jahre war es üblich, strategische Pläne zu erstellen, deren Umsetzung sich über mehrere Jahre erstreckte. Am Ende des letzten Jahrzehnts im alten Jahrtausend geschah jedoch eine technische Revolution, die den Stein des immer schneller werdenden Wandels ins Rollen brachte: Die Kommerzialisierung des Internets. Dies führte dazu, dass viele Annahmen, die noch einige Jahre vorher durchaus sinnvoll und langlebig waren, nun in Frage gestellt werden mussten. Informationen waren nun für jeden zugänglich. Smartphones führten einige Jahre später dazu, dass jeder Nutzer das Internet in der Hosentasche bei sich trug und damit jederzeit und überall auf der Welt erreichbar war. Die sich entwickelnde Cloud-Technologie bot jedem einen Supercomputer an. Das hatte zur Folge, dass plötzlich Eintrittsbarrieren in ganze Branchen wegfielen oder erheblich minimiert wurden. Wenn plötzlich Konkurrenz sprichwörtlich aus dem Nichts kommen kann, weil ein smarter Student am Küchentisch eine Software schreibt, dann kann die Antwort darauf nicht mehr lauten, mehrjährige Strategiepläne zu entwickeln. Unternehmen müssen sich seitdem so aufstellen, dass sie schnell und flexibel auf Änderungen im Unternehmensumfeld reagieren können. Es kommt noch eine Herausforderung dazu: Die soeben beschriebenen Veränderungen treten in Zyklen auf, die sich nicht nur öfter als in der Vergangenheit an der Oberfläche zeigen - Nein. Auch die Abstände zwischen den Zyklen werden kürzer. Eric Schmidt und Jonathan Rosenberg beschreiben die Situation in ihrem Buch „How Google Works“ so, als ob Moores Gesetz Amok läuft. Die beiden Gegebenheiten - schnelle Veränderungen in kürzer werdenden Abstän‐ den - haben zu einer neuen Begriffsbildung geführt. Der Ausdruck VUCA beschreibt diese neue Welt. VUCA ist dabei ein Akronym für die englischen Begriffe Volatility (Unbeständigkeit), Uncertainty (Unsicherheit), Complexity (Komplexität) und Ambi‐ guity (Mehrdeutigkeit). Die Vorhersehbarkeit bestimmter Ereignisse ist sehr schwierig, wenn nicht gar unmöglich geworden. Wer konnte schon vorhersehen, dass eine Revolte eines Händlers, wie es sie viele gibt, zu einer der größten Revolutionsbewegungen, dem Arabischen Frühling, wird - weil sie von einer zufällig anwesenden Person mit einem Smartphone gefilmt und online gestellt wurde. Das gleiche Prinzip gilt auch auf Unternehmensebene. Die Vorhersagbarkeit nimmt ab und führt zu Verunsicherungen. Gleichzeitig nimmt die Komplexität im Unternehmensumfeld zu und unterschiedliche Perspektiven vermischen sich. Trennungen, die früher eindeutig waren und aufgrund derer es zumindest mit großem Aufwand möglich war, einigermaßen gesicherte Annahmen zu treffen, gibt es heute nicht mehr. Immer häufiger gibt es unübersehbare Geflechte aus Reaktionen und Gegenreaktionen. Vielzitierte Best Practice-Erfahrungen sind nutzlos geworden, da sich gesuchte Antworten nicht mehr von bereits gestellten, ähnlichen Fragestellungen ableiten lassen. In anderen Worten: Wo genau die Reise hinführt, ist nach der Abfahrt eigentlich noch gar nicht klar. Wie lautet nun die Gegenantwort auf VUCA? Wie können Unternehmen mit dieser neuen Situation umgehen? Was können sie tun? Auf der Internetseite vuca-welt.de wird eine Antwort geliefert, die sich ihrerseits selbst mit dem Akronym VUCA abbilden lässt. Nur stehen die Buchstaben diesmal für Vision, Understanding (Verstehen), Clarity (Klarheit) und Adaptability (Anpassungsfähigkeit) oder Agility (Agilität). Wer ein kon‐ kretes Ziel vor Augen hat, kann Sinn stiften, Mitarbeiter für sich gewinnen und diese auf ein gemeinsames Ziel einschwören. Nachvollziehbare Zusammenhänge, Klarheit durch Offenheit und Transparenz sorgen dafür, dass sich Mitarbeitende auf das, was wirklich zählt, fokussieren können. Und da die Zukunft trotz aller Bemühungen nicht exakt vorhersagbar ist, müssen Unternehmen - und damit auch die Mitarbeitenden - in der Lage sein, sich schnell auf Veränderung einzustellen und neue Erkenntnisse, die während der Reise erlangt werden, in den noch verbleibenden Weg einzuarbeiten. Damit wird Agilität zu einer echten Kernkompetenz moderner Unternehmen. Mehr noch, Agilität wird zu einem wichtigen Wettbewerbsvorteil. Mit dieser Anpassungsfähigkeit bzw. Agilität befasst sich dieser Reiseführer. Die Autoren haben sich dabei für das Scrum-Rahmenwerk entschieden. Dieses beschreibt eine Methode, wie Agilität in Unternehmen eingeführt werden kann. Die Auswahl von Scrum fiel den Autoren dabei leicht. Scrum, oder adaptierte Versionen davon, die im Verlauf dieses Buches behandelt werden, ist in der Praxis die beliebteste und am häufigsten verwendete agile Methode. Diese Methode soll Unternehmen in die Lage versetzen, produktiv und kreativ Produkte mit höchstmöglichem Wert zu entwi‐ ckeln und sich zügig an sich ändernde Rahmenbedingungen anzupassen. Der Begriff Scrum hat seinen Ursprung im Rugby und leitet sich aus dem englischen Begriff für Gedränge ab. Hiermit soll verdeutlicht werden, dass die Entwicklungsteams, die sich dem Scrum-Modell bedienen, insbesondere durch kooperatives, selbstverantwortliches und selbstorganisiertes Verhalten erfolgreich sind. Die beiden Scrum-Erfinder Ken Schwaber und Jeff Sutherland beschrieben ihr Rahmenwerk erstmals im Scrum Guide im Jahr 2010. Die Ausführungen in diesem Buch basieren auf dem Scrum Guide, der im November 2020 veröffentlicht wurde. Diese siebte Auflage trägt den Titel „The Scrum Guide. The Definite Guide to Scrum: The Rules of the Game“, was als Indiz interpretiert werden kann, dass in näherer Zukunft keine Aktualisierungen geplant sind. Lassen Sie sich nun verzaubern, was in der Theorie alles möglich ist und wie es in der agilen Wirklichkeit zugeht. Freuen Sie sich auf ein beeindruckendes agiles Team auf dem Weg zum Erfolg und bestaunen Sie die Scrum Artefakte in ihrem ganzen Glanz der praktischen Nutzbarkeit. Erleben Sie, wie jedes einfache Scrum Meeting zu einem Event des Austausches und der Erkenntnis wird. Erkunden Sie in einer einmaligen Tour die tiefen Höhlen der Reports und bereiten Sie sich auf größere Dinge vor, die vor Ihnen liegen könnten, auf der Reise in die weite Welt der Agilität. 12 2 Prolog - Agilität als Kernkompetenz für moderne Unternehmen T r a n s p a r e n z Ü b e r p r ü f u n g A n p a s s u n g Mut Selbstverpflichung Fokus Offenheit Respekt Figure 1: Säulen und Werte von Scrum Abbildung 1: Säulen und Werte von Scrum 3 Scrum Framework - Eine kurze Einführung In diesem Kapitel werden in einem Schnelldurchlauf die Werte und Prinzipien sowie die Rollen, Artefakte und Events des Frameworks vorgestellt, auf denen Scrum basiert. Es dient dazu, sich schnell einen Überblick zu verschaffen, bevor die angerissenen Themen in den nachfolgenden Kapiteln tiefergehend und insbesondere in Hinblick auf die praktische Anwendbarkeit behandelt werden. 3.1 Das Fundament Scrum basiert auf der empirischen Prozesssteuerung. Ziel dieser Empirie ist es, Wissen aus gewonnen Erfahrungen abzuleiten und so bessere Entscheidungen zu treffen. Damit man in kurzen Zeitabständen die Möglichkeit zur Prüfung und Anpassung hat, verfolgt Scrum einen iterativen, inkrementellen Ansatz für die Produktentwicklung. So wird nicht nur erreicht, dass die Erfahrungswerte schneller in klügere Entscheidungen münden. Mit dieser Vorgehensweise können auch mögliche Risiken frühzeitig identi‐ fiziert und angegangen werden. Die empirische Prozessteuerung spiegelt sich in drei Säulen, auf denen Scrum basiert, wider: Transparenz, Überprüfung und Anpassung. Scrum wurde ursprünglich für das Soft‐ wareumfeld entwickelt. Mittlerweile be‐ wegt sich dieses Vorgehensmodell je‐ doch nicht mehr nur in seinem originären Bereich, sondern kann allge‐ mein im Bereich Produktentwicklung eingesetzt werden. Dem Entwicklungs‐ prozess von Software wird unterstellt, so umfassend zu sein, dass eine detaillierte Planung der einzelnen Schritte vorab nicht möglich ist. Somit sind regelmä‐ ßige Prüfungen und Transparenz zen‐ trale Elemente. Sämtliche Prozess‐ schritte sind dann für alle Beteiligten ersichtlich. Das sind Grundvorausset‐ zungen, um zum einen unerwünschte Veränderung umgehend festzustellen und zum anderen schnell korrigierend eingreifen zu können. Das erscheint zunächst nicht sehr neu. Was allerdings bei Scrum und anderen Methoden, wie beispielsweise dem Lean Start-up, mehr in den Vorder‐ grund rückt, ist die Dauer bis zu einer Prüfung. Diese ist deutlich kürzer als bei tradi‐ tionellen Projektmethoden, wie zum Beispiel beim Wasserfall. Auf diesen Aspekt wird in diesem Buch noch näher eingegangen, sobald wir uns dem Thema Sprint widmen. Neben den drei Säulen besteht der Scrum Guide seit 2016 aus fünf Werten, die das Rahmenwerk unterstützen und komplettieren: Selbstverpflichtung, Mut, Fokus, Offenheit und Respekt (siehe Abbildung 1). Die Personen im Entwicklungsteam ver‐ pflichten sich gemeinsam, die Ziele zu erreichen und schaffen dadurch eine kollektive Selbstverpflichtung. Durch Mut sollen komplexe Aufgabenstellungen mithilfe kreati‐ ver Lösungen realisiert werden. Der Fokus des Entwicklungsteams liegt ausschließlich auf dem Erreichen des gemeinsamen Ziels. Dabei sollen sich die Tätigkeiten auf die wesentlichen Aktivitäten konzentrieren, um Kapazitäten nicht zu verschwenden. Durch Offenheit soll Herausforderungen und Erfolge verdeutlichen. Diese fünf Werte sollen zu kontinuierlichen Verbesserungen beitragen. Agile Entwicklung nach Scrum setzt einen verständnisvollen Umgang innerhalb des Entwicklungsteams voraus. Die‐ ser umfasst gegenseitigen Respekt, Wertschätzung und die Berücksichtigung von individuellen Befindlichkeiten. 3.2 Scrum Rollen Ein Scrum Team hat immer einen Product Owner, einen Scrum Master und mehrere Entwickler. Die Verantwortung für das zu entwickelnde Produkt liegt beim Product Owner. Er ist daher insbesondere verantwortlich für die Wertmaximierung und die Qualität des Produkts. Das Entwicklungsteam arbeitet selbstorganisiert und in iterativen Schleifen am Projektprodukt. Ein Entwicklungsteam sollte mindestens drei und nicht mehr als neun Mitglieder haben, da der Kommunikationsaufwand mit jedem zusätzlichen Teammitglied erheblich zunimmt. In Abbildung 2 sieht man, dass bei einem Team mit sieben Mitgliedern 21 mögliche Beziehungen bestehen. Erweitert man das Team um nur zwei weitere Mitglieder ergeben sich bereits 36 Beziehungen. Bis zu 105 stolze Kommunikationsvariationen erreicht ein Team mit 15 Mitgliedern. Auf den Aspekt der Teamgröße wird in einem späteren Kapitel nochmals eingegangen, wenn die Zwei-Pizzen-Regel von Amazon vorgestellt wird. 14 3 Scrum Framework - Eine kurze Einführung Figure 2: Beziehungen innerhalb eines Teams Abbildung 2: Beziehungen innerhalb eines Teams Die Kernaufgaben des Scrum Masters bestehen darin, im Team Verständnis für das Scrum Framework zu schaffen und dafür zu sorgen, dass das Regelwerk eingehalten wird. Zudem ist er Ansprechpartner, um alle Probleme zu beseitigen, die das Team an der Zielerreichung behindert. Dabei ist der Punkt Regelwerk ein Thema für sich. Während mit dem Begriff eine gewisse Starrheit und Gehorsam in der Führung assoziiert werden könnten, steckt darin bereits ein Grund, weshalb in der Praxis die Einführung von Scrum Probleme bereitet. Es geht weniger darum, Scrum à la Textbuch einzuführen, sondern die Gegebenheiten der Organisation miteinzubeziehen und die passende Variante von Scrum zu finden. Letztendlich ist das doch der Kern einer agilen Organisation, oder? Bisher gab es mit dem Product Owner, dem Scrum Master und dem Development Team drei Scrum Rollen, die zusammen das Scrum Team bildeten. Im Scrum Guide 2020 wurde das Development Team gestrichen und die Rollen durch die drei Verantwortun‐ gen (Accountabilities) Scrum Master, Product Owner und Developer ersetzt. So kommt es nicht mehr zu der häufigen Frage, ob der Scrum Master oder der Product Owner nicht Teil des Teams sind. In Großunternehmen hat die bisherige Team-im-Team-Struktur häufig zusätzlich dazu geführt, dass unnötige Hierarchieebenen in die Scrum Teams einbezogen wurden und die Development Teams an ihre Product Owner berichten mussten. Mit der Abschaffung des Development Teams wird hervorgehoben, dass alle Mitglieder eines Scrum Teams gemeinsam für die produktbezogenen Aktivitäten verantwortlich sind. Dazu muss das Scrum Team so aufgestellt sein, dass es alle notwendigen Fähigkeiten vereint, um mit jedem Sprint mindestens ein neues Produk‐ tinkrement zu schaffen. Der Verantwortungsbereich eines Developers ist hierbei nicht auf die Softwareentwicklung begrenzt. Grafikdesigner, Experten aus dem Fachbereich oder Linienmanager können beispielsweise auch inhaltlichen Mehrwert liefern. 15 3.2 Scrum Rollen Das Scrum Team ist selbstverwaltend (self managing) und nicht mehr selbstorga‐ nisierend (self organised). In der Folge bedeutet das nicht nur einen Austausch der Begrifflichkeiten. Der Fokus wird dadurch noch stärker auf die Eigenverantwortung des Scrum Teams gelenkt. Allein das Team ist verantwortlich für alle produktbezogenen Aktivitäten. Hierfür muss es sich selbst verwalten. Es muss also dazu befähigt werden, selbst entscheiden zu können, welche Arbeiten wie zu erledigen sind und wer sich wann darum kümmert. 3.3 Scrum Artefakte Unter Artefakten versteht man Prozessdokumente, die während eines Projekts erstellt werden. Scrum kennt die drei Artefakte Product Backlog, Sprint Backlog und Produk‐ tinkrement. Das Product Backlog listet die priorisierten Anforderungen an das zu erstellende Produkt auf. Diese Aufstellung ist niemals vollständig und existiert in der Regel so lange, wie das Projektprodukt entwickelt wird. Der Product Owner ist für das Product Backlog verantwortlich und überarbeitet kontinuierlich die Backlog-Anforde‐ rungen und deren Prioritäten. Das bedeutet, dass er die Einträge regelmäßig verfeinert, das Backlog um neue Anforderungen erweitert und obsolet gewordene Anforderungen aus der Aufstellung löscht. Je wichtiger eine Anforderung ist, desto detaillierter muss sie ausformuliert und desto größer muss deren Priorität sein. Beschrieben werden die Anforderungen häufig in Form von User Stories. Das Sprint Backlog enthält die Product Backlog-Einträge, die in der aktuellen Projektiteration umgesetzt werden sollen. Diese Einträge werden auch als Sprint Backlog Items bezeichnet. Die Verantwortung für das Sprint Backlog liegt beim Entwicklerteam. Das bedeutet insbesondere, dass das Team entscheidet, welche Product-Backlog-Einträge es in der nächsten Iteration bearbeitet und wie diese in detaillierte Aufgaben (Tasks) unterteilt werden können. Während eines Sprints wird das Sprint Backlog nach der Erledigung eines Tasks vom Entwicklerteam aktualisiert. Das Ergebnis einer Iteration bezeichnet man als Produktinkrement. Dieses Artefakt besteht somit aus den in der aktuellen Iteration umgesetzten User-Stories und allen Anforderungen, die bereits in den vorherigen Iterationen realisiert wurden. Wichtig ist, dass jedes Produktinkrement release-fähig ist, also potenziell an den Kunden ausgeliefert werden kann. Im neuen Scrum Guide wird das Produktziel (Product Goal) als zusätzliche Begriff‐ lichkeit eingeführt. Dieses Ziel beschreibt, was der Sinn des zu erstellenden Produkts ist. Eine konkrete Benennung des Sinns vermeidet eine willkürliche Ansammlung von Features, Tasks und Defects. So steht das Produktziel als Leitbild über dem Product Backlog und mit jedem Sprint wird das Produkt näher an dieses Produktziel herangebracht. Die Einführung des Produktziels ermöglicht es, jedem Scrum Artefakt eine klare Zuordnung (Commitment) zuzuweisen: Das Produktziel gehört zum Product Backlog, das Sprintziel zum Sprint Backlog und die Definition of Done zum Produktinkrement. 16 3 Scrum Framework - Eine kurze Einführung Diese drei Commitments sollen die Transparenz erhöhen und den Entwicklungsfort‐ schritt sicht- und messbarer machen. Das Produktziel wird vom Product Owner entwickelt und gilt für das gesamte Scrum Team. Das Sprintziel wird vom Scrum Team festgelegt und ist die selbstverpflichtende Zielvorgabe für den aktuellen Sprint. Die Abschlusskriterien für ein Produktinkrement (Definition of Done) werden vom Scrum Team in Einklang mit den Organisationsvorgaben erstellt. Die Entwickler verpflichten sich dazu, diese Kriterien bei der Erstellung des Produktinkrements zu erfüllen. Der Scrum Guide 2020 ermöglicht die Erstellung mehrerer Produktinkremente in einem Sprint. In der Vergangenheit war es notwendig, bis zum Sprintende zu warten, um ein neues Produktinkrement produktiv setzen zu können. Stattdessen gilt nun: Jedes Mal, wenn ein Product Backlog Item die Definition of Done erfüllt, gibt es ein neues Produktinkrement. Diese Inkremente können also auch während eines Sprints abgenommen und theoretisch ausgeliefert werden. Dadurch wird nicht nur eine kontinuierliche Auslieferung ermöglicht, die Änderung führt hoffentlich auch dazu, dass das Sprint Review nicht mehr als „Freigabe-Veranstaltung“ missinterpretiert wird. Ziel des Sprint Reviews ist es vielmehr, anhand der Prüfung der erstellten Produktinkremente neue Impulse für das Product Backlog zu bekommen, um so die zukünftigen Sprintziele noch besser am Produktziel ausrichten zu können. Damit sind wir bereits mittendrin in den Scrum Events. 3.4 Scrum Events Das Vorgehensmodell Scrum beinhaltet fünf Ereignisse mit festgelegter Dauer. Dazu gehören der Sprint, das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospektive. Der einbis vierwöchige Sprint repräsentiert einen vollständigen Iterationslauf. Innerhalb dieser Zeitspanne findet die eigentliche Entwicklungsarbeit statt und es werden die übrigen vier Ereignisse praktiziert. Endet ein Sprint, startet direkt im Anschluss die nächste Iteration. Ein Sprint kann vom Product Owner jederzeit abgebrochen werden. Der Sprint wird mit dem Ereignis Sprint Planning eröffnet. In diesem Meeting stellt der Product Owner das Ziel des Sprints vor. Das Entwicklungsteam erstellt das Sprint Backlog, indem es so viele Anforderungen aus dem Product Backlog übernimmt, wie es in einem Sprint umsetzen kann. Während des Sprints findet täglich zur gleichen Zeit das Daily Scrum statt. Dies ist ein kurzes Meeting, in dem jeder Entwickler auf seine aktuelle Arbeit eingeht und den Fortschritt bis zum nächsten Daily Scrum prognostiziert. Hierzu beantworten die Entwickler üblicherweise nacheinander folgende drei Fragen: 1. Was war mein Beitrag zum Sprintziel seit dem letzten Daily Scrum? 2. Welche Aktivitäten plane ich bis zum nächsten Daily Scum? 3. Sehe ich Hindernisse, die mich oder das Entwicklungsteam vom Erreichen des Sprintziels abhalten? 17 3.4 Scrum Events Die beiden übrigen Ereignisse folgen am Ende eines Sprints. Zunächst wird im Sprint Review das erstellte Produktinkrement vorgestellt. An dieser Veranstaltung nehmen das ganze Scrum Team und die Projekt Stakeholder teil. Ziel ist es, von den Stakeholdern ein Feedback über das Produktinkrement zu erhalten. Dieses wird anschließend ge‐ nutzt, um das Product Backlog anzupassen und um neue Anforderungen aufzunehmen. In der abschließenden Sprint Retrospektive reflektiert das Team den Verlauf und diskutiert Verbesserungsmöglichkeiten für den nächsten Sprint. Während eines Sprints findet die Entwicklungsarbeit an den Sprint Backlog Items statt. Gestartet wird mit dem Sprint Planning Meeting. In dieser Besprechung fokussiert man sich auf folgende zwei Fragestellungen: Was kann in diesem Sprint realisiert wer‐ den und wie wird diese Arbeit umgesetzt? Das Entwicklungsteam übernimmt im ersten Teil der Planungssitzung so viele User Stories aus dem Product Backlog in das Sprint Backlog, wie es im Sprint umsetzen kann. Hieraus abgeleitet formuliert das gesamte Scrum Team das Ziel des Sprints. Im zweiten Teil überlegt das Entwicklungsteam, welche Tasks zum Erreichen ihres Sprintziels und zur Abarbeitung der ausgewählten Product Backlog-Items notwendig sind. Im Sprint Planning ging es bisher um die Beantwortung von zwei zentralen Fra‐ gestellungen: Die Entscheidung, welche Product Backlog Items im nächsten Sprint bearbeitet werden sollen und wie diese realisiert werden können. Im aktuellen Scrum Guide kommt nun eine dritte Fragestellung hinzu: Warum ist der Sprint sinnvoll bzw. wie kann der Wert des Sprints am effektivsten maximiert werden? Mit der genauen Beschreibung dieses Sprintziels bekommt das selbstverwaltende Team eine klare Richtschnur für den Sprint. In Abbildung 3 wird das Zusammenspiel der Scrum Rollen, der Scrum Events, der Scrum Artefakte und der zugehörigen Commitments dargestellt. Sprint (1-4 Wochen) Sprint Review Sprint Planning alle 24 Stunden P r i o r i t ä t d e r U s e r S t o r i e s Retrospektive Product Backlog Sprint Backlog Product Owner Scrum Master Scrum Team Scrum Artefakt Scrum Ereignis Produktinkrement Produktinkrement PO SM Entwickler E E E E E E Daily Scrum In Tasks verfeinerte User Stories Commitment Definition of Done Sprintziel Produktziel Figure 3: Scrum Framework Abbildung 3: Scrum Framework 18 3 Scrum Framework - Eine kurze Einführung 4 Scrum Rollen - Die Idealbesetzung eines Scrum Teams Unsere Reise in Scrum ist weniger auf den Individualtouristen ausgerichtet, sondern erlangt seine volle Pracht erst in einer Gruppe, die zu einem echten Team werden soll. Lernen Sie daher die Wege kennen, die auch abseits grauer Theorie einen perfekten Blick auf das Wesentliche bei der Teamzusammensetzung geben. 4.1 Passende Rollenbesetzung als Erfolgsschlüssel Wie in jedem Team ist die passende Rollenbesetzung wichtig. Eine Reisegruppe zu den Pyramiden Südamerikas hat viel mehr Spaß, wenn ein kenntnisreicher Reiseführer dabei ist. Eine Fußballmannschaft ohne Torwart dürfte es schwer haben, Spiele zu gewinnen. Und auch ein American Football Team dürfte vor großen Herausforderun‐ gen stehen, ohne Quarterback im Super Bowl zu brillieren. Auch Scrum „benötigt“ bestimmte Rollen, damit es in der Praxis gut funktionieren kann. Scrum macht es sich dabei sehr einfach, denn es gibt nur drei Rollen: Den Product Owner, den Scrum Master und das Entwicklungsteam. Wie die Rollenbezeichnungen schon andeuten, sind der Product Owner und der Scrum Master jeweils eine Person, das Entwicklungsteam jedoch eine Gruppe (siehe Abbildung 4). Endanwender Management Kunde Entwickler Product Owner Scrum Master Scrum Team Figure 4: Rollen in einem Scrum Team PO SM E E E Abbildung 4: Rollen in einem Scrum Team Ein wesentlicher Aspekt von Scrum ist, dass es prinzipiell keine Hierarchien innerhalb des Teams gibt. Zwar hat jede Rolle die ihr zugeordneten Aufgaben, für die sie jeweils auch verantwortlich ist, aber ein hierarchisches Gefälle, in dem eine Person Anweisungen erteilt, die dann nur noch von anderen ohne Hinterfragen um‐ gesetzt werden, wird klar vermieden. Diese Freiheit hat Vor- und Nachteile. Einerseits wird das Wissen aller Teammitglieder eingebracht, was in der aktuellen VUCA-Welt sinnvoll und notwendig ist - die notwendige Expertise für eine Produktentwicklung konzentriert sich auf Grund der Komplexität nicht in einem Individuum. Andererseits gibt es in der Praxis Momente, in denen der eine oder die andere sich ein bisschen „Basta“-Mentalität zurückwünscht, um längere Diskussionen abwürgen zu können. Und damit sind wir schon bei einem Kernthema von Scrum und von agilen Arbeitsme‐ thoden im Allgemeinen: Kommunikation. Agile Arbeitsmethoden benötigen zwingend deutlich mehr Kommunikation und Abstimmung als Wasserfall-Methoden. Wenn es keine Hierarchien innerhalb des Teams gibt, bedeutet das zusätzlich, dass das Team sich selbst organisieren muss. Selbstorganisierende Teams sind derzeit äußerst beliebt und finden als Schlagwort Eingang in viele Reden, Präsentationen und Veröffentlichungen (wie auch in diese). Aber was bedeutet Selbstorganisation überhaupt für ein Scrum Team? Wo liegen die Schwierigkeiten? Wie sieht das in der Praxis aus? Und kann das überhaupt funktionieren oder ist es eine Wunschvorstellung vom idealen, aber nie zu erreichenden Team Utopia? Die gute Nachricht ist, es kann funktionieren. Die Schlechte ist, es gestaltet sich oft schwieriger als es oft erwartet wird. Selbstorganisation bedeutet, dass das Scrum Team die Art und Weise der Zusammen‐ arbeit innerhalb eines vorgegebenen Frameworks selbst definiert. Orchestriert wird das Ganze vom Scrum Master. In der Praxis kann dies eine Herausforderung für den Scrum Master sein. Dafür gibt es zwei Gründe: Erstens befürchten viele Manager einen gewissen Kontrollverlust, wenn sie dem Scrum Team nicht die Art und Weise der Zusammenarbeit vorgeben können. Zweitens fällt es manchen Mitarbeitern schwer, mit der neugewonnenen Freiheit umzugehen. Dies ist umso verständlicher, wenn man berücksichtigt, dass viele Unternehmen die letzten Jahre oder Jahrzehnte in einer Wasserfallwelt zuhause waren, in der sich eine Kultur der Compliance entwickelt hat. In einem solchen Umfeld wurde den Mitarbeitenden wenig Freiheit gegeben, um eigene Ideen voranzutreiben und auszuprobieren. Wird nun Selbstorganisation über Nacht per Dekret eingeführt, weil das Wort häufig in Verbindung mit agilen Arbeitsweisen fällt, kann dies schnell zu einer Überforderung der Mitarbeitenden führen, die noch kein Vertrauen in die neue Herangehensweise entwickeln konnten. Die Ursache beider Punkte liegt im agilen Mindset, das sich erst noch im gesamten Unternehmen ausbilden muss. Dieser Vorgang benötigt Zeit und sollte durch einen umfassenden Veränderungsprozess begleitet werden. Scrum Teams sind crossfunktional, was bedeutet, dass innerhalb des Teams alle Fähigkeiten vorhanden sind, die für die Erreichung des Produktziels notwendig sind. Nehmen wir als Beispiel eine Webapplikation, die unter Verwendung von Wetter- und Verkehrsdaten die Besuchszahlen für einen Zoo vorhersagen will. Ein solches 20 4 Scrum Rollen - Die Idealbesetzung eines Scrum Teams Scrum Team könnte aus einem Product Owner, einem Scrum Master und Entwicklern bestehen, die folgende Fähigkeiten bereithalten: UX/ UI-Design, Frontend- und Backen‐ dentwickler, Testentwickler, Datenbankentwickler, Data Scientist. Das obige Team würde aus circa sieben Mitgliedern bestehen (abhängig davon, ob bestimmt Fähigkeiten in einer Person vereint sind oder, ob bestimmte Kompetenzen mehrfach vorhanden sein müssen). Die Frage nach der Größe eines Scrum Teams wird vor dem Beginn des Projektes beantwortet. Folgende Faustregel kann dabei verwendet werden: Das Scrum Team sollte klein genug sein, um flexibel agieren zu können und den Kommunikationsaufwand nicht zu groß werden zu lassen. Gleichzeitig sollte es groß genug sein, um einen signifikanten Fortschritt zu erzielen. Typischerweise liegt die Zahl zwischen sieben und neun Teammitglieder. Kleine Teams sind meist produk‐ tiver und kommunizieren effizienter. Jeff Bezos hat bei Amazon die Zwei-Pizzen-Regel eingeführt, um die ideale Teamgröße für ein produktives Arbeiten zu bestimmen (siehe Abbildung 5). Figure 5: Performance-Teamgröße L e i s t u n g u n d Z u s a m m e n a r b e i t Anzahl der Personen im Team Positive Synergien Negative Synergien 5-9 Personen Abbildung 5: Performance - Teamgröße Sie besagt, dass an einem Meeting nur so viele Mitarbeiter teilnehmen dürfen, wie von zwei Pizzen satt werden. (Achtung, gemeint sind amerikanische Pizzen, die im Gegensatz zu europäischen Pizzen einen Durchmesser von 40 cm anstatt von 26 cm haben. Von einer amerikanischen Pizza werden vier Personen satt.) Die Anzahl an Teilnehmern ist demnach auf acht beschränkt. So willkürlich diese Zahl erscheinen mag, sie ist wissenschaftlich fundiert und wird auch von Bob Sutton in seinem Buch Scaling Up Excellence: Getting to More without Settling for Less bestätigt. Wird ein Team zu groß, sollte das Team in kleinere Einheiten zerteilt werden. Ab jetzt betreten wir den Bereich der Skalierung von agil, der wir uns später in einem separaten Kapitel 21 4.1 Passende Rollenbesetzung als Erfolgsschlüssel widmen. So viel sei bereits an dieser Stelle gesagt: Wird das Thema Skalierung nicht umfänglich durchdacht, was in der Praxis häufiger vorkommt, kann dies mittel- und langfristig sowohl zu funktionalen als auch technischen Problemen führen, die nur mit einem enormen Zeit- und Kostenaufwand wieder beseitigt werden können. Scrum Teams kümmern sich um alles Produktbezogene. Das umfasst unter anderem das Stakeholder Management, das Erfassen und die Verifikation von Anforderungen (in Form von Epics und User Stories), die Entwicklung eines wert- und sinnvollen Produktinkrements am Ende eines Sprints, den operativen Betrieb und was sonst noch alles anfallen könnte. In einem solchen Szenario kann es zu Situationen kommen, in denen die Teammitglieder eigenverantwortlich Entscheidungen im Sinne des Produk‐ tes treffen müssen. Um die Produktivität des Teams durch aufwendige Rücksprachen dazu nicht zu behindern, ist ein gewisser Spielraum förderlich, indem selbst Entschei‐ dungen getroffen werden dürfen. Hierbei spricht man von Empowerment. Es ist ein wesentlicher Erfolgsfaktor von agilen Teams, wenngleich sich dieser Aspekt auf Grund der bereits oben genannten Herausforderungen als schwierig in der Praxis erweisen kann. 4.2 Entwickler als T-Shaped Professionals Die Hauptaufgabe der Entwickler ist es, ein nutzbares Produktinkrement am Ende eines Sprints erzeugt zu haben. Wir werden in Kapitel 5.5 und 5.6 noch einmal intensiv auf diesen Punkt eingehen, da er ein essenzieller Bestandteil von Scrum ist und in der Praxis manches Mal falsch umgesetzt wird. Die Betonung liegt insbesondere auf nutzbares Produktinkrement, also etwas, was Fachabteilungen im operativen Geschäft verwenden können und das einen Nutzen, einen Mehrwert, bringt. Die lediglich drei vorhandenen Rollen in Scrum erwecken den Eindruck, dass Vor‐ gehensmodell sei einfach umzusetzen und strukturiert. In der praktischen Anwendung führt ebendiese Einfachheit jedoch gelegentlich zu Verwirrungen. Das Verständnis für das Konzept crossfunktionaler Teams ist deshalb umso wichtiger. Crossfunktio‐ nal bedeutet, dass in einem Entwicklerteam alle notwendigen Kenntnisse, um ein Produktinkrement zu erzeugen, vorhanden sind. Zerlegen wir als Beispiel einen Softwareentwicklungsprozess in drei Schritte: Analyse, Programmierung, Testen. Ein Scrum Team würde mindestens diese drei Fähigkeiten abbilden müssen. Im Idealfall wird jeder Schritt von einem Experten begleitet, der über zusätzliches Know-how in den anderen Bereichen verfügt. Solche Teammitglieder bezeichnet man als T-Shaped Professionals (siehe Abbildung 6). Der große Vorteil besteht darin, dass T-Shaped Professionals Tiefenwissen (Expertenwissen) in einem Bereich besitzen und zeitgleich über ein Breitenwissen aus anderen Bereichen verfügt. Solche Mitarbeiter haben in der Regel einen scharfen Blick für das große Ganze und greifen die Gesamtzusammenhänge schnell; eine Fähigkeit, die besonders in dynamischen und agilen Arbeitsumgebungen von Vorteil ist. 22 4 Scrum Rollen - Die Idealbesetzung eines Scrum Teams Breites, fächerübergreifendes Allgemeinwissen T i e f e s , f a c h s p e z i f i s c h e s E x p e r t e n w i s s e n T-Shaped Professional Testen A n a l y s e Business Analyst Programmieren Analyse P r o g r a m m i e r e n Programmierer Testen Analyse T e s t e n Tester Programmieren Abbildung 6: T-Shaped Professionals Um die oben beschriebene Hauptaufgabe, ein nutzbares Produktinkrement am Ende eines Sprints zu erzeugen, erreichen zu können, sind folgende Tätigkeiten ebenfalls in der Verantwortung des Entwicklerteams: Das Team erzeugt einen Plan für den Sprint, das sogenannte Sprint Backlog. Hierin werden alle Aufgaben, die innerhalb des Sprints erledigt werden sollen, transparent aufgelistet. Um jedoch eine zielgerichtete Erledi‐ gung der Aufgaben zu gewährleisten, ist es notwendig, Abhängigkeiten bereits im Vorfeld zu identifizieren und die Planung entsprechend anzupassen. Wird dieser Punkt nicht beachtet, könnten einzelne Aufgaben die Tätigkeiten anderer Teammitglieder blockieren und somit die Erreichung des Sprintziels gefährden. Das Entwicklerteam ist maßgeblich für die Qualität des Produktes zuständig. Hierbei ist vor allem die Definition of Done wichtig, die konkret definiert, wann eine bestimmte Aufgabe oder User Story fertiggestellt ist. Qualität sollte dabei bereits als integraler Bestandteil des Entwicklungsprozesses gesehen werden, um sie von vornherein in das Produkt zu integrieren und nicht erst anschließend in aufwendigen Testphasen zu ergänzen. Dieser Umgang mit Qualität ist eine Umsetzung des Andon Cords, dass bei Toyota Verwendung findet und zu einer enormen Steigerung der Qualität geführt hat. Das Andon Cords ist eine Leine, die jeder Mitarbeiter entlang der Produktionsstrecke ziehen kann - und damit die gesamte Produktion stoppt -, sobald ihnen Qualitätsmängel auffallen. Als Folge werden Probleme und Qualitätsmängel frühzeitig im Prozess 23 4.2 Entwickler als T-Shaped Professionals erkannt und können kostengünstiger korrigiert werden, als wenn man diese nach der Produktion feststellt. Die tägliche Anpassung des Plans gehört deshalb zu den Aufgaben eines Entwicklerteams. Die Korrekturen finden im Rahmen der Daily Stand-ups statt. Sie dienen dazu, den Weg zum Sprintziel zu optimieren und somit das Ziel schneller, effizienter oder günstiger zu erreichen. Veränderungen, die keinen Einfluss auf die Erreichung des Sprintziels haben sind obsolet. Darüber hinaus trägt jedes Teammitglied die Verantwortung, sich selbst und die anderen immer wieder aufs Neue in die Pflicht zu nehmen, die vereinbarten Ergebnisse im Rahmen eines Sprints zu erreichen. 4.3 Scrum Master als Servant Leader Die Rolle des Scrum Masters ist entscheidend bei der Implementierung von Scrum in Unternehmen. Der Scrum Master übernimmt gleich mehrere Schlüsselaktivitäten, die maßgeblichen Einfluss auf eine erfolgreiche Einführung haben. Zusammengefasst kann die Rolle so definiert werden, dass der Scrum Master der Dienstleister im Scrum Team ist, denn seine Hauptaufgaben als Servant Leader, die wir uns im Nachgang näher anschauen werden, weisen einen gewissen Dienstleistungscharakter auf. Der Scrum Master ist dafür zuständig, Scrum als Produktentwicklungsmethode in einem Unternehmen einzuführen und zu etablieren. Diese Aufgabe beinhaltet zu einem großen Teil Training- und Coachingaktivitäten, um das Team und die Organisation zuerst mit den üblichen Begrifflichkeiten und ihren jeweiligen Bedeutungen bekannt zu machen. Ein wesentlicher Aspekt für die erfolgreiche Einführung von Scrum ist, dass die Aufgabe des Scrum Masters die Teamgrenzen überschreitet. Erst wenn auch das Stakeholder-Umfeld mit Scrum verstanden hat, wie Scrum funktioniert und welche Anforderung auf die umstehenden Parteien außerhalb des Teams zukommen, hat Scrum eine Chance, erfolgreich zu sein. Es ist dabei in der Praxis nicht so wichtig - der eine oder die andere mag hier widersprechen -, dass Scrum eins-zu-eins wie im Scrum Guide beschrieben umgesetzt wird. Vielmehr ist es ausschlaggebend, dass der Scrum Master das Unternehmen mit agiler Denkweise, dem oft zitierten Agile Mindset, vertraut macht und dass eine Variante von Scrum gefunden wird, die zum Unternehmen passt und bestmögliche Erfolgsaussichten hat. Weiterhin hat der Scrum Master die Aufgabe, sich um die Effektivität des Scrum Teams zu kümmern und es dabei zu unterstützen, sich stetig zu verbessern. Dies kann auf vielfältige Weise geschehen. Dazu gehören gut struk‐ turierte Retrospektiven ebenso wie offene und ehrliche Gespräche mit dem Team und mit einzelnen Mitgliedern. Die in Managementliteratur immer prominenter werdende Transparenz kann sich genauso durch Teamzusammenkünfte mit allen Personen wie auch im Einzelgespräch mit den Mitgliedern herauskristallisieren. Die vertrauensvollere Atmosphäre unter vier Augen lässt die ein oder andere Schwierigkeit in den Aufgaben oder im Team manchmal eher ans Licht kommen. Das verdeutlicht, dass ein guter Scrum Master Fingerspitzengefühl für unangenehme Situationen oder schwelende Konflikte benötigt, um diese zeitnah zu beseitigen, bevor daraus größere Probleme erwachsen. 24 4 Scrum Rollen - Die Idealbesetzung eines Scrum Teams Nachfolgend wollen wir den Dienstleistungscharakter der Scrum Master Rolle deutlicher herausarbeiten, indem wir uns anschauen, welche Aufgaben der Scrum Master in Bezug auf die anderen Scrum Rollen und die Organisation übernimmt. Fangen wir mit der Organisation an. Wie eingangs kurz angedeutet, besteht die Hauptaufgabe darin, die Organisation mit Scrum vertraut zu machen. Das geschieht durch Trainings und Coachings. Der Scrum Master hat dabei natürlich auch eine beratende Funktion, in die er Erfahrungen aus anderen agilen Projekten mit einbringen sollte (sofern bereits vorhanden). Als größte Hürde hat sich dabei das Agile Mindset gezeigt. Es zeigt sich in der Praxis immer wieder, dass es für Unternehmen eine Hürde ist, von einer über Jahrzehnte gelernten Denkweise, die hauptsächlich auf traditionellen Projekt- und Produktdurchführungsmethoden (Zeit, Geld, Umfang) basiert, loszulassen. Der Schritt weg von einer - sind wir ehrlich - gefühlten Sicherheit der Projekt- und Budgetpläne sowie der Lasten- und Pflichtenhefte hin zu einem empirischen Ansatz, der bewusst Experimentieren zulässt und damit Fehlschläge akzeptiert, ist oftmals deutlich schwieriger als man vermutet und ein Hauptgrund dafür, dass Agilität in Organisationen scheitert. Zu guter Letzt ist der Scrum Master dafür zuständig, sich um sämtliche Hindernisse, welche Gestalt auch immer diese annehmen mögen, zwischen dem Scrum Team und anderen Beteiligten innerhalb der Organisation zu kümmern und sie bestmöglich zu beseitigen. Kommen wir zur Bedeutung des Scrum Masters für den Product Owner. Der Scrum Master unterstützt ihn bei der Definition und dem Management des Produktzieles und des Produkt Backlogs. Er übernimmt keine inhaltlichen Aufgaben, sondern bietet vielmehr Unterstützung und Techniken an, wie die zwei zuvor genannten Aufgaben erfolgreich umgesetzt werden können. Zudem fördert und erweitert der Scrum Master das tiefergehende Verständnis des Product Owners, die Relevanz klarer und prägnanter User Stories zu begreifen und diese entsprechend umzusetzen (ein Punkt, der auch vom gesamten Team verstanden und mitgetragen werden muss - eine weitere Aufgabe des Scrum Masters). Zwar ist der Scrum Master selbst nicht der Product Owner (und hat unter Umständen keine eigene Produktentwicklungserfahrung, wenngleich das sehr hilfreich ist), dennoch gehört es zu seinen Aufgaben, dem Product Owner dabei zu helfen, geeignete Methoden hinsichtlich der Planung und Priorisierung der User Stories anzuwenden. In Lehrbüchern werden an dieser Stelle of Cost of Delay und Weighted Shortest Job First genannt. [Fußzeile: Cost of Delay bezeichnet dabei die Kosten, die auf ein Unternehmen zukämen, wenn eine bestimmte User Story erst zu einem späteren Zeitpunkt umgesetzt wird. Weighted Shortest Job First stellt den Nutzen einer User Story in Relation zum entsprechenden Aufwand und erlaubt damit, zumindest aus rein betriebswirtschaftlicher Sicht, eine optimale Priorisierung von User Stories.] Jedoch zeigt sich in der Praxis, dass Organisationen in Bezug auf Priorisierung von User Stories sehr kreativ sein können. Die Anwendung einer bestimmten Lehrbuchmethode ist dabei gar nicht entscheidend. Von höher Bedeutung ist, dass der Scrum Master die Dringlichkeit der Priorisierung herausstellt. Argumente à la „wir müssen das unbedingt im nächsten Sprint machen, weil wir es brauchen“ sollten nicht akzeptiert werden. 25 4.3 Scrum Master als Servant Leader Ebenso fungiert der Scrum Master als Vermittler und unterstützt, soweit erwünscht oder notwendig, den Product Owner bei der Zusammenarbeit mit anderen Beteiligten aus der Organisation. Im Team äußert sich der Dienstleistungscharakter des Scrum Masters in der Form, als dass dieser alle Teammitglieder kontinuierlich darin coacht, ihre Zeit und Arbeit selbst zu managen. Er begleitet sie auf dem Weg in ein crossfunktionales Umfeld, was für einige zu Beginn noch ein ungewohntes Terrain darstellt. Einer der Gründe, weshalb Agilität nicht erfolgreich in eine Organisation implementiert wird, kann sein, dass dieser Punkt schlichtweg unterschätzt wurde. Teammitglieder benötigen Zeit und lernen erst, mit der neuen Freiheit in einem agilen Umfeld umzugehen. Wenn Personen mehrere Jahre in einem Umfeld gearbeitet haben, in dem sie von außen gemanagt wurden und Selbstorganisation unerwünscht war, ist die Wahrscheinlichkeit hoch, dass eine agile Umgebung erst einmal überfordernd ist. Der Scrum Master bezieht an diesem Punkt eine Leuchtturmposition. Durch Vorbild und Expertise verhindert er, dass eine Lähmung entsteht, in der Personen lieber nichts tun als Fehler zu begehen. Darüber hinaus unterstützt der Scrum Master das Team hinsichtlich der gemeinsam vereinbarten Definition of Done dabei, die Sprintziele zu erreichen. Er hilft dem Team dabei, sämtliche Hindernisse zu beseitigen, die zur Erreichung der Sprintzieles im Weg stehen. In der Praxis beinhaltet das die die Identifizierung von Abhängigkeiten und das entsprechende Management derselben. Folgende Situation wird anfangs immer mal wieder passieren und kann schnell in den Griff bekommen werden: Ein Sprint wird geplant, ohne die entsprechenden Abhängigkeiten der einzelnen User Stories zueinander zu berücksichtigen. Nicht selten führt das zu Situationen während eines Sprints, in denen einzelne Teammitglieder nicht weiterarbeiten können, da sie auf die Ergebnisse anderer Teammitglieder angewiesen sind (sogenannte Blocker). Der Scrum Master wird auch als Prozesswächter von Scrum bezeichnet. Damit ist gemeint, dass der Scrum Master dafür zu sorgen hat, dass alle Scrum Events stattfinden und innerhalb des vorgeschriebenen zeitlichen Rahmens bleiben. Das gesamte Rahmenwerk Scrum kann und sollte individuell auf das Unternehmen, das Produkt und die Teammitglieder angepasst werden. Die Regeln nach Textbuch sind nicht dogmatisch zu verstehen. Es gab bereits erfolgreiche Scrum Teams, die bestimmte Events wie die Retrospektiven gestrichen haben. Genauso konnte so manches Scrum Team, das sich präzise an die Regeln gehalten hat, die gewünschten Ergebnisse nicht erreichen. Diese Freiheit ist ein wesentlicher Bestandteil von selbstorganisierenden Teams. 4.4 Product Owner als Wertmaximierer Die Rolle des Product Owners ist - im Vergleich zu den beiden anderen Rollen - inner‐ halb eines Scrum Teams diejenige, die durchaus unterschätzt wird. Außerdem stehen Fachbereiche vor personellen Herausforderungen, wenn sie einen ihrer Fachexperten 26 4 Scrum Rollen - Die Idealbesetzung eines Scrum Teams 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, wertgenerier‐ enden 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. 27 4.4 Product Owner als Wertmaximierer 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 zu‐ sä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 inner‐ halb 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 Hotelzim‐ mer 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 Vorberei‐ tungszü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 unter‐ schiedlichen Bereichen zusammen, um gemeinsam an einem Projekt zu arbeiten, durchläuft die Gruppe zwangsläufig gewisse Schritte, bevor sie zu einem Höchstleis‐ tungsteam 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 Modell, 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 Entwicklungs‐ dauer 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 28 4 Scrum Rollen - Die Idealbesetzung eines Scrum Teams 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. P e r f o r m a n c e Phase Forming Storming Norming Performing Adjourning • Fragen • Sozialisierung • Eifrig sein • Fokus auf Gruppenidentität • An sicheren Themen festhalten • Widerstand • Fehlende Teilnahme • Konflikt • Wettbewerb • Emotionen • Ausbildung Gruppennormen • Versöhnung • Erleichterung, weniger Angst • Teammitglieder unterstützen sich • Entwicklung von Zusammenhalt • Demonstration von Unabhängigkeit • Gesundes System • Fähigkeit, als Team Ergebnisse zu erzielen • Gleichgewicht von Aufgaben- und Prozessorientierung • Verschiebung hin zu Prozessorientierung • Traurigkeit • Anerkennung Bemühungen einzelner / des Teams C h a r a k t e r i s t i k S t r a t e g i e n • "In die Führung" gehen • Klare Erwartungen und konsistente Anweisungen • Kurze Antwortzeiten • Normalisierung • Mutmachende Führung • Anerkennung Bemühungen einzelner / des Teams • Lernen und Feedback ermöglichen • "Energie" des Teams beobachten • Erfolge feiern • Minimale Interventionen • Gruppenentscheidung en und -lösungen ermutigen • Möglichkeiten bieten, Gelerntes im Team zu teilen • Veränderung wahrnehmen • Abschließende Teambewertungen ermöglichen • Anerkennung von Leistung ermöglichen Figure 7: Team-Building-Phasen nach Tuckman Abbildung 7: Team-Building-Phasen nach Tuckman 29 4.5 Führung und Teambildung in agilen Teams 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 ange‐ sprochen, 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 30 4 Scrum Rollen - Die Idealbesetzung eines Scrum Teams 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 31 4.5 Führung und Teambildung in agilen Teams 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ängigkei‐ ten 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 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. 32 4 Scrum Rollen - Die Idealbesetzung eines Scrum Teams Vertrauen Konfliktbereitschaft Selbstverpflichtung Gegenseitige Verantwortlichkeit Zielorientierung Dominanz von Status & Ego Niedrige Standards Zweideutigkeit Künstliche Harmonie Fehlende Offenheit Figure 8: Fünf Dysfunktionen von Teams 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 beken‐ nen. Es beinhaltet auch, Verantwortung für das Team und das gemeinsame Ziel zu übernehmen. In Hochleistungsteams halten sich Teammitglieder keine Hintertüren 33 4.5 Führung und Teambildung in agilen Teams 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 Vorder‐ grund. 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. 34 4 Scrum Rollen - Die Idealbesetzung eines Scrum Teams 5 Scrum Artefakte - Die Übersicht behalten Die Scrum 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). Artefakt Vereinbarung Product Backlog Produktziel (Product Goal) Sprint Backlog Sprintziel (Sprit Goal) Produktinkrement Definition of Done Figure 9: Zuordnung von Vereinbarungen zu Artefakten 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än‐ dig zu beschreiben. Übergeordnet war die Mission, 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 Produktbeziehungsweise Projektvision ein in der Zukunft liegendes, relativ konkretes Bild dessen, was mit dem jeweiligen Produkt oder Projekt angestrebt wird. Hiermit sollen die Unterneh‐ mensmission und die Unternehmensvision realisiert werden. Abbildung 10 verdeutlich den Zusammenhang zwischen der übergeordneten Unternehmensmission und der Produktvision. • Übergeordnete, verpflichtende Aufgabe auf die durchgehend und dauerhaft hingewirkt wird • Nicht auf ein Produkt ausgerichtet, sondern mehr die treibende Kraft für Produkt-Teams • Geht über Produkt und Produktlaufzeiten hinaus  sehr seltene Änderung • Übergeordnete, verpflichtende Aufgabe auf die durchgehend und dauerhaft hingewirkt wird • Nicht auf ein Produkt ausgerichtet, sondern mehr die treibende Kraft für Produkt-Teams • Geht über Produkt und Produktlaufzeiten hinaus  sehr seltene Änderung Mission 1 • In der Zukunft liegendes, motivierendes, inspirierendes und konkretes Bild des Produktes • Gemeinsam angestrebtes und realistisches Ziel, das die Richtung weist und auf der Mission aufbaut • Langfristig ausgelegt (ca. 3-5 Jahre)  seltene, aber periodische Änderungen • In der Zukunft liegendes, motivierendes, inspirierendes und konkretes Bild des Produktes • Gemeinsam angestrebtes und realistisches Ziel, das die Richtung weist und auf der Mission aufbaut • Langfristig ausgelegt (ca. 3-5 Jahre)  seltene, aber periodische Änderungen Produktvision 2 Figure 10: Mission und Produkt-Vision Abbildung 10: Mission und Produktvision 36 5 Scrum Artefakte - Die Übersicht behalten 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 end‐ lich 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 zusammen‐ hängen. Eine tiefergehende Begriffsdiskussion erfolgt nicht. 5.1.1 Von der Produktidee zur Produktvision Am Anfang steht die Produktidee, die mithilfe der Produktvision beschrieben wird. Diese Produktvision soll die Projektstakeholder positiv auf die anstehenden Verände‐ rungen, 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 beispiels‐ weise 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 und einer Roadmap. Genau darin liegt auch das Problem bei vielen Produktvisionen. Es werden verschiedene Themenstellungen gleichzeitig adressiert. Eine Produktvision soll inspirieren und dabei langfristig auf circa drei bis fünf Jahre ausgelegt sein. Ziel ist, ein klares, positives Bild des Produktes in den Köpfen der Empfänger zu zeichnen, wobei die jeweiligen Vorstellungen nicht übereinstimmen müssen. Die Teammitglieder erhalten ein realistisches Ziel, das aber nicht zwingend erreicht werden muss. Die Produktvision beschreibt keine konkrete Vorgehensweise 37 5.1 Von der Vision zum Product Backlog und auch keinen spezifischen Funktionsumfang. Der Erfüllungsgrad der Vision ist nicht durch Kennzahlen messbar. Es ist außerdem denkbar, dass sich die Vision im Laufe der Zeit verändert, auch wenn dies eine Ausnahme bleiben sollte. So ungewöhn‐ lich oder ambitioniert einige Visionen wirken, so einprägsam sind sie in der Regel auch. In der IT-Branche wird gerne die Vision, die Googles Suchmaschine zugrunde liegt, als Paradebeispiel angeführt: „to provide access to the worlds information in one click“. Diese Vision wird von folgender übergeordneten Mission abgeleitet: „to organize the worlds information and make it universally accessible and useful“. Ein weiteres Positivbeispiel ist Audis Unternehmensvision „Mobilität mit null Emissionen“. Stellen Sie sich vor, das Unternehmen hätte stattdessen die Vision „Sicherstellung der Mobilität trotz vollständiger Vermeidung von Emissionen durch die Umstellung der Fahrzeugflotte auf Elektroantrieb“ gewählt. Eine solche Vision wäre nicht einprägsam und es ist schwierig, sich damit zu identifizieren. In beiden Fällen handelt es sich um Unternehmensvisionen; Produktvision sollten genauso formuliert werden. Bei der Formulierung der Produktvision können Sie die SHIELD-Kriterien als Hilfestellung verwenden. Dieses Akronym enthält die Anfangsbuchstaben der engli‐ schen Begriffe simple, huge, important, engaging, long-term und distributed. Die Produktvision sollte also einfach zu verstehen sein (simple), ein großes Ziel beschreiben (huge), ein bedeutendes Bedürfnis adressieren (important), alle Beteiligten einnehmen (engaging), langfristig ausgerichtet sein (long-term) und allen im Unternehmen be‐ kannt sein (distributed). Nun stellt sich die Frage, wer für die Formulierung der Produktvision verantwortlich ist. Es ist keine gute Idee, diese Aufgabe dem Product Owner zu übertragen. Stattdessen sollte eine Stakeholder-Analyse gemacht werden, um geeignete Personen mit den benötigten Kompetenzen zu identifizieren. 5.1.2 Von der Produktvision zur Produktstrategie Nachdem die Produktvision festgelegt wurde, geht es an die Produktstrategie (siehe Abbildung 11). Die Entwicklung der Produktstrategie ist keine strategische Planung im klassischen Sinne. Die relevanten Produktmerkmale kristallisieren sich oft erst während der iterativen Produktentwicklung heraus. Man sollte den Strategieprozess daher damit starten, dass ausgewählte Stakeholder die Zielgruppe des Produkts festlegen. Denn nur die zukünftigen Kunden und Verwender des Produkts können letztlich beschreiben, welchen Nutzen das Produkt für sie hat. Es kann sein, dass hierbei eine Unterschei‐ dung zwischen Kunden und Anwendern erforderlich ist, denn ein Kunde ist nicht notwendigerweise auch der Anwender eines Produkts. Die beiden Gruppen können unterschiedliche Zielvorstellungen haben, die bei der Formulierung der Produktstra‐ tegie zu berücksichtigen sind. 38 5 Scrum Artefakte - Die Übersicht behalten • Übergeordnete, verpflichtende Aufgabe auf die durchgehend und dauerhaft hingewirkt wird • Nicht auf ein Produkt ausgerichtet, sondern mehr die treibende Kraft für Produkt-Teams • Geht über Produkt und Produktlaufzeiten hinaus  sehr seltene Änderung • Übergeordnete, verpflichtende Aufgabe auf die durchgehend und dauerhaft hingewirkt wird • Nicht auf ein Produkt ausgerichtet, sondern mehr die treibende Kraft für Produkt-Teams • Geht über Produkt und Produktlaufzeiten hinaus  sehr seltene Änderung Mission 1 • In der Zukunft liegendes, motivierendes, inspirierendes und konkretes Bild des Produktes • Gemeinsam angestrebtes und realistisches Ziel, das die Richtung weist und auf der Mission aufbaut • Langfristig ausgelegt (ca. 3-5 Jahre)  seltene, aber periodische Änderung • In der Zukunft liegendes, motivierendes, inspirierendes und konkretes Bild des Produktes • Gemeinsam angestrebtes und realistisches Ziel, das die Richtung weist und auf der Mission aufbaut • Langfristig ausgelegt (ca. 3-5 Jahre)  seltene, aber periodische Änderung Produktvision 2 • Zeigt im Sinne eines langfristigen Plans an wie die Produkt-Vision erreicht werden soll • Enthält zur Erklärung die Notwendigkeit und die verfolgte Ziele (insbesondere hinsichtlich Wert) • Ausgelegt auf Produktlaufzeit  periodische Änderungen - abhängig von Zielen alle 2-6 Monate • Zeigt im Sinne eines langfristigen Plans an wie die Produkt-Vision erreicht werden soll • Enthält zur Erklärung die Notwendigkeit und die verfolgte Ziele (insbesondere hinsichtlich Wert) • Ausgelegt auf Produktlaufzeit  periodische Änderungen - abhängig von Zielen alle 2-6 Monate Produktstrategie 3 Figure 11: Produktstrategie Abbildung 11: Produktstrategie 39 5.1 Von der Vision zum Product Backlog Wer identifiziert also die Zielgruppe? Welche Stakeholder gehören dazu? In jedem Fall ist der Product Owner einer davon. Neben diesem Hauptakteur gehören auch Vertreter aus dem Marketing, dem Verkauf und dem Service in diese Gruppe. Bei strategisch bedeutsamen Produkten sollte sich auch die Unternehmensleitung an diesem Auswahlprozess beteiligen. Ist die Zielgruppe identifiziert, wird im nächsten Schritt der Produktnutzen aus deren Sicht herausgearbeitet. Dieser wird so lange beschreiben, bis der Mehrwert deutlich heraussticht. Dieser kann sein, dass eine bisher vorhandene Anwenderheraus‐ forderung behoben wird oder das Produkt einen zusätzlichen Nutzen für den Kunden schafft. Wenn zum Beispiel die Abarbeitung eines Backoffice-Prozesses zu lange dauert, weil das verwendete IT-System zu langsam ist, würde die Nutzenbeschreibung folgendermaßen lauten: „Performantes IT-System, um Bearbeitungs- und Wartezeiten zu verkürzen“. Das formulierte Ziel sollte erreichbar und flexibel sein. In unserem Beispiel ist das der Fall. Bereits mit der Einführung eines neuen IT-Systems, bei dem die Prozessdauer um eine Sekunde verkürzt würde, wäre das formulierte Ziel erreicht, da jede noch so minimale Verkürzung der Prozessdauer das Ziel erfüllen würde. Die Nutzenbeschreibung ist genauso flexibel, da nicht festgelegt ist, um wie viele Sekunden oder Minuten die Bearbeitungs- und die Wartezeit verkürzt werden soll. Gänzlich auf Zielvorgaben zu verzichten, ist nicht sinnvoll, schließlich erhofft sich die Zielgruppe durch die Anwendung des Produkts einen signifikanten Mehrwert. Um nachhalten zu können, ob dieses Ergebnis erreicht wurde, sollten die Ziele messbar gestaltet werden. Für jedes Ziel finden dann eine oder mehrere Kennzahlen Anwendung. Die Zielvorgaben sollte man nicht mit absoluten Größen, sondern in Form von Anteilsgrößen definieren. Eine Zielformulierung in Form von absoluten Werten erfolgt, wenn die Product Roadmap mit Inhalt gefüllt wird. Wenn möglich, sollte immer ein Zielkorridor und kein Einzelwert benannt werden. In unserem Beispiel würde man vielleicht im ersten Schritt eine Reduzierung der Bearbeitungs- und Wartezeiten um 5 bis 10 % und im zweiten Schritt um 10 bis 20 % anstreben. Sobald die Ziele aus der Perspektive der Zielgruppen definiert sind, bleibt die Frage, welche Vorteile sich für das Unternehmen ergeben (siehe Abbildung 12). Daher sind im nächsten Schritt die Business-Ziele festzulegen. Typische Erwartungen an das neue Produkt sind beispielsweise ein höherer Umsatz, mehr Gewinn, Kostenreduktion und die Erschließung neuer Geschäftsfelder. Diese Ziele sind wertvoll und - wie alle Ziele - sollten sie messbar sein, um später prüfen zu können, ob sie erreicht wurden. Ein Zielformulierung könnte lauten: „Umsatzsteigerung durch Klicks auf Werbelinks“. Dies wird messbar durch die Anzahl der Klicks. Wie jedoch mehr Klicks erreicht werden können, dazu gibt das Ziel keine Auskunft. Das ist im ersten Schritt auch gut so. Die Methoden können später festgelegt werden, was Raum für kreative Lösungen gibt. 40 5 Scrum Artefakte - Die Übersicht behalten Mission 1 Produktvision 2 Produktstrategie 3 • Produktausrichtung auf Marktsegmente u.a. Kunden und Nutzer • An welche Zielgruppe(n) wendet sich das Produkt? • Produktausrichtung auf Marktsegmente u.a. Kunden und Nutzer • An welche Zielgruppe(n) wendet sich das Produkt? Marktsegmente und Zielgruppen A • Positiver Nutzen des Produktes aufgrund der Probleme der jeweiligen Zielgruppe (Beschreibung, warum es benötigt wird.) • Positiver Nutzen des Produktes aufgrund der Probleme der jeweiligen Zielgruppe (Beschreibung, warum es benötigt wird.) Marktanforderungen B • Beschreibung der Erwartungen an das Produkt aus Business Sicht (Umsatz-/ Gewinnsteigerung, Kostenreduktion, neue Geschäftsfelder etc.) • Beschreibung der Erwartungen an das Produkt aus Business Sicht (Umsatz-/ Gewinnsteigerung, Kostenreduktion, neue Geschäftsfelder etc.) Geschäftserwartungen C • Beschreibung der Kernelemente, die das Produkt grob umreißen und die an den überliegenden Strategiepunkten ausrichtet sind • Beschreibung der Kernelemente, die das Produkt grob umreißen und die an den überliegenden Strategiepunkten ausrichtet sind Kernfunktionalität D Figure 12: Inhalte Produkt-Strategie Abbildung 12: Inhalte Produktstrategie 41 5.1 Von der Vision zum Product Backlog Im folgenden Schritt erreichen wir die ersten Ebenen der Backlog Elemente (Initiativen, Features oder Epics). Es geht um die grobe Unterteilung in Hauptfunktionen. Ziel ist es, das Produkt mithilfe wesentlicher Hauptfunktionen zu beschreiben. Diese Features können sich auf funktionale und nichtfunktionale Anforderungen beziehen. In der Re‐ gel genügen drei bis zehn Elemente. Bei den Hauptanforderungen sollte auch vermerkt werden, ob es sich um einen Industriestandard oder eine innovative Neuerung handelt. Wünschenswert für einen Produkterfolg sind vor allem die Hauptanforderungen, die ein Alleinstellungsmerkmal am Markt haben oder eine deutliche Verbesserung gegenüber dem Standard versprechen. Für die Klassifizierung können beispielsweise folgende Unterteilungen verwendet werden: ■ Innovation (Alleinstellungsmerkmal): Diese Anforderungen sollten unbedingt und frühzeitig umgesetzt werden. ■ Verbesserung gegenüber Industriestandard: Diese Anforderungen sollten umge‐ setzt werden ■ Standardbzw. Basisfunktion: Diese Anforderungen entsprechen dem Industrie‐ standard oder liegen darunter. Daher sollte geprüft werden, ob und in welchem Umfang sie wirklich benötigt werden. 5.1.3 Von der Produktstrategie zu den Produktzielen Nachdem nun die Ziele für die verschiedenen Ebenen ermittelt wurden, ist es an der Zeit, über die Erfolgsfaktoren nachzudenken. Beim klassischen Projektmanagement hat man immer die Zieldimensionen Zeit, Kosten und Leistung im Blick. Deren Abhängigkeiten voneinander aufmerksam zu berücksichtigen ist von Bedeutung, da diese drei Größen in direkter Verbindung zueinanderstehen (siehe Abbildung 13). Erfolg Kosten Zeit Leistung Figure 13: Magisches Dreieck Abbildung 13: Magisches Dreieck Als Erweiterung zum magischen Dreieck gibt es auch noch das Teufelsquadrat (siehe Abbildung 14). Bei diesem Quadrat wird die Leistungsdimension in die zwei Dimen‐ sionen Inhalt und Qualität aufgespalten. Werden alle Dimensionen des magischen Dreiecks oder des Teufelsquadrats (weitestgehend) erfüllt, spricht man von einem erfolgreichen Projekt. 42 5 Scrum Artefakte - Die Übersicht behalten Erfolg Kosten Zeit Qualität Inhalt Figure 14: Magisches Viereck Abbildung 14: Teufelsquadrat Sind diese Kriterien ein guter Maßstab, den Erfolg eines Projekts zu messen? Wer sagt denn, dass ein Projekt nicht bereits erfolgreich sein kann, wenn nur 60 % des Inhalts umgesetzt wurde und das innerhalb der Hälfte der Zeit. Das Projektbudget wurde zwar um 10 % überzogen, mit dem neuen Produkt erhöht sich jedoch der Umsatz gegenüber dem Vormonat um 20 % und das obwohl noch 40 % der Anforderungen fehlen. Natürlich sind Kosten, Leistung, Inhalt und Zeit weiterhin wichtige Erfolgsfaktoren. Gleichzeitig werden weitere Kriterien berücksichtigt. Was bedeutet es in unserem fiktiven Beispiel für den Projekterfolg, wenn sich aufgrund einer geringeren Produktqualität der Serviceaufwand um ein Fünftel erhöht? Welche Konsequenzen hat es, dass eine hohe Fehleranzahl dazu führt, dass die Kunden das Produkt nicht kaufen möchten? Was wäre, wenn man die Produktqualität im nächsten Release nur um 3 % verbessern würde, aber ein neues Feature, das ein Alleinstellungsmerkmal ist, implementieren würde und sich dadurch der Umsatz um 25 % steigern würde? Kosten, Zeit, Inhalt und Qualität bleiben weiterhin wesentliche Erfolgsfaktoren. Dennoch bedürfen sie einer Erweiterung um den Funktionsumfang, den Marktanteil (insbesondere, wenn es relevante Mitbewerber gibt) und den generierten Wert. Der Wert der Produktanforderungen, auch als Business Value bezeichnet, wird uns später intensiver beschäftigen. Abhängig davon, welche Erfolgsfaktoren man für ein Produkt zugrunde legt, ist die Projektvorgehensweise darauf abzustimmen. Soll zum Beispiel ein fester Liefertermin eingehalten werden, richten sich sämtliche Bestrebungen danach. Kosten, Inhalt, Qualität und Funktionsumfang würden kaum beachtet werden. Stattdessen würden wahrscheinlich viele kostenintensive Experten mit den notwen‐ digen Erfahrungen einkauft werden, das Produkt in kürzester Zeit mit minimalem Funktionsumfang so einfach wie möglich umsetzen. 43 5.1 Von der Vision zum Product Backlog Mission 1 Produktvision 2 Produktstrategie 3 Marktsegmente und Zielgruppen A Marktanforderungen B Geschäftserwartungen C Kernfunktionalität D • Festlegung von Zielen entlang der strategischen Ausrichtung • Mehrere Ziele helfen, sich zu orientieren und zu fokussieren • Messbarkeit von jedem Ziel sicherstellen (Metriken benennen) • Festlegung von Zielen entlang der strategischen Ausrichtung • Mehrere Ziele helfen, sich zu orientieren und zu fokussieren • Messbarkeit von jedem Ziel sicherstellen (Metriken benennen) Produktziele E • Festlegung von Erfolgsfaktoren (Kosten, Zeit, Qualität, Funktionsumfang, Marktanteil, Wert usw.) • Festlegung von Erfolgsfaktoren (Kosten, Zeit, Qualität, Funktionsumfang, Marktanteil, Wert usw.) Erfolgsfaktoren I • Auswahl der richtige Taktik anhand der Erfolgsfaktoren (z.B. mehr Ressourcen und weniger Funktionsumfang, wenn Zeit und Qualität die primären Erfolgsfaktoren sind) • Auswahl der richtige Taktik anhand der Erfolgsfaktoren (z.B. mehr Ressourcen und weniger Funktionsumfang, wenn Zeit und Qualität die primären Erfolgsfaktoren sind) Taktische Ausrichtung II Figure 15: Produktziele Abbildung 15: Produktziele 44 5 Scrum Artefakte - Die Übersicht behalten Für der Produktentwicklung sollte also nicht ein einziges Produktziel verwendet werden, sondern mehrere. Im Scrum Guide steht, dass das Produktziel das langfristige Ziel für das Scrum Team sei und, dass erst eine Zielvorgabe erfüllt sein sollte, bevor es an die nächste geht. Jedoch steht im Guide nicht, dass es für das Projektprodukt nicht ein Ziel gibt. Es wird auch nicht genauer festgelegt, was ein langfristiges Ziel ist. Dieses kann individuell festgelegt werden. Wenn die Sprintdauer beispielsweise eine Woche beträgt, können drei Monate durchaus lang sein. Es spricht daher nichts dagegen, mehrere Produktziele zu definieren. Wie viele Produktziele werden gebraucht? Mindestens so viele, wie benötigt werden, um die strategischen Ziele erreichen zu können. Das mag sich pauschal anhören, dahinter verbirgt sich jedoch ein hohes Maß an Agilität. Es bedeutet, dass keine feste Anzahl an Produktzielen für die strategischen Ziele erreicht werden muss. Es kann also sein, dass sich die Produktziele ändern, neue hinzukommen oder welche entfallen und daher Anpassungen an den strategischen Zielen notwendig werden. Dies erfordert möglicherweise auch Anpassungen an der Vision. Der Weg von der Vision bis zum Sprintziel wird nicht nur einmal durchlaufen, sondern immer wieder - ganz nach dem agilen Verständnis. Wie sollte nun ein einzelnes Produktziel gestaltet werden? Kurz und deutlich. Ein Ziel könnte zum Beispiel die „Verbesserung der Benutzererfahrung bei Verkaufsauswertun‐ gen“ sein. Da Ziele immer messbar sein müssen, könnten Sie hierfür beispielsweise die Metriken Kundenzufriedenheit oder Nutzungsdauer verwenden. Legen Sie zusätzliche relevante Erfolgsfaktoren fest. Achten Sie in den Zeitdimensionen darauf, dass Sie nicht zu weit in die Zukunft gehen. Dabei sollte der Zeithorizont zwischen sechs und maximal zwölf Monate liegen. Die Produktziele sind auch die Basis für eine gute Strukturierung des Backlogs. So er‐ reichen Sie, dass das Backlog immer am nächsten Ziel ausgerichtet wird. Das bedeutet, das Backlog enthält keine überflüssigen oder redundanten Product Backlog-Elemente. Das macht es für das Team einfacher, sich auf das nächste Ziel zu fokussieren, anstatt mit Themen konfrontiert zu werden, die erst viel später in der Produktentwicklung benötigt werden. Hinzu kommt, dass Sprintziele einfacher abgeleitet werden können. Diese sind auch immer am nächsten und nicht schon am übernächsten Produktziel ausrichtet. 5.1.4 Von den Produktzielen zu den Sprintzielen und zurück zur Vision Auf Basis der Produktziele kann eine Product Roadmap erstellt werden. Der Begriff Roadmap lässt einen Wasserfall-Ansatz vermuten. Sie ist jedoch eine Strukturierungs‐ hilfe für die Produktziele. Für einen überschaubaren Zeithorizont wird der Weg zum nächsten Produktziel aufgezeigt. 45 5.1 Von der Vision zum Product Backlog Mission 1 Produktvision 2 Produktstrategie 3 Marktsegmente und Zielgruppen A Marktanforderungen B Geschäftserwartungen C Kernfunktionalität D Produktziele E Erfolgsfaktoren I Taktische Ausrichtung II • Produktziele bzw. Unterziele zum nächsten Produktziel werden mit einem Zeithorizont von 6 bis 12 Monaten formuliert (kein Projektplan! ) • Darstellung auf Basis von Zielen mit Features oder nur auf Basis von Features • Produktziele bzw. Unterziele zum nächsten Produktziel werden mit einem Zeithorizont von 6 bis 12 Monaten formuliert (kein Projektplan! ) • Darstellung auf Basis von Zielen mit Features oder nur auf Basis von Features Product Roadmap F Figure 16: Einordnung der Product Roadmap Abbildung 16: Einordnung der Product Roadmap 46 5 Scrum Artefakte - Die Übersicht behalten Hierbei können unterschiedliche Roadmap-Typen zum Einsatz kommen. Die wohl bekannteste Roadmap ist an den Funktionen des Gesamtproduktes bzw. des nächsten Produktziels (auf Ebene der Features oder Epics) ausgerichtet. Abbildung 17 zeigt eine solche Feature Roadmap. Zeitrahmen Q1/ 202x Q2/ 202x Q3/ 202x Q4/ 202x Funktionsumfang (Features) • Feature A • Feature B • Feature C • Feature D • Feature E • Feature F • Feature G • Feature H • Feature I • Feature J • Feature K • Feature L Metriken / Erfolgsparameter • Metrik A • Metrik C • Metrik A • Metrik D • Metrik B • Metrik D • Metrik F • Metrik G Figure 17: Feature Roadmap Abbildung 17: Feature Roadmap Die Feature Roadmap wird meistens für einen größeren Zeithorizont genutzt. Typisch sind Zeiträume von größer als einem Jahr. Wenn es viele Features gibt, kann die Roadmap schnell unübersichtlich werden und die Abhängigkeiten zwischen den Fea‐ tures werden nicht ausreichend berücksichtigt. In solchen Konstellationen hat sich die zielorientierte Roadmap bewährt (siehe Abbildung 18). Bei dieser Roadmap erfolgt die Strukturierung anhand von Hauptfunktionen zu einem Ziel auf der Roadmap. Dadurch bleibt die übergeordnete Sichtweise auf die Basis der Ziele erhalten, die Details sind ebenfalls erkennbar. Das Backlog ist damit klarer strukturiert. Bei der zielorientierten Roadmap wird, je nach Produktausprägung, ein Zeitraum von sechs Monaten bis zu maximal einem Jahr genutzt, wobei alle ein bis drei Monate eine Überprüfung und Anpassung anhand der Sprintergebnisse vorgenommen werden sollte. 47 5.1 Von der Vision zum Product Backlog Zeitrahmen Q1/ 202x Q2/ 202x Q3/ 202x Q4/ 202x Name des Roadmap-Ziels Ziel A Ziel B Ziel C Ziel D Zielbeschreibung Funktionsumfang (Features) • Feature A • Feature B • Feature C • Feature D • Feature E • Feature F • Feature G • Feature H • Feature I • Feature J • Feature K • Feature L Metriken / Erfolgsparameter • Metrik A • Metrik C • Metrik A • Metrik D • Metrik B • Metrik D • Metrik F • Metrik G Figure 18: Zielorientierte Roadmap Abbildung 18: Zielorientierte Roadmap Ein weiterer Vorteil der zielorientierten Roadmap ist, dass sie Roadmap-Ziele hat. Entweder werden kurzfristige Produktziele abgebildet - dann sind bereits alle Anfor‐ derungen an die Ziele erfüllt - oder sie werden durch Unterziele auf dem Weg zu den nächsten Produktzielen ergänzt. Im zweiten Fall sind für die Unterziele ebenfalls die grundlegenden Kriterien für Ziele zu erfüllen. Zumindest sollte jedem Unterziel eine sinnvolle Metrik, mit der die Zielerreichung gemessen wird, zugewiesen werden. So können der Entwicklungsfortschritt und die damit einhergehende Wertsteigerung auf dem Weg zum Produktziel geprüft werden. Die Features der zielorientierten Roadmap lassen sich einfach auf die Formulierung der Sprintziele übertragen. Im Grunde stellt dieser Übertrag die gleiche Beziehung wie zwischen Produktzielen und deren Unterzielen in der Roadmap dar. Ein Sprintziel wird erst bei der Sprintplanung vom Scrum Team formuliert und ist die selbstverpflichtende Zielvorgabe für den aktuellen Sprint, ohne dabei zu definieren, welche Arbeit dafür erforderlich ist. Dadurch bleibt die Flexibilität erhalten. In der Praxis ist dieser einfach klingende Ansatz schwieriger umzusetzen. Ein Grund dafür kann sein, dass nicht fokussiert genug auf ein Produktziel hingearbeitet wird. Möglicherweise gibt es auch zu viele Vorstellungen darüber, was im nächsten Sprint umgesetzt werden sollte, um das Produktziel zu erreichen. Einige Teammitglieder denken vielleicht an neue Funktionen, während andere der Meinung sind, dass erstmal die Infrastruktur erweitert und bereitgestellt werden müssen. Beides kann richtig sein und zum Sprintziel passen, muss es aber eben nicht. So wird die Festlegung auf ein Sprintziel zu einer Herausforderung. Achten Sie darauf, dass Sie sich am Ende auf ein 48 5 Scrum Artefakte - Die Übersicht behalten Sprintziel verständigen und diese Diskussion nicht mit einer Reihe oder sogar ohne ein echtes Sprintziel endet. Schließen Sie eine Funktion alle zwei bis drei Sprints immer auf der Feature- oder Epic-Ebene ab (siehe Abbildung 19). Die Sprintziele lassen sich so wesentlich konkreter formulieren. In diesem Szenario könnte das erste Sprintziel daher „Bereitstellung der Infrastruktur“ lauten. Das zweite Ziel könnten Sie als „Verbesserung von Feature XY“ festlegen. Auf diese Weise wird das Team motiviert, gemeinsam auf ein Thema hinzu‐ arbeiten, anstatt alles parallel machen zu wollen und an unterschiedlichen Themen zu arbeiten. Selbstverständlich darf die agile Vorgehensweise bei der Entwicklung der Sprintziele nicht zu kurz kommen. Sollte sich während eines Sprints herausstellen, dass aufgrund eines unerwarteten Aufwands oder einer blockierten Aufgabe nicht alles erledigt werden kann, ermitteln Sie gemeinsam mit dem Product Owner, ob das das Sprint Backlog reduziert wird. Das Sprintziel sollte dabei nicht verändert werden. „Alle User Stories aus der Sprintplanung sind zu erledigen“ ist daher kein sinnvolles Sprintziel. Es muss auch dann erreicht werden können, wenn es nicht vollständig der Planung entspricht. Das Sprintziel „Reduzierung der Code-Komplexität von Feature XY“ bietet zum Beispiel ausreichend Spielraum. 49 5.1 Von der Vision zum Product Backlog Mission 1 Produkt-Vision 2 Produkt-Strategie 3 Marktsegmente und Zielgruppen A Marktanforderungen B Geschäftserwartungen C Kernfunktionalität D Produkt-Ziele E Erfolgsfaktoren I Taktische Ausrichtung II Produkt Roadmap E • Sprintlänge anhand der Produkt Roadmap festlegen, sodass 2-3 Sprints jeweils ein Feature/ eine Epic abschließen. • Sprintziel auf das nächste Roadmap-Ziel ausrichten. • Sprintlänge anhand der Produkt Roadmap festlegen, sodass 2-3 Sprints jeweils ein Feature/ eine Epic abschließen. • Sprintziel auf das nächste Roadmap-Ziel ausrichten. Produkttaktik 4 Abbildung 19: Produkttaktik 50 5 Scrum Artefakte - Die Übersicht behalten Im obigen Sprintziel aus den Bereich Refactoring könnte es das Ziel sein, eine 20-prozentige Verbesserung der Code-Komplexität zu erreichen. Was passiert, wenn nur 19 % erreicht wurden? Lässt sich dann noch immer von Erfolg sprechen? Vermeiden Sie deshalb vage Begriffe wie Erfolg oder Erfüllung von Zielen. Deutlicher wird es am Beispiel der Sorites-Paradoxie (Paradoxie des Haufens) oder an der Paradoxie des Eubulides (Paradoxie vom Kahlköpfigen). Die Sorites-Paradoxie beinhaltet die Frage, ab wann ein Sandhaufen kein Sandhaufen mehr ist, wenn einzelne Sandkörner entfernt werden. ■ Gegeben: Ein Sandhaufen, aus dem einzelne Körner entfernt werden. ■ Annahme: Das Entfernen eines einzelnen Korns verwandelt einen Haufen nicht in einen Nicht-Haufen. ■ Paradoxie: Was passiert, wenn bei der bestehenden Annahme der Prozess „Entfernen eines einzelnen Sandkorns“ oft genug wiederholt wird? Ist ein einzelnes Sandkorn dann noch ein Haufen? Wenn nicht, wann hat es sich von einem Haufen in einen Nicht-Haufen verändert? Ist ein Sandhaufen durch die Anzahl der Körner definiert? Wenn ja, was ist, wenn alle Körner nebeneinander angeordnet sind? Die Paradoxie des Eubulides stellt die Frage, wie viele Haare ein Mensch besitzen muss, um nicht als kahlköpfig zu gelten. Beiden Paradoxien liegt die Annahme zugrunde, dass ein einzelnes Sandkorn oder ein einzelnes Haar nicht über die Ausprägung Haufen oder behaart oder kein Haufen bzw. kahl entscheiden könne. Die Paradoxie zeigt sich in beiden Fällen, wenn versucht wird, etwas zu bestimmen, für das keine genaue Definition existiert. Dieser Herausforderung können Sie umgehen, indem ein fester Grenzwert festgelegt wird. (Beispiel: 20-prozentige Reduzierung der Komplexität des Programmcodes). Gän‐ gige Praxis ist auch, einen Grenzbereich (Beispiel: 15bis 20-prozentige Reduzierung der Komplexität des Programmcodes) oder mehrere Grenzwerte (Beispiel: Bei unter 8 bis 10 % ist das Ziel nicht erreicht, zwischen 10 und 15 % ist das Ziel erfüllt, bei über 15 % wird das Ziel übertroffen) zu verwenden. Sie können auch im Gruppenkonsens prüfen, ob das Ziel erreicht wurde (Beispiel: Gruppe entscheidet, ob die Verbesserung der Programmcodes ein Erfolg war). Lassen Sie bei der Bewertung genügend Spielraum. Welches Team hat schon Lust, das Sprintziel regelmäßig zu verfehlen, obwohl es nur wenige Prozentpunkte hinter den Zielvorgaben liegt? 51 5.1 Von der Vision zum Product Backlog Mission 1 Produkt-Vision 2 Produkt-Strategie 3 Marktsegmente und Zielgruppen A Marktanforderungen B Geschäftserwartungen C Kernfunktionalität D Produkt-Ziele E Erfolgsfaktoren I Taktische Ausrichtung II Produkt Roadmap E Produkttaktik 4 Überprüfung alle 4-6 Wochen Überprüfung alle 6-12 Monate Überprüfung alle 3-12 Monate Überprüfung alle 2-9 Monate Überprüfung alle 1-6 Monate Figure 20: Überprüfungsintervalle von der Taktik bis zur Vision Abbildung 20: Überprüfungsintervalle von der Taktik bis zur Vision 52 5 Scrum Artefakte - Die Übersicht behalten Wie auch immer die Sprintziele bewertet werden, sie haben Auswirkungen auf das nächste Ziel der Product Roadmap. Daher sollten die Sprintergebnisse, abhängig von der Länge der Sprints, alle paar Wochen oder nach zwei bis drei Sprints dahingehend untersucht werden, ob das nächste Ziel auf der Product Roadmap noch realistisch ist. Abhängig davon kann das nächste Sprintziel darauf ausgerichtet werden. Vielleicht ist auch eine Korrektur der Ziele auf der Roadmap notwendig, um das nächste Produktziel zu erreichen. Daher sollte auch die Roadmap alle paar Monate (abhängig vom Road‐ map-Typ, der Sprintlänge und den Produkttypen) überprüft und angepasst werden. Wenn anhand der Roadmap erkannt wird, dass ein Produktziel nicht erreicht wird oder obsolet geworden ist, sollte auch das Produktziel angepasst werden. Das sollte alle zwei bis neun Monate erledigt werden. Das Gleiche gilt für die Produktstrategie und die Vision. Prüfen Sie diese alle sechs bis zwölf Monate und nehmen Sie entsprechende Anpassungen vor. So erreicht man eine Rückkopplung von den Sprintergebnissen bis hin zur Produktvision (siehe Abbildung 20). Figure 21: Von der Produktidee zum Sprintziel Von der Produktidee zur Produktvision 1 Stakeholder-Mapping durchführen 2 Produktvision definieren Von der Produktvision zur Produktstrategie 1 Zielgruppen und Marktsegmente ermitteln 2 Ziele entlang der Marktsegmente und Zielgruppen definieren Notwendigkeit bzw. Nutzen des Produktes auf Basis der Problemstellungen beschreiben 3 Ziel aus Business Sicht definieren Gewünschte Vorteile des Produktes anhand der Business-Anforderungen beschreiben 4 Grobe Beschreibung der wichtigsten funktionalen und nicht funktionalen Anforderungen (High-Level-Features), ausgerichtet an den vorigen Punkten Von der Produktstrategie zu den Produktzielen 1 Erfolgsfaktoren festlegen (Kosten, Zeit, Funktionsumfang, Qualität, usw.) 2 Produktziele anhand aller vorigen Ergebnisse definieren Von den Produktzielen zu den Sprintzielen 1 Produkt Roadmap für überschaubaren Zeitraum erstellen: Wie sollen die Produktziele erreicht werden? 2 Sprintziele am nächste Ziel der Produkt-Roadmap ausrichten. Abbildung 21: Schritte von der Produktidee zu den Sprintzielen In Abbildung 21 sind nochmal die wesentlichen Schritte auf dem Weg von der Pro‐ duktidee zu den Sprintzielen zusammengefasst. Abbildung 22 zeigt die Rückkopplung, ausgehend von Sprintergebnissen bis hin zur Anpassung der Produktausrichtung. 53 5.1 Von der Vision zum Product Backlog Figure 22: Von der Produktidee zum Sprintziel Von den Sprintergebnissen zur Anpassung der Produktausrichtung 1 Prüfen der Ergebnisse der Sprints hinsichtlich der Erfolgsfaktoren und der nächsten Ziele auf der Produkt Roadmap inkl. Berücksichtigung der Ergebnisse bei der Festlegung zukünftiger Sprintziele Frequenz: Alle zwei bis vier Wochen bzw. alle zwei bis drei Sprints 2 Produkt Roadmap anhand der aktuellen Sprintergebnisse regelmäßig überprüfen und ggf. anpassen Frequenz: Alle eins bis sechs Monate (abhängig von Roadmap-Typ und Sprintlängen) 3 Produktziele anhand der aktuellen Produkt-Roadmap regelmäßig überprüfen und ggf. anpassen Frequenz: alle zwei bis sechs Monate 4 Produktstrategie anhand der aktuellen Produktziele regelmäßig überprüfen und ggf. anpassen Frequenz: alle drei bis zwölf Monate 5 Produktvision anhand der aktuellen Produktstrategie regelmäßig überprüfen und ggf. anpassen Frequenz: alle sechs bis zwölf Monate Abbildung 22: Von den Sprintergebnissen zur Anpassung der Produktausrichtung 5.2 Product Backlog Grundlagen Nach dem Ausflug in die Welt der Visionen und Ziele untersuchen wir nun mit dem Product Backlog das erste Artefakt. In Kapitel 3.3 wurde bereits beschrieben, wofür es verwendet wird. Das Product Backlog ist eine geordnete Liste von Dingen, die der Produkterstellung und -verbesserung dienen. Alle Arbeiten, die das Scrum Team erledigt, stammen aus dieser einzigen Quelle. Dreh- und Angelpunkt des Product Backlogs ist das Produktziel, das im vorherigen Kapitel ausgiebig behandelt wurde. Nachdem das Produktziel festgelegt wurde, werden die Anforderungen, die an das Produkt gestellt werden, formuliert. Das erinnert im ersten Moment an das Pflichten- und Lastenheft aus dem klassischen Projektmanage‐ ment. Dies ist jedoch anders zu werten. Die bei der Wasserfallmethode üblichen Phasen Definition, Analyse, Design und Umsetzung werden auch nicht sequenziell, sondern iterativ durchlaufen. So können zum Beispiel die ersten zwei bis drei Anforderungen aus dem Product Backlog in das Sprint Backlog übernommen und umgesetzt werden, während weitere Anforderungen für das Product Backlog definiert werden. Auf diese Weise können die Anforderungen kurzfristig den aktuellen Gegebenheiten angepasst werden. Das klingt nicht nur in der Theorie gut, sondern funktioniert sogar in der Praxis. Es sind einige Punkte zu beachten, damit der Überblick erhalten bleibt. In diesem Kapitel geben wir ein paar Hilfestellungen, damit Sie auch diese Herausforderung erfolgreich meistern. Das Product Backlog enthält alle Anforderungen, die zur Erreichung des Produkt‐ ziels umgesetzt werden müssen. Die Zerlegung dieser Anforderungen in kleinere und immer präzisere Elemente nennt man Product Backlog Refinement. Da der Product Owner die Produktzielgruppe repräsentiert, wird in der Regel erwartet, dass er alle 54 5 Scrum Artefakte - Die Übersicht behalten Anforderungen bis ins letzte Detail beschreibt. Das ist nicht sinnvoll. Der Product Owner ist zwar verantwortlich für das Product Backlog, jedoch sollte sich das gesamte Team bei der Verfeinerung der Anforderungen aktiv beteiligen. Die primäre Aufgabe des Product Owners ist es, die Reihenfolge, mit der die Anforderungen konkretisiert werden, vorzugeben. Auf diese Weise können sich alle Teammitglieder mit dem Product Backlog identifizieren. Letztendlich stellt das Product Backlog eine priorisierte Anforderungsliste dar, die im Zeitablauf stetig detaillierter wird. Sie ändert sich kon‐ tinuierlich und ist niemals vollständig. Es sein denn, das Projekt ist abgeschlossen, und selbst dann kann es sein, dass sich während der Nutzung des Produkts Erweiterungs- oder Änderungswünsche ergeben, die in das Product Backlog aufgenommen werden müssen. Die Elemente der Anforderungsliste werden meistens als Backlog Items bezeichnet. Hierbei wird selten zwischen Product Backlog und Sprint Backlog Items differenziert. Neben funktionalen Anforderungen werden auch nichtfunktionale Items in das Back‐ log aufgenommen. Hierzu zählen beispielsweise Anforderungen, welche die Perfor‐ mance, die Stabilität oder die Skalierbarkeit einer IT-Lösung betreffen. Darüber hinaus können auch technische Elemente, wie die Bereitstellung von Systemumgebungen (zum Beispiel Entwicklungs-, Test-, oder Produktionsumgebung) oder Fehlerbeschrei‐ bungen, Teil des Product Backlogs sein. Umgesetzt werden allerdings immer nur die Product Backlog Items, die in das Sprint Backlog übernommen werden. Wie können Sie nun bei einem großen Projekt mit zahlreichen Anforderungen die Übersicht behalten? Grundsätzlich sollten die Anforderungen top-down verfeinert werden. So ergibt sich eine hierarchische Struktur, in der die Anforderungen immer kleinteiliger werden. Hierbei wird nicht immer die gleiche Anzahl an Hierarchieebenen verwendet. Jedes Team hat seine eigenen Vorlieben, was die Anzahl der Hierarchie‐ ebenen und deren Bezeichnungen betrifft. Wenn Sie eine Softwarelösung für die Verwaltung des Backlogs verwenden, sind Sie zudem davon abhängig, was Ihnen hier angeboten wird. Anfangs waren diese drei Ebenen gängige Praxis: ■ Epic (höchste Ebene), ■ User Story (mittlere Ebene) und ■ Task (höchster Detailierungsgrad auf der untersten Ebene). ■ Später kamen folgende Ebenen mit unterschiedlicher Einsortierung hinzu: ■ Themes (entweder als Ebene oberhalb der Initiative oder als Verknüpfungselement zwischen einzelnen Initiativen), ■ Initiativen (in den meisten Fällen als höchste Ebene, entweder über Features oder Epics) und ■ Features (mal über und mal unter den Epics, aber eigentlich immer unter den Initiativen). Unabhängig von der Anzahl der Ebenen gilt immer, dass ein Element einer Hierarchie‐ ebene immer mehrere Elemente der darunterliegenden Ebene enthält. Ein Epic oder 55 5.2 Product Backlog Grundlagen ein Feature besteht immer aus mehreren User Stories und eine User Story umfasst meistens mehrere Tasks. Leider ist nicht allgemeingültig festgelegt, welche Hierarchieebene wofür verwendet wird. Das kann in der Praxis zu Verwirrungen führen, sodass die Projektbeteiligten nicht wissen, worüber eigentlich geredet wird. Es entstehen unübersichtliche Product Backlogs. Nachfolgend werden die in Abbildung 23 gezeigten Ebenen verwendet. Auf oberster Ebene gibt es Themes. Diese bestehen aus mehreren Initiativen, die sich in Epics untergliedern. Mehrere Features werden zu einem Epic zusammengefasst und auf User Stories heruntergebrochen. Eine User Story wird schließlich auf unterster Ebene in Tasks unterteilt. Feature User Story Task Epic Task User Story Feature Epic Initiative Figure 23: Beispiel einer Struktur-Hierarchie Abbildung 23: Beispiel einer Struktur-Hierarchie Es ist gängige Praxis, dass … ■ … Themes an langfristigen Zielen ausgerichtet werden. Hiermit kann ein strate‐ gischer Nutzen oder ein Ziel aus Business-Sicht verbunden sein. Themes werden häufig produktübergreifend formuliert. ■ … Initiativen den Themes zugeordnet sind oder mit diesen zusammenhängen. Sie beschreiben in der Regel eine sehr große Maßnahme, bei der typischerweise mehrere Teams involviert sein können. ■ … Epics größere Aufgabenstellungen einer Initiative beschreiben. Für deren Bearbeitung benötigt man üblicherweise mehrere Sprints. Sie repräsentieren oft ein Ziel auf einer zielorientierten Roadmap, wobei die Aufgabenstellungen oder Anwendungsfälle in Form von Szenarien beschrieben werden. ■ … Features spezielle Produkteigenschaften darstellen, die den Epics zugeordnet werden. Man verwendet sie gerne für die Abbildung von Funktionen eines Ziels auf einer Roadmap. ■ … User Stories den Anforderungsbeschreibungen aus Nutzersicht entsprechen. User Stories werden in Sprints umgesetzt, nachdem sie vom Product Backlog in das Sprint Backlog übernommen wurden. 56 5 Scrum Artefakte - Die Übersicht behalten ■ … Tasks die Arbeitspakete einer User Story sind. Sie werden in einem Sprint abgearbeitet. Theme: Basiert auf der Vision Initiative: Basiert auf dem Produkt-Ziel Epic: Basiert auf dem Produkt-Roadmap-Ziel Feature: Basiert auf dem Product-Roadmap-Feature User Story: Basiert auf der Anforderung eines Features Task: Basiert auf einem kleinen Arbeitspaket der User Story Figure 24: Zuordnung der Strukturelemente Abbildung 24: Zuordnung der Strukturelemente Die Zusammenhänge zwischen den Ebenen zu verstehen, ist maßgeblich auf dem Weg der Zielerreichung, da diese einen großen Einfluss auf das Product Backlog haben. Sind beispielsweise alle Tasks einer User Story abgearbeitet, ist auch die User Story (abhängig von der Definition of Done) abgeschlossen. Wenn alle User Stories eines Features fertig sind, ist auch das Feature mit hoher Wahrscheinlichkeit beendet. Aus diesem Grund gilt für eine User Story die einfache Regel, dass alle Tasks einer User Story in einem Sprint abgeschlossen werden können. Features und Epics sind hingegen zu umfangreich für einen einzelnen Sprint. In der Praxis hat sich bewährt, dass ein Epic circa zwei bis sechs Sprints erfordert. Wenn zwischen den User Stories und den Epics eine weitere Hierarchieebene einbezogen wird, kann die Bearbeitung eines Epics auch länger dauern. Das bedeutet jedoch nicht, dass die Sprints, die für die Bearbeitung eines Epics oder Features benötigt werden, direkt nacheinander durchlaufen werden. Das hängt von der Priorisierung und damit von den Sprintzielen ab. Dazu folgen in späteren Kapiteln weitere Informationen. Denkbar wären beispielsweise folgende Größenordnungen: ■ 1 bis 3 Jahre: Theme (Vision, strategischer Nutzen oder Business-Ziele) ■ 6 bis 12 Monate: Initiative (Produktziele) ■ 2 bis 6 Monate: Epic (Ziele einer Roadmap) ■ 1 bis 2 Monate: Feature (Funktionen der Roadmap-Ziele) ■ 1 bis 4 Wochen (maximal eine Sprintlänge): User Story (Anforderungen eines Features) ■ 4 Stunden bis 2 Tage: Task (Arbeitspakete der User Story) 57 5.2 Product Backlog Grundlagen Theme: 1 bis 3 Jahre Initiative: 6 bis 12 Monate Epic: 2 bis 6 Monate Feature: 1 bis 2 Monate User Story: 1 Tag bis 4 Wochen (Best Practice: 1-5 Tage) Task: 2 Stunden bis wenige Tage (Best Practice: 4-16 Stunden) Figure 25: Backlog Strukturelemente mit zeitlichem Umfang Abbildung 25: Backlog Strukturelemente mit zeitlichem Umfang Häufig ist zu beobachten, dass einem Epic oder Feature weitere User Stories zugeord‐ net werden. Das ist grundsätzlich konform mit der agilen Vorgehensweise, jedoch können dadurch Epics und Features zu Sammelpools für User Stories verkommen und eine endlose Bearbeitungszeit bekommen. Die User Stories werden nur noch in wenige Epics oder Features gruppiert und das Product Backlog muss letztlich auf der User-Story-Ebene verwaltet werden. Ziel ist jedoch, die Anforderungen auf höherer Ebene gegeneinander abzugrenzen, um hierüber eine Priorisierung und ein sinnvolles Fortschritts-Reporting abbilden zu können. Es ist deutlich einfacher, auf einer höheren als auf einer niederen Ebene zu priori‐ sieren. Das gilt insbesondere, wenn es auf der Detailebene zusätzliche Abhängigkeiten gibt. Jeder, der schon einmal versucht hat, eine Roadmap anhand von User Stories aufzubauen, weiß, dass diese Vorgehensweise zum Scheitern verurteilt ist. Auch bei Scrum ist es nicht sinnvoll, einfach anzufangen und das Backlog sukzessive mit Anforderungen zu füllen. Eine übergeordnete Strukturierung würde dann fehlen, was das gesamte Vorhaben unnötig schwierig werden lässt. Deshalb ist es ratsam, dass die Anforderungen aus der Produktvision abgeleitet werden und so ein sinnhaftes Backlog entsteht (siehe Kapitel 5.1). Es gibt keine allgemeingültige Regel, wie Strukturelemente, die sich oberhalb der User Stories befinden, zu verwenden sind. Initiativen, Features und Epics sollten sich an abgrenzbaren Bereichen orientieren. Der Detailgrad nimmt von oben nach unten zu. Die Struktur richtet sich nach der Produktstrategie, die vom Product Owner - gegebenenfalls mit der Unterstützung des Scrum Masters - entworfen wird. Anschlie‐ ßend sollte die Struktur im Team diskutiert werden. Hierbei ergeben sich häufig hilfreiche Änderungsvorschläge, die berücksichtigt werden können, bevor die Struktur mit den relevanten Stakeholdern abgestimmt wird. Durch diese Diskussion erhalten die Teammitglieder außerdem einen guten Überblick zu dem geplanten Produkt. In dieser Struktur sollten sich auch die technischen Anforderungen widerspiegeln. Es ist nicht empfehlenswert, hierfür nur ein Epic (oder ein Feature) mit der Bezeichnung „technische Voraussetzungen“ anzulegen und diesem Epic (oder diesem Feature) alle technischen User Stories zuzuordnen. Richten Sie die Epics/ Features an größeren Zielen aus. Fokussieren Sie sich dabei auf die wichtigsten Funktionen und Anforde‐ 58 5 Scrum Artefakte - Die Übersicht behalten rungen. Sie sparen sich viel Zeit und Arbeit, wenn Sie frühzeitig auf einer höheren Strukturebene priorisieren als später auf der Ebene der detaillierteren User Stories. Das gilt auch für die Wertermittlung (Business Value) der Anforderungen. Dem wird oft entgegengehalten, dass jede User Story einen eigenen Business Value haben muss. Wenn der Business Value jedoch auf höherer Ebene festgelegt wird, kann dieser Wert von der Summe der einzelnen Business Values auf Ebene der User Stories abweichen. Das ist sicher richtig, gerade zu Projektbeginn werden für ein Epic (bzw. ein Feature) regelmäßig neue User Stories identifiziert. US-B (50) US-B (50) User Story-A (130) User Story-A (130) Feature A (Plan: 200/ Sum: 210) Feature A (Plan: 200/ Sum: 210) Epic A (Plan: 340/ Summe: 80) Epic A (Plan: 340/ Summe: 80) Initiative A (Plan: 480/ Summe: 105) Initiative A (Plan: 480/ Summe: 105) B u s i n e s s V a l u e ( i n T € ) Zeit US-C (30) US-C (30) US-E (30) US-E (30) US-D (80) US-D (80) Feature B (P: 140 / S: 130) Feature B (P: 140 / S: 130) US-F (20) US-F (20) Epic B (Plan: 140/ Summe: 120) Epic B (Plan: 140/ Summe: 120) US-G (50) US-G (50) Feature C (P: 80 / S: 60) Feature C (P: 80 / S: 60) US-H (10) US-H (10) US-I (10) US-I (10) Feature D (P: 60 / S: 60) Feature D (P: 60 / S: 60) US-J (30) US-J (30) US-K (20) US-K (20) US-L (10) US-L (10) Figure 26: Abweichung von Plan- und Istwerten bei Strukturelementen Abbildung 26: Abweichung von Plan- und Ist-Werten zwischen Strukturelementen Deshalb ist es zum Anfang eines Projektes weniger sinnvoll, die Business Values, die für die Priorisierung benötigt werden, bottom-up zu ermitteln. 5.3 Aufbau, Priorisierung und Sortierung des Product Backlogs Es hat sich bewährt, das Product Backlog in folgende fünf Schritte aufzubauen: ■ Zuerst werden die Strukturelemente auf der obersten Ebene (Themes oder Initia‐ tiven) festgelegt. Diese orientieren sich an der Vision bzw. an der Strategie. ■ Anschließend werden je Theme (bzw. je Initiative) die Anforderungen in Form von Epics (oder Features) grob erfasst. Anhand dieser Übersicht kann man eine erste Vollständigkeitsprüfung der High-Level-Anforderungen vornehmen. In dieser Aufstellung sollten auch nichtfunktionale Anforderungen enthalten sein. ■ Auf Basis der Epics (oder Features) erfolgt eine erste Priorisierung der Anforde‐ rungen. Berücksichtigen Sie dabei folgende vier Punkte: 59 5.3 Aufbau, Priorisierung und Sortierung des Product Backlogs • Welchen Wert hat die Anforderung? Diese Wertermittlung ist besonders wichtig, um werthaltige Elemente frühzeitig zu identifizieren und bereits zu einem frühen Zeitpunkt eine Wertmaximierung des zu erstellenden Produkts sicherzustellen. Hierbei muss es sich nicht zwingend um einen monetären Wert handeln. Ein wichtiger Nutzen, wie das Erreichen von notwendigem Wissen zur Umsetzung weiterer Anforderungen, kann auch einen hohen Wert darstellen. • Welche Abhängigkeiten bestehen zwischen den Anforderungen und den Zielen (ggf. Releases) und anderen Produkten, Services oder Teams? Die wert‐ vollsten Anforderungen können häufig nicht direkt am Anfang umgesetzt werden, weil es Abhängigkeiten mit anderen, weniger wertvollen Anforde‐ rungen gibt. Wie soll zum Beispiel eine Entwicklung starten, wenn keine Entwicklungsumgebung zur Verfügung steht oder das Wissen zur Einrichtung der Entwicklungsumgebung fehlt? • Welche Risiken gehen mit einer Anforderung einher? Hierbei sind zwei Aspekte zu berücksichtigen: i. Welche Risiken gibt es bei der Umsetzung der Anforderung? Bei der Be‐ wertung müssen die Auswirkung und die Eintrittswahrscheinlichkeit be‐ rücksichtigt werden. Abhängig davon, sind gegebenenfalls Maßnahmen zur Minderung, Vermeidung oder Übertragung der Risiken zu ergreifen. ii. Gibt es Risiken, die durch die Umsetzung einer Anforderung gemindert oder vermieden werden können und wie wirken sich diese Maßnahmen auf die Erfolgsfaktoren (beispielsweise Zeit, Kosten oder Wert und Ab‐ hängigkeiten) gegenüber anderen Anforderungen aus? • Welche Kosten entstehen bei der Umsetzung der Anforderung? Insbesondere in der Startphase ist es besonders schwer, eine Kostenschätzung zu erstellen und oftmals gar nicht erst machbar. Das liegt zum einen daran, dass die Anfor‐ derungen zu diesem Zeitpunkt noch sehr unspezifisch sind und zum anderen ist noch unklar, was in einen Sprint geleistet werden kann. Die Schätzungen werden daher immer präziser, je mehr Informationen zu den Anforderungen und je mehr Erfahrungswerte zur Team Performance vorliegen. ■ Im nächsten Schritt müssen die Anforderungen, die sich auf das nächste Pro‐ dukt- oder Roadmap-Ziel beziehen und die höchste Priorität haben, konkretisiert werden. Dies kann auf Ebene der User Stories oder auf einer Zwischenebene (Epics oder Features) gemacht werden. Es ist besser, wenn man zu diesem frühen Zeitpunkt noch auf Epic- oder Feature-Ebene arbeitet. So wird vermieden, dass man sich im Detail verliert, was bei der Verfeinerung von User Stories schnell passieren kann. Gerade Abhängigkeiten, die es innerhalb und zwischen Epics oder Features gibt, werden offensichtlicher, was hilfreich für die Priorisierung ist. Der Nachteil an dieser Vorgehensweise ist, dass man nach einer Konkretisierung auf der Zwischenebene keine Backlog Items erhält, mit deren Umsetzung gestartet werden kann. Daher müssen nach der Epicsbzw. Feature-Verfeinerung noch User 60 5 Scrum Artefakte - Die Übersicht behalten Stories für die initiale Befüllung des Product Backlogs erstellt werden. Es genügt, wenn User Stories für zwei bis drei Spints vorhanden sind. ■ Zum Schluss erhalten die höchstpriorisierten User Stories einen verfeinerten Detaillierungsgrad auf Task-Ebene. Diese fünf Schritte werden in regelmäßigen Abständen immer wieder durchlaufen, um neue Anforderungen zu identifizieren. In neuen Projekten sollte die Priorisierung der Anforderungen anhand des Business Values und anhand des Risikowertes erfolgen. Die Priorisierungen bestimmen jedoch nicht automatisch die Reihenfolge bei der Umsetzung. Etwaige Abhängigkeiten spielen dabei eine bedeutendere Rolle. Ziel es also, die Anforderungen mit dem höchstem Business Value und dem höchsten Risikowert inklusive aller Voraussetzungen, die dafür vorab geschaffen werden müssen, zuerst umzusetzen. So wird erreicht, dass der Produktwert vom ersten Tag an maximiert wird und gleichzeitig die größten Risiken angegangen werden. So erkennen Sie frühzeitig, ob ein Projekt erfolgversprechend ist. Die frühe Erkenntnis, dass ein Projekt nicht gelingen wird, ist sehr wertvoll. Fail Fast spart Geld und Nerven. Planung basierend auf höchstem Business Value und höchstem Risiko • Ziel: User Stories mit dem höchsten Business Value und dem höchstem Risiko zuerst • Komplexität spiegelt sich meistes im Business Value und Risiko wieder • Gesamtverlauf häufig nahe an der Ideallinie • Weniger „Überraschungen“ im Zeitverlauf und frühzeitige Wertgenerierung 100 0 25 50 75 % abgeschlossen 1/ 4 0/ 4 2/ 4 3/ 4 4/ 4 Zeit Risikoeinschätzung Komplexitätseinschätzung Business Value Idealverlauf Figure 27: Planung mit höchstem Wert und Risiko zuerst Abbildung 27: Planung mit höchstem Wert und Risiko zuerst 61 5.3 Aufbau, Priorisierung und Sortierung des Product Backlogs Die eine richtige Reihenfolge der Umsetzung der User Stories gibt es jedoch nicht. Einen wesentlichen Einfluss darauf haben die Unternehmensziele. Es kann eine clevere Entscheidung sein, zuerst alle Anforderungen mit dem höchsten Business Value und dem geringsten Risiko umzusetzen, da dadurch notwendige Einnahmen, die man für das Projekt benötigt, generiert werden. In diesem Fall ist es optimal, wenn Sie mit Anforderungen starten, die einen hohen Wertbeitrag haben und mit geringem Aufwand umgesetzt werden können. So werden bereits zu Projektbeginn schnelle Erfolge erzielt. Im weiteren Projektverlauf wird es zu einer deutlichen Verlangsamung kommen, da die am Anfang ignorierten Risiken im Zeitverlauf zu Problemen werden. Das Projekt dauert länger als ursprünglich geplant und es kann sogar zu einem Projektabbruch kommen. Planung basierend auf höchstem Business Value • Ziel: User Stories mit den dem höchsten Business Value zuerst • Wenig Liefererfolge am Anfang  kaum sichtbare Erfolge  Produkt oft nicht nutzbar • Kaum zusätzlich Wert im späteren Verlauf aufgrund weniger werthaltiger Elemente • Von Anfang an hoher Wert für das Business, wenn es möglich ist, das Produkt zu vermarkten 100 0 25 50 75 % abgeschlossen Zeit 1/ 4 0/ 4 2/ 4 3/ 4 4/ 4 Risikoeinschätzung Komplexitätseinschätzung Business Value Idealverlauf Figure 28: Planung mit höchstem Business value zuerst Abbildung 28: Planung mit höchstem Business Value zuerst Denkbar ist auch, dass risikoreiche Anforderungen zuerst - ohne Rücksicht auf deren Business Value - umgesetzt werden, um zu prüfen, ob das Projekt grundsätzlich durchführbar ist. Das widerspricht grundsätzlich dem Gedanken, dass immer eine Wertmaximierung angestrebt werden soll, also User Stories mit großem Wert priori‐ siert behandelt werden müssen. Erschwerend kommt hinzu, dass den Stakeholdern im Sprint Review nicht viel gezeigt werden kann, wenn zuerst nur risikoreiche, nicht‐ funktionale Anforderungen implementiert werden. Wie präsentiert man beispielsweise 62 5 Scrum Artefakte - Die Übersicht behalten die sehr performante Datenbank, wenn die Benutzerschnittstelle zur Erfassung der Daten und zur Datenauswertung fehlt? Da risikoreiche Anforderungen meistens zeit- und damit auch kostenintensiv sind, kann sich bei dieser Priorisierung auch ein merkwürdiges Fast-Fail-Phänomen ergeben: Das Geld geht aus, bevor ein lauffähiges Produkt entstanden ist. Planung basierend auf der Risikoeinschätzung • Ziel: User Stories mit den höchsten Risikowerten zuerst • Unterdurchschnittliche Liefererfolge, meistens über den gesamte Zeitverlauf • Risiken werden frühzeitig erkannt und können damit reduziert werden  keine „Überraschungen“ im späteren Verlauf 100 0 25 50 75 % abgeschlossen 1/ 4 0/ 4 2/ 4 3/ 4 4/ 4 Zeit Risikoeinschätzung Komplexitätseinschätzung Business Value Idealverlauf Figure 29: Planung mit höchstem Risiko zuerst Abbildung 29: Planung mit höchstem Risiko zuerst Man könnte das Backlog auch abhängig vom Aufwand sortieren. Bei dieser Option werden die User Stories mit dem geringsten Bearbeitungsaufwand zuerst bearbeitet. Es werden also in kurzen Zeitabständen viele (kleine) Anforderungen umgesetzt. Das scheint auf den ersten Blick erfolgreich zu sein, da schnell Ergebnisse geliefert werden können. Im weiteren Verlauf wird das Projekt jedoch ausgebremst. 63 5.3 Aufbau, Priorisierung und Sortierung des Product Backlogs Planung basierend auf der Komplexität • Ziel: User Stories mit den niedrigsten Aufwand zuerst • Gute Liefererfolge am Anfang  schnell sichtbare Erfolge • Deutliche Verlangsamung im späteren Verlauf aufgrund komplexerer Elemente • Geringer Wert über lange Zeit  Business Value wird erst im letzten Abschnitt generiert 100 0 25 50 75 % abgeschlossen Zeit 1/ 4 0/ 4 2/ 4 3/ 4 4/ 4 Risikoeinschätzung Komplexitätseinschätzung Business Value Idealverlauf Figure 30: Planung mit höchster Komplexität zuerst Abbildung 30: Planung mit höchster Komplexität zuerst Wie man es auch dreht und wendet: Der Klassiker unter den Product Backlog Sortierungen ist meistens die beste Wahl. Setze zuerst die Anforderungen mit dem höchsten Wert in Kombination mit dem höchsten Risiko und unter Berücksichtigung von Abhängigkeiten um. Oder einfacher ausgedrückt: Wenn Sie die Wahl zwischen zwei Funktionen mit gleichem Umsetzungsrisiko haben, dann sollten Sie immer die Funktion mit dem größeren Nutzen wählen - also das Feature, das den größten Profit bringt (siehe Abbildung 31). Business Value R i s i k o zuerst machen als zweites machen zuletzt machen hoch niedrig h o c h n i e d r i g vermeiden Figure 31: Priorisierung unter Berücksichtigung von Risiko und Business Value Abbildung 31: Priorisierung unter Berücksichtigung von Risiko und Business Value 64 5 Scrum Artefakte - Die Übersicht behalten In diesem Kontext fällt auch immer wieder der Begriff der Verzögerungskosten (Cost of Delay, kurz CoD). Verzögerungskosten beschreiben, was es ein Unternehmen kostet, wenn eine Funktionalität zeitverzögert auf den Markt kommt, die Funktionalität von den Kunden also später als geplant genutzt werden kann. Eine gute Orientierung bietet das MoSCoW-Priorisierungsschema. MoSCoW ist ein Akronym und steht für „Must have, Should have, Could have, Won’t have“. (Die kleingeschriebenen Os dienen lediglich der besseren Lesbarkeit und haben keine weitere Bedeutung.) Bei diesem Priorisierungsschema werden die Anforderungen anhand ihrer Wichtigkeit in folgende vier Klassen sortiert: „Unbedingt erforderlich“, „Sollten umgesetzt wer‐ den, nachdem alle Must-Anforderungen erledigt wurden“, „Kann umgesetzt werden, wenn höherwertige Anforderungen nicht beeinträchtigt werden“ und „Wird nicht umgesetzt, ist eventuell zu einem späteren Zeitpunkt interessant“. Im Scrum Guide wird vorgeschlagen, Aufwandsschätzungen in Form von Story Points vorzunehmen. Die Schätzungen können beispielsweise mit einem Planning Poker oder einer Magic Estimation ermittelt werden. Sollen diese Schätzwerte bei der Sortierung der User Stories im Product Backlog berücksichtigt werden? Die praktische Erfahrung zeigt, dass die Aufwandsschätzungen häufig zu ungenau sind und daher kein wesentliches Sortierkriterium sein sollten. Es soll an dieser Stelle nicht verschwiegen werden, dass die beschriebene Verfeinerung der Anforderungen von der Ebene der Initiativen über Epics und Features bis zu den User Stories fehlerbehaftet ist, wenn ein Produkt in einem sehr dynamischen Umfeld entwickelt wird. Investieren Sie in dem Fall nicht zu viel Zeit in eine akribische und detailliertere Ausführung. Grundsätzlich sollten Sie darauf achten, dass das Product Backlog nicht zu viele User Stories enthält. In der Praxis hat es sich bewährt, User Stories für maximal drei bis vier Monate im Vorrat zu haben. Der Product Backlog sollte nicht umfangreicher sein als es für die Erreichung des nächsten Ziels notwendig ist. Ansonsten verschwenden Sie zu viel Zeit damit, diese User Stories immer wieder aufzugreifen. Hinzu kommt, dass User Stories, die weitentfernte Ziele betreffen, häufig obsolet werden. 5.4 Sprint Backlog -ToDo-Liste für den laufenden Sprint Das Sprint Backlog ist eine To-Do-Liste für den laufenden Sprint, dessen Eigentümer die Entwickler sind. Sie verwalten die Backlog-Einträge. Im Sprint Backlog befindet sich also eine Sammlung aller Product Backlog-Einträge, die das Scrum Team für den aktuellen Sprint ausgewählt hat. Jedem Sprint Backlog wird zusätzlich ein Sprintziel zugewiesen. Mit diesem Ziel soll folgende zentrale Frage beantwortet werden: Warum ist der aktuelle Sprint sinnvoll beziehungsweise welchen Wertbeitrag leistet der aktuelle Sprint? Hiermit bekommt das selbstverwaltete Scrum Team eine Richtschnur für den Sprint. 65 5.4 Sprint Backlog -ToDo-Liste für den laufenden Sprint Welche Einträge aus dem Product Backlog in das Sprint Backlog verschoben werden, wird in der Sprint-Planungssitzung entschieden (siehe Kapitel 6.2). Das Ergebnis dieser Planungssitzung ist das Sprintziel, die ausgewählten Product Backlog-Einträge und eine Umsatzplanung für die Einträge im Sprint Backlog (siehe Abbildung 32). User Story 1 User Story 2 User Story 3 User Story 4 Product Backlog User Story 1 User Story 2 User Story 3 Sprint Backlog Task 1 Task 2 Task 3 Task 4 Task 1 Task 2 Task 1 Task 2 Task 3 User Story n … Sprintziel Figure 32: Sprint Backlog als Ergebnis des Sprint Plannings Abbildung 32: Sprint Backlog als Ergebnis des Sprint Plannings Anhand des Sprint Backlogs lässt sich jederzeit erkennen, wie das Sprintziel erreicht werden soll und woran im aktuellen Sprint gearbeitet wird. Zwei Elemente spielen hierbei eine wesentliche Rolle: User Stories und Tasks. Wann immer neue Informatio‐ nen zu diesen beiden Elementen vorliegen, muss das Sprint Backlog angepasst werden. Das Sprint Backlog ist also ein „lebendes Artefakt“, an dem jeden Tag Änderungen vorgenommen werden. Im Idealfall ändert sich während eines Sprints nur der Bearbei‐ tungsstatus der enthaltenen User Stories oder Tasks und am Ende eines Sprints sind alle Sprint Backlog-Einträge abgeschlossen. In der Realität gelangt man während eines Sprints jedoch zu neuen Erkenntnissen, die dazu führen, dass zum Beispiel neue Tasks zum Sprint Backlog hinzugefügt werden müssen oder es erforderlich ist, Tasks aus dem Backlog zu entfernen. Zusätzlich zu den User Stories kann auch mindestens einen Verbesserungspunkt in das Sprint Backlog aufgenommen werden, den das Scrum Team in der vorangegangenen Sprint Retrospektive identifiziert hat. Dadurch wird erreicht, dass das Scrum Team Zeit dafür vorsieht, die eigene Leistungsfähigkeit kontinuierlich zu verbessern. Es gibt zahlreiche Faktoren, die einen Einfluss auf den Bearbeitungsfortschritt in einem Sprint haben. Das Sprint Backlog zeigt unabhängig von diesen Faktoren bewertungsfrei den Fortschritt eines Sprints, um frühzeitig mögliche Verzögerungen analysieren und notwendige Gegenmaßnahmen einleiten zu können. Das Sprint Backlog ist somit ein Frühwarnsystem und dient nicht dazu, das Scrum Team zu kontrollieren. In der Praxis kommt es leider häufig vor, dass Projekt Stakeholder oder 66 5 Scrum Artefakte - Die Übersicht behalten Vorgesetzte die Transparenz des Sprint Backlogs missbrauchen, um auf einzelne Team‐ mitglieder oder das ganze Teams Druck aufbauen. An dieser Stelle ist der Scrum Master gefragt. Er muss erklären, welchen Zweck das Sprint Backlog erfüllt und warum hierfür Transparenz notwendig ist. Wenn sich die Situation anschließend nicht verändert, muss sich das Team überlegen, ob es zielführend wäre, Nicht-Teammitgliedern den Zugang zum Sprint Backlog zu verwehren. Ansonsten verkommt das Sprint Backlog zu einem Kontrollinstrument für die Messung der Arbeitsleistung der Teammitglieder, was dazu führen kann, dass die Fortschrittsmessung im Sprint Backlog geschönt wird und das Backlog somit nicht mehr sinnvoll vom Team verwendet werden kann (siehe hierzu auch Kapitel 7.3). 5.5 Produktinkrement - Herausforderung in der Umsetzung Auf unserem Scrum Rundgang halten wir kurz inne beim dritten und letzten Artefakt, dem Produktinkrement. Es besteht aus allen fertiggestellten Backlog-Einträgen, die der Definition of Done genügen. Dieses Artefakt ist älter als Scrum und die agilen Methoden verhalfen ihm zu neuem Glanz. Schauen wir zurück in die Blütezeit der Wasserfallprojekte, um den Nutzen dieses Artefakts besser zu verstehen. Damals wurden den Anwendern nach einer Projektlaufzeit von vielen Monaten oder mehreren Jahren ein umfangreiches Projektprodukt mit zahlreichen Funktionalitäten zur Verfügung gestellt. Die Nachteile dieser Vorgehensweise sind hinlänglich bekannt. Mit dem Produktinkrement stellt die agile Welt ein Alternativkonzept zur Verfügung. Anstatt in einem großen Projekt eine komplexe Lösung zu entwickeln, erhalten die Anwender nach jedem Sprint neue Produktfunktionalitäten; das Produkt wird also inkrementell entwickelt. Es ist die Summe aller Aufgaben, die in einem Sprint erledigt wurden. Zusätzlich enthält das Produktinkrement die Aufgaben aller vorherigen Sprints. Es ist potenziell auslieferbar. Das bedeutet, dass es immer einen Mehrwert für den Anwender liefern muss, auch dann, wenn es nicht ausgeliefert wird. So wird sichergestellt, dass das Scrum Team in jedem Sprint ein in sich abgeschlossenes, funktionsfähiges Teilprodukt erstellt (siehe Abbildung 33). 67 5.5 Produktinkrement - Herausforderung in der Umsetzung Sprint 1 Sprint 2 Sprint 3 Sprint 4 Auslieferung #1 Auslieferung #2a Auslieferung #3 Auslieferung #2b Figure 33: Potenziell auslieferbare Produktinkremente Abbildung 33: Potenziell auslieferbare Produktinkremente Wie viele Funktionalitäten dieses Inkrement zur Verfügung stellt, hängt vom Team und der Planung ab. Bei der Auswahl der richtigen Funktionen ist der Product Owner von entscheidender Bedeutung. Er muss entscheiden, welche Funktionen sich als ein Inkrement am besten vermarkten lassen und welche für die Zielgruppe (für den Kunden oder die Nutzer) einen echten Mehrwert liefern. Die mit dem inkrementellen Ansatz verbundenen Vorteile lassen sich beispielsweise griffig mit den Phrasen „kürzere Time-To-Market“, „gute Time-To-Value“, „optimierter Cash Flow“ oder „Fast-Custo‐ mer-Feedback“ beschreiben. Das ist gut zu wissen, wenn im nächsten Management Meeting über den Nutzen von Produktinkrementen gesprochen wird. Mit dem Scrum Guide 2020 wurde am Produktinkrement eine Anpassung vorge‐ nommen, die bei einigen Scrum Teams schon gelebte Realität war: Pro Sprint kann es mehrere Produktinkremente geben. Es muss also nicht mehr bis zum Ende eines Sprints mit der Auslieferung eines Produktinkrements gewartet werden. Wenn nur ein einzelnes Element nicht der Definition of Done entsprach, konnte ein gesamtes Inkrement mit all seinen Umsetzungen aus dem Sprint nicht abgenommen werden, als noch bis zum Sprintende gewartet werden musste. Stattdessen gilt nun: Jedes Mal, wenn ein Product Backlog Item die Definition of Done erfüllt, gibt es ein neues Produktinkrement. Diese Inkremente können also auch während eines Sprints abgenommen und potenziell ausgeliefert werden. Dadurch wird nicht nur eine konti‐ nuierliche Auslieferung ermöglicht, die Änderung führt hoffentlich auch dazu, dass das sogenannte Sprint Review nicht mehr als „Freigabe-Veranstaltung“ missinterpretiert wird. Ziel des Sprint Reviews ist es vielmehr, anhand der Prüfung der erstellten Produktinkremente Fehlentwicklungen des Produktes vorzubeugen und neue Impulse für das Product Backlog zu bekommen, um so die zukünftigen Sprintziele noch besser am Produktziel ausrichten zu können. 68 5 Scrum Artefakte - Die Übersicht behalten Eine wichtige Rolle spielt in diesem Zusammenhang die Definition of Done. Grundsätzlich ist die Definition of Done eine formale Beschreibung dessen, was zur Auslieferung des Inkrements benötigt wird beziehungsweise was erfüllt sein muss. Hiermit wird sicherstellt, dass jedes Inkrement die festgelegten Qualitätsstandards einhält. Die Definition of Done darf nicht mit den Abnahmekriterien verwechselt werden. Abnahmekriterien beschreiben Bedingungen, die erfüllt sein müssen, damit die Produktfunktionalitäten den Wünschen der Zielgruppe entsprechen. Sie sind daher nur eine Teilmenge der Definition of Done. Die Definition of Done wird vom Scrum Team erstellt. Wenn mehrere Scrum Teams gemeinsam an einem größeren Produkt arbeiten, wird die Definition of Done häufig teamübergreifend festgelegt. Es ist üblich, dass es neben einer allgemeinen Definition of Done, die alle Teams erfüllen müssen, zusätzlich individuelle Qualitätskriterien für die einzelnen Teams gibt. Unabhängig davon, ob eine einzelne oder eine kombinierte Definition of Done verwendet wird, müssen die umgesetzten User Stories alle darin enthaltenen Qualitätskriterien erfüllen. Ansonsten kommen sie am Sprintende zurück in das Product Backlog und werden gegebenenfalls im nächsten Sprint weiterberarbeitet. Diese Funktionalitäten werden also weder ausgeliefert noch im Sprint Review gezeigt. Berücksichtigt man alle vorherigen Ausführungen, kann eine Definition of Done maximal in vier Bereiche untergliedert werden: ■ Organisationsweite Definition of Done ■ Teamübergreifende Definition of Done ■ Teaminterne Definition of Done ■ Definition of Done für ein Inkrement Die organisationsweite Definition of Done enthält Qualitätsstandards, die für alle Projektteams einer Organisation gelten. Abbildung 34 zeigt ein paar Kriterien, die in einer solchen Definition of Done enthalten sind. Organisationsweite Definition of Done 1 Alle Tasks einer User Story sind abgeschlossen. 2 Alle Akzeptanzkriterien wurden erfüllt. 3 Die Dokumentationsrichtlinien wurden eingehalten. 4 Alle Sicherheitsrichtlinien wurden eingehalten. 5 Softwareentwicklungen wurden durch den Security-Verantwortlichen freigegeben. … Figure 34: Exemplarische Kriterien einer organisationsweiten Definition of Done Abbildung 34: Exemplarische Kriterien einer organisationsweiten Definition of Done 69 5.5 Produktinkrement - Herausforderung in der Umsetzung In der teamübergreifenden Definition of Done sind solche Kriterien enthalten, die für alle Teams, die gemeinsam an einem Produkt arbeiten, gelten. Abbildung 35 listet typische Qualitätskriterien auf. Teamübergreifende Definition of Done 1 Die Kriterien der organisationsweiten Definition of Done wurden erfüllt. 2 Das Ergebnis der User Story wurde nach dem Vier-Augen-Prinzip geprüft. 3 Die Dokumentation wurde im der Dokumentationsdatenbank gespeichert. 4 Bei Softwareentwicklungen wurde n die Programmierrichtlinien eingehalten. … Figure 35: Exemplarische Kriterien einer teamübergreifenden Definition of Done Abbildung 35: Exemplarische Kriterien einer teamübergreifenden Definition of Done In der teaminternen Definition of Done werden die teamübergreifenden Kriterien weiter präzisiert und gegebenenfalls strengere Maßstäbe angelegt. Abbildung 36 zeigt ausschnittsweise sechs teaminterne Qualitätsanforderungen. Teaminterne Definition of Done 1 Die Kriterien der organisationsweiten Definition of Done wurden erfüllt. 2 Die Kriterien der teamübergreifenden Definition of Done wurden erfüllt. 3 Bei Softwareentwicklungen wurde ein Code-Review durch einen zweiten Entwickler durchgeführt. 4 Bei Softwareentwicklungen wurden alle Unit-Tests erfolgreich abgeschlossen. 5 Alle Anwendertests wurden entsprechend der Testfälle erfolgreich durchgeführt. 6 Bei Softwareentwicklungen wurden alle Anwendertests automatisiert. … Figure 36: Exemplarische Kriterien einer teaminternen Definition of Done Abbildung 36: Exemplarische Kriterien einer teaminternen Definition of Done Schließlich kann sogar für ein Produktinkrement eine individuelle Definition of Done formuliert werden. Für eine solche finden Sie in Abbildung 37 ein paar exemplarische Kriterien. 70 5 Scrum Artefakte - Die Übersicht behalten Definition of Done für ein Inkrement 1 Die Kriterien der organisationsweiten Definition of Done wurden erfüllt. 2 Die Kriterien der teamübergreifenden Definition of Done wurden erfüllt. 3 Die Kriterien der teaminternen Definition of Done wurden erfüllt. 4 Bei Softwareentwicklungen wurde der Programm-Code vollständig integriert. 5 Die Hilfetexte stehen in allen unterstützten Sprachen zur Verfügung. 6 Das Wiki zum aktuellen Produktziel wurde erstellt bzw. erweitert. … Figure 37: Exemplarische Kriterien einer Definition of Done für ein Produktinkrement Abbildung 37: Exemplarische Kriterien einer Definition of Done für ein Produktinkrement Man kann eine mehrstufige Definition of Done in Form einer Vererbung darstellen (wie in Abbildung 34 bis Abbildung 37) oder immer alle relevanten Kriterien auflisten. Da es eine Checkliste ist, gegen die geprüft wird, ist es einfacher, wenn die Definition of Done für ein Inkrement alle Punkte enthält. Grundsätzlich gilt, dass die Definition of Done kein Kontrollinstrument ist, sondern dafür sorgen soll, dass keine wichtigen Punkte vergessen werden und eine qualitativ hochwertige Arbeit geliefert wird. Mit der Definition of Done schaffen Sie ein klares Verständnis darüber, wann eine User Story fertig ist. Es hängt also nicht von persön‐ lichen Einschätzungen ab, sondern von vereinbarten Kriterien, die alle erfüllt sein müssen. Damit die Definition of Done von allen verinnerlicht wird, sollte sie für alle Teammitglieder sichtbar an die Wand gehängt werden. Dann steigt das Commitment des Teams, die Kriterien zu erfüllen. Die Definition of Done ist keine statische Liste, sie ist vielmehr ein lebendes Dokument. Sie kann sich ändern, wenn zum Beispiel im Rahmen einer Sprint Retrospektive erkannt wird, dass Kriterien sinnlos sind oder gar fehlen. Bei der organisationsweiten Definition of Done (siehe Abbildung 34) könnte es zu einer Herausforderung werden, dass für ein Inkrement immer die formale Freigabe eines Security-Verantwortlichen erforderlich ist. Dies kann die Fertigstellung der Inkremente verzögern. Das Kriterium könnte deshalb dahingehend angepasst werden, dass nur noch geprüft werden muss, ob die User Stories alle Sicherheitsrichtlinien einhalten und keine Freigabe mehr benötigt wird. 5.6 Das Product Backlog und die Backlog Refinement-Aktivitäten Nachdem wir nun alle drei Artefakte näher betrachtet haben, gehen wir nochmals zurück zum Product Backlog und beschäftigen uns damit, wie dieses Artefakt gepflegt wird. Diese Pflege bezeichnet man auch als Product Backlog Refinement (auch Backlog Estimation oder Backlog Grooming). 71 5.6 Das Product Backlog und die Backlog Refinement-Aktivitäten Der Scrum Guide sagt hierzu: Das Refinement des Product Backlogs ist der Vorgang, durch den Product Backlog-Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren je nach Arbeitsumfeld. Was bedeutet das im praktischen Alltag? In erster Linie viel Arbeit. Das Backlog ist das zentrale Artefakt in agilen Projekten. Die bereits enthaltenen Product Backlog Items müssen ständig überprüft werden. Zudem werden regelmäßig neue Einträge hinzugefügt. Eine wöchentliche Aktualisierung vor dem nächsten Product Backlog Refinement reicht nicht aus, der Product Owner muss sich täglich mit dem Product Backlog beschäftigen. Typische Tätigkeiten in diesem Kontext sind … ■ … die Ergänzung neuer Epics, Features oder User Stories in das Product Backlog ■ … die Verfeinerung, Aufteilung und Zusammenfassung bereits vorhandener Epics, Features oder User Stories ■ … die Entfernung von nicht mehr relevanten Epics, Features oder User Stories ■ … die Diskussion der Akzeptanzkriterien ■ … die Identifikation möglicher Abhängigkeiten zwischen den Elementen ■ … die Überarbeitung der Aufwandsschätzungen ■ … die Umsortierung aufgrund von neu gewonnenen Erkenntnissen Auch wenn der Scrum Guide den Product Owner in der Verantwortung und die Entwickler in der Mitwirkung sieht, sind am Product Backlog Refinement mehrere Personen beteiligt. Typisch sind dabei Gruppen, die sich auf bestimmte Themen fokus‐ sieren oder es gibt teamübergreifende Anforderungsworkshops, in denen neue Product Backlog Items identifiziert werden. Das klingt nach Requirements Engineering, wie man es aus Projekten kennt, die nach dem klassischen Wasserfallmodell durchgeführt werden. Insbesondere alle Formen von Gruppenarbeit produzieren schnell einen großen, nicht mehr pflegbaren Produkt Backlog. Wie in Kapitel 5.2 diskutiert, sollte ein Product Backlog allerdings so klein wie möglich und so detailliert wie notwendig sein. Ausgerichtet ist es dabei immer am nächsten Ziel (zum Beispiel einem Produkt- oder Roadmap-Ziel). 72 5 Scrum Artefakte - Die Übersicht behalten User Story Product Backlog User Story User Story T a s k T a s k T a s k Sprint Backlog Epic / Feature Epic / Feature T a s k T a s k T a s k T a s k T a s k T a s k Initiative Figure 38: Epics, Features und User Stories im Product Backlog Abbildung 38: Epics, Features und User Stories im Product Backlog Wie Sie bereits erfahren haben, sollten nur so viele User Stories existieren, wie für die nächsten paar Sprints notwendig sind. Mehr User Stories als für das nächste Ziel nötig sollten es nicht sein. Zudem sollte dieses Ziel nicht weiter als drei bis vier Monate in der Zukunft liegen. Zu viele User Stories machen das Product Backlog nicht nur unübersichtlich, sie erzeugen auch unnötige Arbeit. Ein Product Backlog mit über 100 User Stories für ein Team, das im Schnitt zehn User Stories pro Sprint bearbeitet, ist zu groß und sollte aufgeräumt werden. 5.6.1 Die drei Stufen der Detailierung In der Praxis hat sich ein dreistufiger Detaillierungsgrad im Product Backlog bewehrt (siehe Abbildung 39). 73 5.6 Das Product Backlog und die Backlog Refinement-Aktivitäten N e u Ü b e r p r ü f e n B e r e i t Backlog Refinement • Nicht alle Informationen liegen vor • Keine Vorstellung gegenüber dem Team • Nicht alle Informationen liegen vor • Keine Vorstellung gegenüber dem Team • Enthält alle relevanten Informationen für eine Vorstellung • Team überprüft und verfeinert • Enthält alle relevanten Informationen für eine Vorstellung • Team überprüft und verfeinert • Alle Informationen liegen vor, um mit der Entwicklung zu starten • Es gibt keine Blocker • Alle Informationen liegen vor, um mit der Entwicklung zu starten • Es gibt keine Blocker Neu Neu Überprüfung Überprüfung Bereit Bereit Figure 39: Backlog Refinement mittels dreistufigem Detailierungsprozess Abbildung 39: Backlog Refinement mit dreistufigem Detaillierungsprozess 74 5 Scrum Artefakte - Die Übersicht behalten Wird ein neues Element erstellt, hat es den Detailgrad „neu“. Für Elemente in diesem Stadium liegen häufig noch nicht alle notwendigen Information vor und es ist wahr‐ scheinlich, dass der Product Owner noch Ergänzungen vornehmen wird. Es ist daher zu früh, das Element dem Team vorzustellen. Sind alle Informationen vorhanden, wird der Status auf „Prüfung“ geändert und das Element wird dem Team vorgestellt. Es prüft das Product Backlog Item und nimmt gegebenenfalls Verfeinerungen vor. Anschließend wird der Status auf „bereit“ gesetzt, das Element kann nun bearbeitet werden. Ein wesentlicher Vorteil dieser Dreiteilung besteht darin, dass bei der Prüfung des Backlogs keine Elemente diskutiert werden, für die noch Informationen fehlen und Elemente, die bereits im Detail behandelt wurden, werden nicht mehr besprochen. Gleichzeitig ist das kein Freibrief, um User Stories für ein Jahr im Voraus zu erstellen. Man kann nicht wissen, welches Feature in zwölf Monaten wirklich relevant ist und der Zielgruppe einen echten Mehrwert liefert. Hinzu kommt, dass der Inhalt von Elementen, die zu lange im Status „bereit“ verharren, in Vergessenheit gerät und erneuter Diskussionsbedarf und Abstimmungsaufwand entsteht. Für die User Stories haben sich folgende Größenordnungen bewährt: Mit dem De‐ tailgrad „bereit“ sollten User Stories für circa zwei Sprints verfügbar sein. Dann hat man im Sprint Planning genügend Auswahlmöglichkeiten und kann auch Urlaubszeiten, in denen weniger neue User Stories verfeinert werden, leicht überbrücken. Für circa ein bis zwei Sprints sollten Sie die Stories in den Detailgrad „Prüfung“ setzen. Mit dem Detailgrad „neu“ sollten User Stories für einen Sprint vorhanden sein. Für die Strukturelemente oberhalb der Stories gilt das nicht unbedingt. In den Kapiteln 5.2 und 5.3 finden Sie weiterführende Informationen zu diesen Strukturierungselementen sowie eine Prozessbeschreibung für den Aufbau des Product Backlogs. 5.6.2 User Stories, Tasks und deren Schätzung Nun schauen wir uns das Zusammenspiel der beiden unteren Strukturebenen an, die für das Sprint Backlog und die Sprintplanung relevant sind. Hierbei handelt es sich um User Stories und Tasks, wobei die Tasks nur die zu den User Stories gehörenden Arbeitspakte repräsentieren (siehe Abbildung 40). 75 5.6 Das Product Backlog und die Backlog Refinement-Aktivitäten User Story Product Backlog User Story User Story T a s k T a s k T a s k Sprint Backlog Epic / Feature Epic / Feature T a s k T a s k T a s k T a s k T a s k T a s k Initiative Figure 40: User Stories und Tasks im Sprint Backlog Abbildung 40: User Stories und Tasks im Sprint Backlog Da alle Strukturelemente oberhalb der User Story länger als einen Sprint benötigen, erstellen Sie die Sprintplanung auf der Ebene der User Stories und den dazugehörigen Tasks. User Stories dürfen daher maximal so groß sein, dass man sie in einem Sprint erledigen kann. Manchmal ist es deshalb notwendig, eine User Story in mehrere aufzuteilen. Es gibt unterschiedliche Empfehlungen, wie man dieses Story Splitting am besten bewerkstelligt. Einige der wichtigsten Punkte dieser „Patterns for Splitting User Stories“ werden wir später noch genauer betrachten. Grundsätzlich sollten für einen Sprint nur User Stories ausgewählt werden, die zum nächsten Roadmap- oder zum nächsten Produktziel gehören und davon nur diejenigen, die für die Erreichung des Sprintziels wirklich benötigt werden. Es geht also nicht darum, „so viel wie möglich“, sondern nur „so viel wie nötig“ umzusetzen. Gleichzeitig sollen die User Stories den höchsten Wertbeitrag für das Produktinkrement liefern. Was zeichnet eine geeignete User Story aus, um diesem Anspruch gerecht zu werden? Dazu schauen wir uns den Zweck und den Aufbau einer User Story an. Eine User Story ist eine in Alltagssprache beschriebene Anforderung. Sie sollte sich auf das Wesentliche konzentrieren und leicht verständlich sein. Das erreicht man mit einfachen Satzkonstruktionen. Mehrdeutige Begriffe sollten in einer User Story nicht verwendet werden. Üblicherweise werden sie mit den drei W-Fragen formuliert: „Wer“ möchte „was“ und „warum/ wozu“? Im Englischen verwendet man in der Regel die Vorlage „As a <role> I want <function> so that <benefit>“: 76 5 Scrum Artefakte - Die Übersicht behalten ■ <role>: Wer fordert etwas? Der Anforderer ist häufig die Zielgruppe des Produkts. ■ <function>: Was wünscht sich der Anforderer? Je präziser der Wunsch formuliert ist, desto einfacher ist es für die die Entwickler, diese Anforderung umzusetzen. ■ <benefit>: Welchen Nutzen erhofft sich der Anforderer mit der Umsetzung? Diese Beschreibung liefert den Entwicklern weitere Informationen, die sie für die Implementierung benötigen. In der Praxis führt die Verwendung dieser Vorlagen oft zu merkwürdigen Stilblüten oder zu Standardformulierungen, welche die Anforderungen nur unzureichend wieder‐ geben. Das führt dann dazu, dass die User Stories alle gleich aussehen und die wirklich wichtigen Informationen in den Notizen, Kommentaren oder den Akzeptanzkriterien versteckt werden. Die Akzeptanzkriterien kommen überwiegend vom Product Owner und beschreiben, welche Punkte erfüllt sein müssen, damit User Stories die an sie gestellten Erwartungen erfüllen. Abbildung 41 zeigt eine typische Vorlage für die Formulierung von User Stories. <P> User Story <Bezeichnung> <S> User Story ist fertig, wenn folgende Kriterien erfüllt sind: Akzeptanzkriterium #1 Akzeptanzkriterium #2 Akzeptanzkriterium #3 Ich als: <role> möchte: <function> um: <benefit> Priorität Story Points Figure 41: Typische Vorlage für User Stories Abbildung 41: Typische Vorlage für User Stories Problematisch wird es, wenn User Stories für nichtfunktionale Anforderungen erstellt werden. Diese User Stories werden meistens von technischen Experten verfasst und sie beschreiben oft schon die Lösung. (Beispiel: „Definition eines zusätzlichen Tabellenin‐ 77 5.6 Das Product Backlog und die Backlog Refinement-Aktivitäten dizes ZZZ mit den Schlüsselfeldern A und B, um die Performance beim Lesevorgang auf der Datenbanktabelle XXX zu verbessern“) Ist dies wirklich die beste Lösung und werden die Entwickler, die diese User Story umsetzen, mit solchen Formulierungen nicht in eine falsche Richtung geschickt? Beispiele für wirkungslose User Stories gibt es häufig in Bezug auf Anforderungen, welche die Benutzeroberflächen von Softwarelösungen betreffen. Hier findet man sol‐ che Formulierungen: „Als Product Owner möchte ich, dass die Benutzeroberfläche für die Anzeige der Artikelstammdaten übersichtlicher wird, damit ich schneller erkennen kann, welche Artikel aktuell verfügbar sind.“ Hierbei soll folgendes Akzeptanzkrite‐ rium gelten: „Die Artikelnummer soll gelb unterlegt werden, wenn der Artikel nicht vorrätig ist.“ Das ist eine unklare Anforderung, denn „Übersichtlichkeit“ ist subjektiv und gibt es nicht eine bessere Möglichkeit, um die Verfügbarkeit der Artikel zu prüfen? Hinzu kommt, dass das Abnahmekriterium keinen Bezug zur Übersichtlichkeit hat. Wie Sie an den beiden Negativbeispielen erkennen können, ist die Erstellung von User Stories mit Stolperfallen versehen. Die Vorlagen helfen oft nur bedingt bei der praktischen Umsetzung. Insbesondere bei nichtfunktionalen Anforderungen sind Szenario-Beschreibungen häufig besser, um die Herausforderung zu erfassen, die mit einer User Story gelöst werden soll. Mit einer sinnvollen Strukturierung des Product Backlogs haben Sie schon eine gute Voraussetzung für die Formulierung der User Stories geschaffen. Setzen Sie sich anschließend mit den höheren Strukturebenen auseinander, damit das Backlog sinnvoll mit Stories befüllt werden kann und nicht versehentlich eine bloße Aneinanderreihung entsteht. Das würde dazu führen, dass User Stories entstehen, die nicht innerhalb eines Sprints bearbeitet werden können. Häufig wird dann die Flucht nach vorn angetreten, indem zu große User Stories einfach geteilt werden, ohne großartig den Text, den Business Value oder die Akzeptanzkriterien zu ändern. Das führt dazu, dass die User Stories kein eigenständiges Inkrement beziehungsweise kein Bestandteil eines Inkre‐ ments sind. Die geteilten User Stories sind nur gemeinsam funktionsfähig. Die Erste enthält zum Beispiel die Spezifikation einer Software-Anforderung und die erste Hälfte der Entwicklungsarbeiten. In der zweiten Story ist die zweite Entwicklungshälfte und das Testen enthalten. Das ist auch zu beobachten, wenn User Stories direkt voneinander abhängig sind und nur gemeinsam ein Inkrement ergeben. Ein typisches Beispiel hierfür ist die Dreiteilung in Datenbankentwicklung, Implementierung der Anwendungslogik und Erstellung der grafischen Benutzeroberfläche. Wenn hierfür drei User Stories erstellt und über drei Sprints verteilt werden, wird in den ersten beiden Sprints kein Business Value generiert. Wenn schon User Stories als primäre Elemente im Product Backlog verwendet werden, sollten zumindest die Tasks die einzelnen Schritte auf dem Weg zur Erfüllung der User Story beschreiben und konkret abgeschätzt werden. Die Empfehlung aus der Praxis ist, keine Story Points für die Aufwandsschätzung der Tasks zu verwenden, auch wenn das vermutlich schneller gehen würde. Den Aufwand der Tasks auf Stundenbasis 78 5 Scrum Artefakte - Die Übersicht behalten zu kalkulieren ist zielgerichteter. Wenn es nämlich heißt „Ich weiß nicht, wie viele Stunden ich dafür brauche.“, wird die User Story sehr wahrscheinlich nicht fertig. 5.6.3 Das Orakel und die Story Points Auf der Liste der umstrittensten Scrum-Themen nehmen Story Points einen der vorde‐ ren Plätze ein. Obwohl Story Points im Scrum Guide nicht erwähnt werden, findet man sie im Werkzeugkasten der meisten Scrum Teams. Zur Erinnerung, Story Points sollen die Größe einer User Story beschreiben und dabei alle Faktoren berücksichtigen, die den Umsetzungsaufwand beeinflussen können. Hierzu gehören beispielsweise Komplexität und Risiko. Es ist also eine abstrakte Zahl, die alles in sich vereint. Als Story Points werden in der Regel Werte verwendet, die sich an der Fibonacci-Folge orientieren (1, 2, 3, 5, 8, 13, 21, 34, 55, 89 usw.). Hiermit sollen zwei Aspekte zum Ausdruck gebracht werden: Erstens lässt die Schätzgenauigkeit bei größerem Implementierungsaufwand, bei steigender Komplexität und bei höherem Risiko nach. Zweitens geht es bei Story Points um relative Werte. Eine User Story mit fünf Story Points soll also fünfmal so groß sein wie eine User Story mit einem Story Point. Wenn die Sprint Velocity in Story Points gemessen wird, soll dargestellt werden, wie viele Story Points in einem Sprint bearbeitet werden können, die Planung kann sich anschließend daran anlehnen. Es wird also immer in Relation zu einer gegebenen Referenzstory geschätzt und wie hoch der Aufwand im Vergleich ist. Die Triangulation erleichtert das Schätzen. Dabei werden die zu schätzenden User Stories mit zwei unterschiedlich großen Referenzstories verglichen. Die erste User Story hat beispielsweise einen Story Point und die zweite Story zehn Points. Beim Vergleich mit zwei Referenzen fällt vielen Menschen das Schätzen leichter. Den Story Points wird gelegentlich unterstellt, gute Planungsgrößen zu sein. Als Argument dafür wird angeführt, dass Story Points besser sind als Personentage, da mit diesen ein Bewusstsein dafür geschaffen wird, dass es sich um Schätzwerte und keine verbindlichen Aufwandsangaben handelt, für die das Scrum Team Rechenschaft ablegen muss. Größe, Komplexität, Risiko und Implementierungsdauer mit einer einzigen Kenngröße abzubilden, ist fast unmöglich. Die Aussagekraft der Story Points, die für eine User Story geschätzt werden, ist gering. Wenn Sie dennoch nicht auf Schätzwerte verzichten möchten, ist es empfehlenswert, maximal die ersten sieben Werte aus der Fibonacci-Folge für die Schätzungen zu verwenden: 1, 2, 3, 5, 8, 13 und 21. Die 21 besagt dann, dass eine User Story zu groß für einen einzelnen Sprint ist und nochmal genauer untersucht werden muss. Beliebt zur Angabe der Schätzung ist die Verwendung von T-Shirt-Größen wie S, M, L, XL und XXL. Wieder andere Teams verwenden nur drei Kategorien: ■ Kategorie 1: User Story kann sehr wahrscheinlich (mit geringem Risiko) in einem Sprint erledigt werden. ■ Kategorie 2: User Story kann vermutlich (unter mittelgroßem Risiko) in einem Sprint erledigt werden. 79 5.6 Das Product Backlog und die Backlog Refinement-Aktivitäten ■ Kategorie 3: User Story kann vielleicht (unter hohem Risiko) in einem Sprint erledigt werden. Es wird jedoch vermutlich mehr Aufwand benötigt. Zwei volle Sprints sind dennoch nicht notwendig. Natürlich gibt es auch Teams, die anstelle von Story Points weiterhin Personentage benutzen. Egal, ob Sie eine Bewertung in Story Points oder auf Basis von Zeiteinheiten machen, es ist und bleibt ein schwieriges Unterfangen. Keine Schätzungen abzugeben ist derweil auch keine Lösung, da kalkuliert werden muss, was in einem Sprint alles erledigt werden kann. 5.6.4 Die Analyse als Allheilmittel vor der Planung Sehr beliebt in vielen agilen Teams ist, die für den letzten Sprint geplanten User Stories durchzugehen und auf mögliche Verbesserungen zu untersuchen. Für diese User Stories wird in der Retrospektive diskutiert, ob die Umsetzung gut oder schlecht gelaufen ist. War die Umsetzung nicht gut, werden Vorschläge gesammelt, was das Team in Zukunft besser machen kann. Die einfachste und einzige Lösung, sich mit dem Thema ausreichend auseinander‐ zusetzen, scheint bei vielen Teams immer wieder zu sein, dass Analyse-User Stories benötigt werden, damit das Problem und damit der Aufwand deutlicher wird. Ein typisches Verhalten, welches das Risiko birgt, auf eine falsche Fährte zu führen. Am Ende wird in einem Sprint immer die Analyse-User Story erstellt. Darin enthalten erfolgt die Abschätzung zum Aufwand einer Umsetzungs-User Story. In einem zweiten Sprint erfolgt anschließend die Umsetzung. Eine weitere mögliche Variante sind zwei oder mehrere neue User Stories, die in verschiedenen Sprints umgesetzt werden. Erst wenn alle Stories einer Serie umgesetzt wurden, wird die Analyse Teil des Inkrements. Dieses Vorgehen ist nicht empfehlenswert. Analyse-User Stories stellen die Teammitglieder vor folgende Herausforderungen: Sie produzieren keinen Mehrwert, erzeugen also keinen Business Value. Es ist nahezu unmöglich, alle späteren Einflussgrößen im Vorfeld zu erkennen. Tiefergehende Erkenntnisse ergeben sich in der Regel erst während der Entwicklung. Wenn jedoch eine solche User Story zu einer Entscheidungsfindung, zu einem Wissensgewinn führt oder dazu beiträgt, hätte sie durchaus einen Mehrwert - wer will schon Geld für etwas ausgeben, das nicht funktioniert, zu lange dauert oder zu teuer wird? Diese Punkte sind in die Überlegung einzubeziehen. Vorausschauender wäre es jedoch, wenn die Gedanken zu den zuvor genannten Aspekten bereits vorher auf einer höheren Ebene der Anforderung Form annehmen. Sicher wird es auch im Nachhinein hin und wieder notwendig, ein Thema später noch näher zu analysieren, da sich manches nicht in den Gruppen oder durch Gespräche aufklären lässt oder die Erfahrung noch nicht vorhanden ist. 80 5 Scrum Artefakte - Die Übersicht behalten Spike Spike-unabhängige Arbeit Regulärer Sprint Regulärer Sprint A u f w a n d Spike Figure 42: Regulärer Sprint versus Spike Abbildung 42: Regulärer Sprint versus Spike Dieses Vorgehen wird Spike genannt. Ein Spike entsteht, wenn eine User Story oder ein Task nur genau eingeschätzt werden kann, nachdem zusätzliche Recherchen durchgeführt wurden. Ein Spike sollte immer eine Ausnahme sein und nicht zur Regel werden. Er dient dazu, die grundlegende Durchführbarkeit einer Anforderung (funktional oder nichtfunktional) zu ermitteln und, sofern eine Umsetzung möglich ist, die Planung zu verbessern und das Risiko bei der Umsetzung zu verringern. Es geht also nicht darum, neue Funktionalitäten für das Produktelement umzusetzen. Am Ende entstehen oft neue User Stories, welche die Umsetzung genau beschreiben. Spikes zählen nicht zu den echten Scrum Elementen. In der Praxis werden sie dennoch gerne verwendet. Sie funktionieren am besten, wenn sie auf Strukturebenen oberhalb der User Stories eingesetzt werden und zum Beispiel Teil einer Epic oder sogar eigene Epics mit entsprechenden „Spike User Stories“ sind. Ein Spike kann auch als Mittel für Experimente genutzt werden, die in ein Mockup, einen Prototyp oder ein Design Concept münden. Ein wesentliches Charakteristikum von Spikes ist, dass sie keinen Wert erzeugen und keine Aufwandsschätzung enthalten. Das Team hat nicht genügend Kenntnisse, um das Thema zu beurteilen. Es besteht daher das Risiko, dass am Ende eines Spikes kein Ergebnis erzeugt wurde. Zudem gibt es nicht einmal eine Vorgabe, wie lange ein Spike dauern darf. Wie viel Zeit sollte man daher einem Spike einräumen? Wünschenswert sind kurze Zeitfenster. Ein, maximal zwei Sprints sollten dafür genutzt werden. Diese Fragestellung verhält sich ähnlich zu den Überlegungen für die User Stories. Entscheiden Sie sich für eine der vier folgenden Optionen, wenn Sie ein Spike bewerten: 81 5.6 Das Product Backlog und die Backlog Refinement-Aktivitäten ■ Spike mit geringem Risiko: Spike kann sehr wahrscheinlich in einem Sprint erledigt werden. ■ Spike mit mittlerem Risiko: Spike kann vermutlich in einen Sprint erledigt werden. ■ Spike mit hohem Risiko: Spike benötigt vermutlich etwas länger als einen Sprint, aber vermutlich weniger als einen Monat. (Bei einer Sprintlänge von vier Wochen wären das vermutlich zwei Monate.) ■ Spike mit sehr hohem Risiko: Spike wird mehr als einen Sprint benötigen. (Bei Sprints mit einer Länge von vier Wochen wären das zwei Monate.) Wenn ein Spike mehr als einen Sprint benötigt (Spikes mit hohem oder sehr hohem Risiko), ist es ratsam, die Ziele, die damit verfolgt werden, nochmal unter die Lupe zu nehmen. Versuchen Sie, die Ziele und die Akzeptanzkriterien auf mehrere Spikes herunterzubrechen. Wenn dies nicht erfolgreich ist, stellen Sie den gesamten Spike in Frage. Es ist in der Regel nicht sinnvoll, während des ersten Sprints zu prüfen, ob eine Unterteilung in weitere Spike User Stories erforderlich ist, die dann gegebenenfalls in einem zusätzlichen Sprint erledigt werden müssten. Das ist nur dann akzeptabel, wenn sich dadurch an der Zeitplanung des Spikes nichts ändert. Dann führt es dazu, dass ein Spike aufgeteilt und verlängert wird. Wenn von vornherein klar ist, dass der Spike länger als einen Sprint dauert, sollte dieser auf Epic- oder Feature-Ebene geplant werden. Gliedern Sie in dem Fall den Spike in zugehörige User Stories auf, die in einen Sprint passen. An diesem Punkt bleibt die Frage, wie mit den Kapazitäten derer umzugehen ist, die sich des Themas annehmen. Da der notwendige Aufwand nicht zu beurteilen ist, hilft es, ein festes Enddatum für einen Spike einzusetzen und sich nicht auf die bloße Hoffnung zu stützen, dass der Spike eventuell in nur einer Sprintwoche abgeschlossen ist. Beträgt die Sprintlänge zum Beispiel drei Wochen, könnte der Spike für die letzte Woche geplant werden. Wenn im Rahmen der Sprintplanung die Kapazität auf Stunden pro Tag festgelegt wird, kann anhand des Enddatums leichter bestimmt werden, wie viel Restkapazität für andere Aufgaben noch zur Verfügung steht. Es verlangt einiges an Disziplin, einen Spike bis zu einem Termin oder nur über eine beschränkte Dauer zu bearbeiten und unter Umständen zu akzeptieren, nicht vollumfänglich über ein Thema informiert zu sein. Umso bedeutender werden die Kriterien, anhand derer ein Spike als erfolgreich oder nicht erfolgreich bewertet wird und, ob daraus Erkenntnisse gewonnen wurden, die zum Beispiel die Entscheidung über das weitere Vorgehen erleichtern. Am Ende sollte ein Spike immer dokumentiert werden, auch wenn es sich um einen Design- oder einen Architektur-Spike handelt. Hin und wieder werden Spikes auch als elementarer Bestandteil der User Story angesehen. Der Spike ist dann als ein Task der User Story eingebunden oder, anders gesagt, ein „Analyse-Task“. Dieser stellt die erste Aufgabe in einer User Story dar, noch vor der Spezifikation oder der Implementierung. Nachteilig ist, dass dafür die anderen Tasks der User Story nicht geschätzt werden, solange der Spike nicht abgeschlossen ist. Eine Taskplanung anhand der Teamkapazitäten ist nicht mehr möglich und es bleibt nur eine Planung auf Basis einer User Story Schätzung. 82 5 Scrum Artefakte - Die Übersicht behalten 5.6.5 Business Value im Backlog Refinement Zu den schwierigsten Aufgaben gehören die Wertermittlung für eine Anforderung und die Entscheidung, auf welcher Ebene der Wert ermittelt werden sollte. Dazu gibt es in den vorigen Kapiteln bereits einige Hinweise. Der Product Owner hat die Aufgabe, den Wert des Produktes zu maximieren. Dabei soll der Wert anhand der Elemente im Backlog erkennbar sein, damit entschieden werden kann, was in welcher Reihenfolge umzusetzen ist - sowohl in Hinsicht auf die Ziele als auch in einem Sprint. So weit so gut. Das ist jedoch alles andere als einfach. Starten wir mit der leichten Frage: „Welche Art von Wert bringt die Anforderung? “. Dazu gehören beispielsweise Umsatzsteigerung oder Kostenersparnis, aber auch schwer zu beziffernde Werte wie Kundenzufriedenheit oder Verlängerung der Nutzungsdauer. In vielen Fällen werden drei bis vier Wertkategorien verwendet (siehe beispielsweise Abbildung 43). • Gesetzliche Vorschriften • Vertragsregelverletzungen • Systemverfügbarkeit • … • Günstigere Systemlandschaft • Automatisierung von Prozessen • Zeitersparnisse durch einfache Bedienung • ... • Systemstabilität • Performance • Datenqualität • … • Höhere Reichweite des Produktes • Erschließung neuer Märkte • Informationsvorsprung • … Umsatzsteigerung Vermeidung von Umsatzverlusten Kostenvermeidung Kostenreduzierung Figure 43: Beispiel Business Value Kategorien Abbildung 43: Beispiel Business Value Kategorien Es ist nicht ungewöhnlich, dass eine Anforderung mehrere Wertkategorien bedient. Wenn die Softwarelösung, mit der die Anforderungen erfasst werden, dies nicht unterstützt, könnte die Kategorien in einem Kommentarfeld vermerkt werden. Der Wert der Anforderung sollte erkennbar sein. 5.6.6 Das Business Value-Trilemma Nachdem die Art des Wertes festgelegt wurde, muss der Wert ermittelt werden. Ausgehend von der Anforderung „Wertmaximierung“ gelten folgende Annahmen: ■ Alle Anforderungen sind für ein Ziel bekannt und im Wert abschätzbar. ■ Was hat welchen Wert für wen ist immer bekannt und eindeutig bewertbar. ■ Die Anforderungen im Backlog werden anhand des Wertes priorisiert und sortiert. 83 5.6 Das Product Backlog und die Backlog Refinement-Aktivitäten So viel zur Theorie. In der Praxis fällt Folgendes vermutlich schnell auf: ■ Zu Beginn sind nicht alle Anforderungen im Detail bekannt, daher kann der Wert einer Anforderung nicht oder nicht vollständig bestimmt werden ■ Was einem Anwender als hoher Wert in Bezug auf die Nutzung erscheint, kann im absoluten Vergleich zu anderen Nutzungsbereichen wenig sein. Wenn zum Beispiel mit einer Anforderung in Land A der Umsatz um zwei Euro je Download gesteigert werden kann, im Monat jedoch nur 200 Downloads erfolgen, während eine Anforderung für Land B den Umsatz zwar nur um einen Euro je Download steigert, aber dafür über 5.000 Downloads pro Monat erzeugt, wird vermutlich jeder die Anforderung von Land B bevorzugen. Das könnte auch für weitere Anforderungen gelten und letztlich dazu führen, dass das Land A kaum oder nur sehr spät Anforderungen umgesetzt bekommt, wodurch möglicherweise ein gesamter Markt verloren geht. Anhand dieses Beispiels wird ersichtlich, dass so große Unterschiede zwischen den relativen und den absoluten Werten bestehen, die eine Beurteilung eines Wertes erschweren oder sogar verhindern. ■ Anforderungen sollen nach dem höchsten Wert sortiert und priorisiert werden, jedoch ist genau dieser Wert nicht vollständig bekannt oder nicht bewertbar. Eine Lösung dieses Problems ist auf Ebene der User Stories nicht möglich. Vielmehr ist bereits eine Klärung auf höheren Strukturebenen (Initiativen, Epics oder Features) notwendig. Über den sich daraus ergebenden Gesamtwert erfolgt anschließend die Sortierung und Priorisierung. Diese Handhabung wird das Problem vermutlich auch nicht vollständig auflösen können, die zuvor genannten Punkte werden so aber besser berücksichtigt als auf der Ebene der User Stories. Gleichzeitig wird es zu Differenzen zwischen den ermittelten Werten auf zum Beispiel der Ebene Epics oder Features und den zugeordneten User Stories mit den einzelnen Business Values geben. Beispiel eines Features durch die Anzahl der User Stories teilen: Auch das ist noch nicht des Rätsels finale Lösung. Die Anzahl der User Stories ist zu Beginn noch unbekannt oder zumindest nicht final determiniert. Würden Sie diesen Weg wählen, bedarf der Wert des Features einer Erhöhung oder der Wert anderer User Stories muss gesenkt werden. Solche Differenzen sind in der Praxis sogar akzeptabel, zumal sich im agilen Vorgehen Dinge ändern können - auch der Business Value. Es ist daher normal, dass der geplante Wert auf Ebene von Initiativen, Epics oder Features durch die Summe der Werte auf Basis von User Stories entweder nicht erreicht oder übertroffen wird. Es ist also nicht das Ziel, den Wert der User Stories an den übergeordneten Ebenen auszurichten, sondern jede User Story einzeln zu bewerten. Dabei sind erneut nur die nächsten Ziele mit den zugehörigen User Stories von Bedeutung. Einen Ausblick über den gesamten Wert einer Entwicklung erfolgt auf Basis übergeordneter Strukturele‐ mente - zum nächsten Ziel kann dieses gegebenenfalls bereits anhand der User Stories erfolgen. Im Rahmen des Business Value-Ausblicks je Einzelziel auf Ebene der User Stories werden vermutlich drei Dinge auffallen: 84 5 Scrum Artefakte - Die Übersicht behalten ■ Je Ziel gibt es nur sehr wenige, wirklich „wertvolle“ User Stories ■ Die wenigen User Stories mit dem höchsten Business Value können nicht zuerst produziert werden, weil diese häufig von weniger wertvollen Stories abhängen ■ Nachdem die wertvollsten User Stories abgeschlossen wurden, bleiben noch sehr viele über, die jedoch den größten Anteil der gesamten Umsetzungszeit benötigen Diese Punkte führen zu den weiteren Überlegungen, was wirklich benötigt wird, um ein Ziel zu erreichen. Sicher gehören die wertvollen User Stories dazu, genauso wie dieje‐ nigen, die dazu führen, dass die wertvollen Anforderungen umgesetzt werden können, gleichzeitig verbleibt die Frage, ab wann ein Ziel als erreicht gilt. Ganz klassisch wird gerne das Pareto-Prinzip (besser bekannt unter der 80: 20 Regel) herangezogen, um nach circa 80 % des erreichten Business Values ein Ziel als erreicht darzustellen. Vor allem, wenn der Wert bereits nach 20 % der vermutlich benötigten Zeit für alle User Stories erreicht wurde. Pauschal kann diese Methode jedoch nicht angewendet werden, denn es gibt Aufgaben, für die reicht eine 80-prozentige Erledigung eben nicht aus. Vielleicht könnten 80 % des Wertes erreicht sein, wenn eine Nutzung einer Zahlungsmaske des Produktes fertig ist, aber in den letzten 20 % befindet sich die Verschlüsselung der Zahlungsdaten. Das Ziel kann in diesem Beispiel nicht als vollständig erreicht betrachtet werden, solange elementare Teile fehlen. Es kommt also primär auf das Ziel in Verbindung mit den dafür benötigten Features an, um zu entscheiden, ob ein Ziel erreicht wurde oder nicht. Daher sind die Abnahmekriterien immer wieder von entscheidender Bedeutung; in unserem Beispiel nicht auf der Ebene der User Stories, sondern auf den darüber liegenden Ebenen. Es ist ratsam, alle ermittelten Werte als monetäre Angaben vorzugeben und nicht als abstrakte Größen, wie zum Beispiel die Kleidergrößen S, M, L oder XL. Oft sind Werte nicht einfach zu ermitteln. Es kann schnell die Frage aufkommen, welchen mo‐ netären Unterschied eine größere Reichweite eines Produktes (zum Beispiel aufgrund von Downloads) über einen bestimmten Zeitraum macht. Genau diese Frage sollte beantwortet werden können. Marktanteile bedeuten immer einen Vorteil, der sich auch beziffern lässt. Das wird zwar nicht das Problem zwischen relativen und absoluten Werten klären, dass zuvor betrachtet wurde, aber die Angabe von abstrakten Werten ist nur eine scheinbare Lösung. Um das Beispiel mit Anforderungen von Land A und B nur diesmal mit T-Shirt Business Value aufzugreifen, würde es aus Land A heißen, die Anforderung hat einen XL-Wert. Die gleiche Aussage kommt aus Land B. Das Problem des relativen Wertes wird damit umgangen und beide Anforderungen sind gleich bewertet, also gleichermaßen wichtig. Damit erfolgt keine Bevorzugung eines Landes. Am Ende kann aber nicht ermittelt werden, welcher Wert erzeugt wurde. Um den Wert doch noch bestimmen zu können, werden Hilfstabellen erstellt, die pro Land einen Wertebereich pro T-Shirt-Größe ausweisen. Anhand dieser Tabelle erfolgt die Umrechnung auf den absoluten Wertebereich. Dieses Vorgehen erzielt jedoch nur ungenaue Ergebnisse und ist umständlich in der Handhabung. Es zeigt gleichzeitig, dass ein sehr striktes Festhalten an Vorgaben nicht immer zum Ziel führt. In dem Beispiel mit den Ländern ist es meist hilfreicher, eine Art Kapazitätskontingent pro 85 5.6 Das Product Backlog und die Backlog Refinement-Aktivitäten Land zu nutzen, worin wiederrum die wertvollsten Anforderungen in der Reihenfolge nach dem absoluten Wert umgesetzt werden - immer unter Berücksichtigung von Abhängigkeiten und Risiken. Die absoluten Werte aus allen Kategorien sind zudem so zu bewerten, dass für alle der gleiche Zeitraum der Wertschöpfung zu Grunde liegt. Wenn also im Jahr eine Million Euro Umsatzplus erreicht werden kann und die Kosteneinsparung (zum Beispiel Zeitersparnis bei Mitarbeitern) auf Tagesbasis ermittelt wird, können diese beiden verschiedenen Werte nicht in Relation zueinander gesetzt werden. Bei einem Umsatzplus von einem Euro pro Jahr stellt sich die Frage, in wie vielen Jahren dieses erzielt wird oder ob es ein sich abschwächenden Effekt über die Jahre ist. In Bezug auf Kosteneinsparung verhält es sich sehr ähnlich. Welcher Wert nun der richtige für eine User Story ist, kann mit einer einzelnen Zahl nicht ausreichend beantwortet werden. Ab hier kommen die Business Cases zum Einsatz, die alle Effekte über die Zeit berücksichtigen sollten. Am Ende beantwortet also ein Wert aus dem Business Case die Frage nach monetären Unterschieden. Auf der Ebene der User Stories werden jedoch eher selten Business Cases formuliert. Diese befinden sich in der Regel auf der Ebene der übergeordneten Elemente. Demnach bleibt es dabei, dass ein absoluter Wert auf Ebene der User Story eingetragen wird, um zu priorisieren und zu sortieren. Die letztendliche Interpretation des Wertes erfolgt anhand der übergeordneten Ebenen. Damit kann der Fehlinterpretation entgegengewirkt werden, dass nach Abschluss einer User Story auch der Wert erreicht wurde - selbst bei Angabe von X Euro im Jahr wird der Wert erst nach einem Jahr erreicht und nicht mit Abschluss der User Story. 86 5 Scrum Artefakte - Die Übersicht behalten 6 Scrum Events - Effektive und effiziente Scrum Meetings Ein wichtiger Abschnitt unserer Reise bezieht sich auf kulturelle Aspekte und Folklore. Daher darf auf keiner Tour ein geistreicher Gedankenaustausch in einem gepflegten Ambiente fehlen. Was wäre da besser geeignet als ein schönes Beisammensein in Rahmen der Scrum Events? Erkunden Sie die Gepflogenheiten dieser Events und lernen Sie die Grundregeln kennen, damit ein gelungener Austausch mit den Einheimischen im agilen Umfeld sichergestellt wird. 6.1 Inkrementelle Produktentwicklung in Sprints Ziel eines jeden Sprints bei Scrum ist es, ein potenziell auslieferbares Produktinkrement zu erzeugen. In der Praxis wird der Begriff Produktinkrement weit ausgedehnt, obwohl das im Sinne von Scrum eigentlich nicht möglich ist. Produktinkrement bedeutet, dass ein Kunde die neue Produktversion in der Produktivumgebung nutzen kann. Sämtliche Graubereiche wie „eigentlich fertig“ oder „fast fertig“ oder „fertig, aber noch nicht final getestet“ oder „fertig, aber nicht nutzbar“ sind demnach im Sinne von Scrum nicht korrekt. Oft fällt es Organisationen jedoch schwer, diesen Schritt in Gänze zu gehen. Folgende Aussage ist demnach zulässig: Ein Großteil der heutigen Scrum-Organisationen sind in Wirklichkeit gar keine. Dabei erweisen sich vor allem fünf Aspekte auf dem Weg hin zu einer agilen Organisation als schwierig. Diese sind Definition of Done, Testen, Continuous Integration/ Continuous Deployment (CI/ CD), gewachsene IT-Landschaften und Integration externer Lieferanten (siehe Abbildung 44). Figure 44: Fünf Herausforderungen bei inkrementeller Produktentwicklung Definition of Done Testen Integration externer Lieferanten Gewachsene IT-Landschaften Continuous Integration / Continuous Deployment (CI/ CD) 5 Herausforderungen bei inkrementeller Produktentwicklung Abbildung 44: Fünf Herausforderungen der inkrementellen Produktentwicklung Definition of Done Wie Sie bereits gelesen haben, versteht man unter der Definition of Done bestimmte Charakteristika, die eine User Story oder ein Task erfüllen muss, um am Ende eines Sprints wirklich als abgeschlossen, also als „fertig“ eingestuft werden zu können. Eine klare Festlegung der Definition of Done ist ein wesentlicher Erfolgsfaktor von Scrum. Wie genau die Definition of Done aussieht, ist von Team zu Team verschieden. Wichtig ist vor allem, dass sie vom Team festgelegt wird, dass alle Teammitglieder sie verstehen und mit ihr vertraut sind, um innerhalb eines Sprints zielgerichtet auf das Sprintziel hinarbeiten zu können. Allerdings gibt es ein paar Kriterien, die in jedem Sprint erfüllt sein müssen. Demnach können Kriterien des Definition of Done für User Stories und Tasks wie folgt aussehen: Done-Regel für eine User Story: ■ 100 % aller Akzeptanzkriterien erfüllt ■ User-Story-Tests erfolgreich abgeschlossen ■ Integrationstest erfolgreich abgeschlossen ■ Alle Bugs, die durch die User Story generiert wurden, wurden behoben ■ Die entsprechenden Dokumentationen und Instruktionen, insbesondere die End‐ anwenderdokumentation, wurden fertiggestellt und übergeben 88 6 Scrum Events - Effektive und effiziente Scrum Meetings Done-Regel für einen Task: ■ Dokumentation fertiggestellt und übergeben ■ Alle Unit-Tests erfolgreich abgeschlossen ■ Code Review erfolgreich durchgeführt In der Praxis ist eine fehlende oder nicht konsequent umgesetzte Definition of Done ein typischer Fehler, der oft erst nach einiger Zeit erkannt wird. Ein Grund dafür ist, dass die Ursachen für nicht erreichte Sprintziele woanders gesucht werden, zum Beispiel in den Fähigkeiten der Teammitglieder oder in fehlender Kommunikation innerhalb des Teams. Die Definition of Done gibt dem Team die Sicherheit und Klarheit, die es braucht, um innerhalb eines Sprints ein potenziell auslieferbares Produktinkrement zu erzeugen. Testen Bevor Sie auf Reisen gehen, überprüfen Sie vielleicht noch einmal, ob der Herd wirklich ausgeschaltet ist und ob Sie alle notwendigen Reisedokumente eingepackt sind. So ähnlich verhält es sich auch mit dem Testen und der Qualitätssicherung bei der Software-Produkterstellung. Ohne erfolgreich durchgeführte Tests kann kein Code mit gutem Gewissen produktiv gesetzt werden. Zwei Punkte treten hier sehr häufig in der Praxis auf. Erstens werden in größeren IT-Projekten viele Test- oder Quality-Assurance-Ressourcen eingesetzt. Obwohl dem prinzipiell nichts entgegenzu‐ setzen ist, können viele Testpersonen auch als nachteilig angesehen werden. Zum einen wird innerhalb des vergrößerten Teams die Kommunikation aufwändiger und kann der Reduzierung von Übergaben (Handovers) damit entgegenwirken, was wiederum aber ein agiles Grundprinzip ist. Zweitens führt ein größeres Testteam zu höheren Kosten. Das richtige Maß ist also von Bedeutung. Ein sinnvoller und praxiserprobter Ansatz ist, die Business Analysten federführend das Thema Tests betreuen zu lassen, da diese die Anforderungen genau kennen. Will man Scrum mit kurzen Entwicklungs‐ zyklen jedoch sinnvoll umsetzen, führt kein Weg an Testautomatisierung vorbei. Hier gibt es viele Herausforderungen. Angefangen von höheren Investitionskosten und zunächst wenig Ertrag bis hin zu der Frage, welche Tests ein Unternehmen eigentlich sinnvollerweise automatisieren sollte. Sollen auch bereits Unit Tests automatisiert durchgeführt werden? Wie sieht es mit Integrations- und Regressionstests aus? Was soll mit den User Acceptance Tests passieren? Will und kann man diese automatisieren? Testautomatisierung zahlt sich üblicherweise nach ein bis drei Jahren aus. Insofern muss es eine bewusste Entscheidung des Unternehmens sein, das sich damit auch allen Konsequenzen in Klaren sein muss. Natürlich wäre es schön - und aus Automatisie‐ rungssicht auch der Idealzustand -, wenn jedwede Tests automatisiert durchführbar wären. Allerdings ist das aus praktischer Sicht oft nicht so einfach umzusetzen und auch gar nicht unbedingt nötig. Wenn eine Organisation mit Testautomatisierung starten will, wären Regressionstests ein guter Startpunkt. Diese kann man über Nacht ausführen und prüfen, ob sich ein neuer Programmcode negativ auf bereits 89 6.1 Inkrementelle Produktentwicklung in Sprints bestehende Funktionalitäten auswirkt. Auch User Acceptance Tests zu automatisieren kann sinnvoll sein, denn dies spart viel Zeit für die Fachabteilungen. Ein nächster Schritt ist Test-driven Development (TDD). Hier beginnt der Entwickler zunächst damit, ein Testprogramm zu schreiben, welches vorher definierte Akzeptanzkriterien prüft. Der Vorteil liegt darin, dass ein Entwickler nun gegen dieses Testprogramm das Produktinkrement entwickeln kann, was erneut zu Zeiteinsparungen und gleichzeitig zu einer höheren Produktqualität führt. In der Praxis haben manche Unternehmen große Herausforderungen im Bereich Testautomatisierung, da sie auf ein schweres Erbe zurückgreifen müssen: eine über Jahre und Jahrzehnte gewachsene IT-Infrastruk‐ tur. Allerdings gilt auch hier das agile Prinzip, im Kleinen mit Experimenten anfangen, und dann die Thematik Testautomatisierung weiter skalieren. Continuous Integration/ Continuous Deployment Stellen Sie sich vor, Sie müssten nur noch ein Urlaubsziel heraussuchen. Danach drücken Sie einfach einen Knopf und alles weitere, was für die Reiseplanung und -buchung üblicherweise zu tun ist, wird automatisch für Sie erledigt. Ein Traum, nicht wahr? Zugegeben, der Vergleich hinkt schon ein wenig, aber immerhin konnten wir so eine Idee davon schaffen, was unter Continuous Integration/ Continuous Deployment (CI/ CD) zu verstehen ist. CI/ CD löst ein Problem, das in der Praxis oft als „Integrati‐ onshölle“ bezeichnet wird. Schreiben Entwicklungsteams, die möglichst unabhängig voneinander an neuen Features für ein und dieselbe Gesamtapplikation arbeiten sollen, einen neuen Code, stellt sich irgendwann die Frage, wie dieser in den bereits vorhandenen integriert werden kann - und zwar ohne zu Fehlern zu führen. Streng genommen besteht CI/ CD nicht aus zwei Schritten, sondern aus drei. Diese sind Con‐ tinuous Integration, Continuous Delivery und Continuous Deployment. Da diese im Idealfall vollautomatisiert ablaufen und ineinandergreifen, spricht man auch von einer CI/ CD-Pipeline (siehe Abbildung 45). Es lässt sich schnell erkennen, dass agile Teams diese Art der Automatisierung benötigen, um schnell einen neuen Code produktiv setzen zu können, sodass der Endanwender diesen nutzen kann. Nur mit CI/ CD ist es möglich, mehrere Code Drops am Tag in Produktion zu haben, was ein großer Wettbewerbsvorteil sein kann, um neue Software Features in kurzen Zeitabständen anbieten zu können oder Fehler, die in der bereits veröffentlichten Software vorhanden sind, zügig beheben zu können. Figure 45: CI/ CD-Pipeline Continuous Integration Continuous Delivery Continuous Deployment Code schreiben Code testen Code zusammenführen Code automatisch ins Repository schieben Code automatisch in Produktion schieben Abbildung 45: CI/ CD-Pipeline 90 6 Scrum Events - Effektive und effiziente Scrum Meetings In der Continuous Integration steht das Zusammenführen eines Codes im Vordergrund, der von mehreren Entwicklern für unterschiedliche Features der gleichen Applikation geschrieben wurde. Üblicherweise ist dieses Zusammenführen (in der Praxis auch als Mergen bezeichnet) mit einem hohen Zeit- und Arbeitsaufwand verbunden und somit ein echtes Hemmnis auf dem Weg hin zu einem schnellen, agilen Team. Das grundsätzliche Problem, das auftreten kann, ist, dass der unterschiedliche Code Kon‐ flikte verursachen kann, die noch erhöht werden, wenn jeder Entwickler seine eigene Entwicklungsumgebung verwendet und keine gemeinsame, integrierte Entwicklungs‐ umgebung vorhanden ist. Nach der Codezusammenführung werden meist automatisch Unit Tests und Integrationstests durchgeführt. Treten hier nun Konflikte auf, so lassen sich diese oft schneller beheben. Continuous Delivery hat die Aufgabe, den zusam‐ mengeführten und getesteten Code automatisch in ein Repository zu schieben. Das damit verfolgte Ziel wird schnell klar: Man will eine Codebasis schaffen, die jederzeit in eine Produktivumgebung geschoben und für den Endanwender nutzbar gemacht werden kann. Wichtig ist dabei, dass auch bei Continuous Delivery sämtliche Tests und Code-Freigaben automatisiert durchgeführt werden, um eine hohe Schnelligkeit bei der Bearbeitung zu gewährleisten. Zuletzt wird bei Continuous Deployment auch die Freigabe des Codes vom Repository in die Produktivumgebung automatisiert. Es ist mit diesen drei Schritten also möglich, dass der von einem Entwickler geschriebene Code innerhalb weniger Minuten für den Endanwender zur Verfügung gestellt werden kann. Damit unterstützt CI/ CD zwei wesentliche Merkmale einer agilen Arbeitsweise. Erstens reduziert CI/ CD die Größe des produktiv zu setzenden Codes (Batch), da durch die kleineren Batch-Größen das Risiko größerer Fehler, wie es oft bei sogenannten Big-Bangs vorkommt, deutlich minimiert wird. Zweitens ermöglicht das schnelle Produktivsetzen des neuen Codes, wertvolles Kundenfeedback unmittelbar auf Code‐ änderungen zu bekommen und diese besser verstehen und bearbeiten zu können. Gewachsene IT-Landschaften Lassen Sie uns noch einmal von einem idealen Reiseziel träumen. Natürlich kommt es jetzt darauf an, ob sie ein Strand- oder Bergtyp sind. Aber lassen Sie uns nicht in Details verlieren. Nehmen wir einen Strandtyp als Beispiel. Die Sonne steht lotrecht als gelber Flimmerball am azurblauen, wolkenlosen Himmel. Die Wellen des türkisfarbenen Meeres brechen sich rauschend und laufen auf dem feinkörnigen, weißen Sandstrand aus. Am Cocktail-Glas perlen kleine Wassertröpfchen. Wundervoll! Übertragen auf agile Organisationen bedeutet dieses Bild, dass es viele autonome Teams gibt, die alle notwendigen Informationen und Fähigkeiten haben, um unabhängig von anderen Teams ihr Teilprodukt weiterentwickeln zu können. Allerdings ist das eben ein Idealbild. Insbesondere größere Unternehmen, deren IT-Landschaft über Jahre oder gar Jahrzehnte gewachsen ist, stehe vor Herausforderungen, um ein solches Setup abbilden zu können. Die agile Reise dieser Unternehmen startet nämlich nicht auf der grünen Wiese (Green Field), wie das bei vielen Start-ups der Fall ist, sondern 91 6.1 Inkrementelle Produktentwicklung in Sprints mit einer komplizierten IT-Infrastruktur (Brown Field), die das Aufstellen autonomer Teams erschwert. Zwei Gesichtspunkte sind hier zu betrachten. Erstens sind die Zuständigkeiten für verschiedene Systeme über mehrere Abteilungen verteilt, sodass eine echte Ende-zu-Ende-Verantwortung für Prozesse erschwert wird. Zweitens sind die Komponenten der IT-Landschaft nicht überall im gleichen Tempo gewachsen und basieren damit sehr wahrscheinlich auf unterschiedlichen Technologien. Das Überwin‐ den etablierter IT-Landschaften ist kraftzehrend und zeitaufwändig und zeitgleich ein Muss auf dem Weg hin zu einer echten agilen Organisation. Integration externer Lieferanten Mit externen Lieferanten zusammenzuarbeiten hat in der heutigen Zeit mit den rasan‐ ten technologischen Entwicklungen einige Vorteile für ein Unternehmen. Dennoch hat auch der traditionellere Ansatz, gewisse Arbeitsschritte auszulagern, weiterhin seine Berechtigung. Aus unternehmerischer Sicht ergibt sich während der Integration von externen Lieferanten in die eigene Organisation folgende Herausforderung: Der Organisationaufbau der Lieferanten beinhaltet eigene interne Prozesse und Strukturen. Es kommt vor, dass diese nicht optimal in die Prozesse und Strukturen der Kunden greifen (was auf Grund der Vielzahl an Kunden auch gar nicht praktikabel wäre). Genau darin besteht eine große Herausforderung für Scrum und die Erstellung des Produktinkrements am Ende eines Sprints. Wie kann diese Konstellation nun angegangen werden? Zwei Schritte erscheinen besonders vielversprechend. Der erste Schritt beinhaltet das Zugehörigkeitsgefühl externer Lieferanten zum Scrum Team. Ein Team besteht eben nicht aus verschiedenen Lagern, in denen sich externe und interne Mitarbeitende aufhalten, sondern aus Menschen, die zusammen ein gemeinsames Ziel verfolgen. Dabei ist Beständigkeit der Teammitglieder ein wesentliches Erfolgskrite‐ rium. In der Praxis hat sich das Einfordern eines festen Lieferantenteams als sinnvoll erwiesen, um ein zu häufiges Wechseln der Teammitglieder zu vermeiden. Der zweite Schritt betrachtet den Aspekt der Transparenz von zu leistenden und bereits geleisteten Aufgaben. Lieferanten berufen sich manches Mal darauf, gewisse Informationen nicht transparent machen zu können, weil sie entweder interne Angelegenheiten betreffen oder weil der Lieferant andere Tools verwendet. In einem ersten Schritt sollte daher versucht werden, ein konsolidiertes Backlog zu verwenden, in dem alle notwendigen Arbeitsschritte offen und transparent dargestellt werden. Das ist nicht zuletzt auch ein wichtiger Bestandteil, Vertrauen zwischen allen Beteiligten aufzubauen. 6.2 Sprint Planning - Was wird wie im Sprint gemacht? Vorab ist festzuhalten, dass das Thema Sprintplanung vermutlich eines der umfang‐ reichsten Scrum Events ist - zumindest hat der Scrum Guide diesem Event eine ganze Seite gewidmet. 92 6 Scrum Events - Effektive und effiziente Scrum Meetings In Kürze ist die Sprintplanung das erste Event eines neuen Sprints, in dem festgelegt wird, welche Aufgaben zu erledigen sind, um ein werthaltiges Ziel (Sprintziel) zu erreichen. Dabei sollte die Sprintplanung in drei Abschnitte unterteilt werden: ■ „Warum“ ist der Sprint wertvoll (Werthaltigkeit) ■ „Was“ soll im Sprint umgesetzt werden ■ „Wie“ soll die Umsetzung erfolgen Am Ende ergibt sich aus dem Sprintziel, den ausgewählten Product Backlog Items und der Umsetzungsplanung das bereits bekannte Sprint Backlog. Die anzusetzende Zeit ist auf maximal acht Stunden für einen vierwöchigen Sprint zu begrenzen oder die Hälfte bei zweiwöchigen Sprints. Dabei handelt es sich jedoch mehr ein Richtwert - meist wird die Dauer der Termine mit der Zeit kürzer. Teilnehmer können alle sein, die etwas zur Sprintplanung beizutragen haben. Wer das Meeting organisiert hängt von der definierten Arbeitsweise des Teams ab. Die Organisatoren sind meistens entweder der Product Owner oder der Scrum Master. Da die Planungsmeetings mit dem Product Owner nicht immer leicht sind, ist es von Vorteil, wenn der Scrum Master moderiert. In der Praxis zeigen sich einige Herausforderungen bei der Sprintplanung. Der Pro‐ duct Owner trägt die Verantwortung dafür, dass sämtliche Teilnehmer gut vorbereitet sein können und es auch sind. Außerdem soll er dafür Sorge tragen, dass alle Product Backlog-Elemente für einen Sprint bekannt sind, damit diese gemeinsam besprochen werden können. Das kann nur gelingen, wenn der Product Owner im Vorfeld die Themen im Rahmen des Backlog Refinements mit dem Team besprochen hat, also die Elemente den Status „bereit“ (siehe Kapitel 5.6.1) haben und er gleichzeitig aufzeigt, wie die Elemente hinsichtlich der Produktziele einzuordnen sind. Das Risiko dabei ist, dass die Backlog Refinements zu einer Art „Vorplanung“ für einen Sprint werden oder zu einer Gesamtplanung für sehr viele User Stories im Product Backlog werden und am Ende eine Art „Projektplan“ entsteht. Die Produktziele sollten deshalb nicht zu groß sein (siehe Kapitel 5.1.4). Während der voluminösen Sprintplanung kann es zudem zu Vermeidungsverhalten kommen. Zum Beispiel wird bewusst oder unbewusst die Größe des Backlogs gedeckelt, um diesen nicht zu groß werden zu lassen. Eine weitere Vermeidungsstrategie ist, das Backlog nicht zu groß werden zu lassen. Wenn es nur so groß ist wie es für das nächste Produktziel notwendig ist, fällt die Fokussierung leichter. Noch einfacher wird es, wenn die Product Backlog-Elemente mit dem Status „bereit“ nur circa anderthalb bis zwei Sprints umfassen. Auf diese Weise wurden die Themen erst vor kurzem besprochen, wodurch die Informationen präsenter sind, als es bei Elementen für zehn Sprints der Fall wäre. Nach dem Scrum Guide sollte der Termin zur Sprintplanung am Anfang eines neuen Sprints stattfinden, wobei ein zeitlicher Umfang von mehreren Stunden, abhängig von der Sprintdauer und den Erfahrungen des Teams, einkalkuliert werden sollte. Aufgrund der Länge dieser Abstimmung ist ein Termin beginnend am Morgen emp‐ fehlenswert. In internationalen Teams von zum Beispiel Großunternehmen gestaltet sich die Terminfindung tückischer. Die Teammitglieder arbeiten möglicherweise in 93 6.2 Sprint Planning - Was wird wie im Sprint gemacht? unterschiedlichen Zeitzonen. Räumen Sie der Frage, wann sich das Team auf die Sprintplanung vorbereiten soll, also genügend Zeit ein. Aus diesen Gründen werden Sie in der Praxis auf verschiedene Philosophien zum Beginn einer Sprintplanung treffen. Die gängigste Variante startet am ersten Morgen des neuen Sprints. Wenn davon ausgegangen wird, dass nach Scrum Guide die Sprint Retrospektive als Abschluss des vorigen Sprints angesehen wird, findet die Sprint Retrospektive mit einer Dauer von bis zu drei Stunden am Vortag der Sprintplanung statt - meist am Nachmittag, denn dieses Event repräsentiert den Sprintabschluss. Der Vorteil ist sicher, dass die Informationen aus der Retrospektive bei der Planung noch sehr präsent sind und möglicherweise direkt berücksichtigt werden können. Auf der anderen Seite ergeben sich so für das Team zwei lange, kurz aufeinanderfolgende Events, sodass sowohl die Konzentration leidet als auch keine Zeit bleibt sich mit Themen detaillierter auseinanderzusetzen. Den Termin der Sprintplanung auf den Nachmittag zu verlegen, würde Freiraum schaffen, sich mit den anstehenden Themen zu beschäftigen, jedoch geht damit ein gesamter Tag des Sprints für die Entwicklung verloren. Zudem könnte die Zeit fälschlicherweise für Nacharbeiten von Aufgaben aus dem vorigen Sprint genutzt werden, die nicht fertig wurden. Es ist keinesfalls grundsätzlich davon auszugehen, dass Aufgaben, die in einen Sprint nicht fertig wurden, automatisch im nächsten Sprint fortgeführt werden. Das abzustimmen wäre Teil der Sprintplanung. Es spricht also einiges dafür, den Weg zweier unmittelbar aufeinander folgender Termine zu gehen. Eine weitere Variante ist, die Sprintplanung des nächsten Sprints am Ende des aktuellen Sprints nachmittags durchzuführen. Selbstverständlich sollte auch in diesem Fall die Sprint Retrospektive vorher erfolgen. Die Auswirkungen auf die Konzentration und Mitarbeit in zwei langen Events direkt hintereinander (oder über den Tag verteilt - vormittags und nachmittags) bedarf vermutlich keiner weiteren Erklärung. Daher wird in dieser Variante meist die Retrospektive kürzer gefasst oder teilweise in die Sprintplanung integriert. Auch hier geht bis zu ein Tag des vorherigen Sprints verloren. Das kann ein Nachteil sein, weil insbesondere am letzten Tag operative Hektik ausbrechen kann, sofern noch offene Aufgaben abgeschlossen werden müssen. Auf der anderen Seite ist fraglich, wie viel der noch offenen Aufgaben am letzten halben Tag noch erledigt werden können. Vielleicht sind es genau die Aufgaben, die nicht die höchste Priorität haben, ansonsten wären es nicht die letzten Aufgaben, die im Sprint gestartet wurden. Es liegt im Bereich des Möglichen, dass sich dagegen entschieden wird, die noch offenen, niedrig priorisierten Aufgaben zu beenden. Ein anderer Aspekt, der für die Variante der integrierten Retrospektive spricht, ist die Tatsache, dass gut eingespielte Teams am letzten Tag des Sprints meist sehr wenig zu tun haben und bei einer guten Backlog Pflege automatisch auf die nächsten Themen vorbereitet sind. Welche Variante auch immer genutzt wird, es ändert nichts an der grundsätzlichen Reihenfolge der Meetings - alles andere sollte das Team miteinander abstimmen und in einer eigenen 94 6 Scrum Events - Effektive und effiziente Scrum Meetings Definition der Zusammenarbeit festhalten. Auf diese Weise wird die höchste Akzeptanz im gesamten Team erreicht. In jeder Sprintplanung sollte man damit beginnen, auszuführen, warum der kom‐ mende Sprint wertvoll ist. Hier ist der Product Owner in der Pflicht. Es ist seine Aufgabe, Vorschläge zu unterbreiten, wie der Wert des Produktes gesteigert werden kann. Nun definiert darauf basierend das Team gemeinsam ein Sprintziel und wählt anschließend die dazu passenden Product Backlog-Elemente für den Sprint aus. In der Praxis ist es so, dass der Product Owner die Product Backlog-Elemente zuvor anhand des Business Values für den Sprint ausgewählt hat. Dies wird auch als „Selected Backlog“ oder Wunschliste des Product Owners bezeichnet. Erfahrene Teams prüfen anhand der verfügbaren Kapazitäten, welche Elemente umsetzbar sind. Weniger erfahrene Teams schätzen ohne weitere Kapazitätsplanung, welche Elemente realisiert werden können. Abschließend definieren alle gemeinsam ein Sprintziel für die Product Backlog-Elemente. In der Realität sieht eine solche Formulierung oft so aus, dass viele Ziele aneinandergereiht und durch ein Komma getrennt werden. Produkt- oder Roadmap-Ziele in einer nahen Zukunft reduzieren dieses Risiko erheblich, werden es aber nicht verhindern, denn die Ursache liegt tiefer - meist in der Organisation selbst. Ein Product Owner wird dann angehalten, den Wert des Produktes zu maximieren, was dieser als seine - und nur als seine Aufgabe ansieht. Der Product Owner verfällt deshalb leicht in die Rolle eines Projektleiters aus Wasserfallzeiten. Dabei ist der Product Owner Teil des Teams und als Team ist es wesentlich leichter, den höchsten Wert zu ermitteln, wenn alle auf ein gemeinsames, nächstes Produktziel hinarbeiten. Das Sprintziel lässt sich auf diese Weise ebenfalls deutlich leichter formulieren und der Sprint wird kein bunter Blumenstrauß von gemixten Anforderungen, die keine Sprintziel Ableitung zulassen. Dieses Verständnis zu entwickeln ist jedoch eine Herausforderung und gleichzeitig die Grundlage für eine gelungenere Sprintplanung. Sobald das Team gemeinsam entschieden hat, was das Sprintziel ist, ist die Auswahl von User Stories aus einem geeigneten, übersichtlichen Product Backlog einfach. Vor der Auswahl sind zwei Dinge zu berücksichtigen: Was wird aus den nicht abgeschlosse‐ nen User Stories des vorherigen Sprints und welche Kapazitäten stehen für die nächsten Sprints zur Verfügung. Beginnen wir mit den nicht abgeschlossenen Elementen. Zwar wurde bereits beschrieben, dass diese Elemente in das Product Backlog zurückfließen und damit wieder in der Planung berücksichtigt werden können, allerdings neigen Teams dazu, ihre angefangene Arbeit abschließen zu wollen. Es ist daher daran zu erinnern, dass das Sprintziel an erster Stelle steht. Wenn es dem Sprintziel hilft, dann sollten diese User Stories wieder aufgenommen werden. Sind diese jedoch nicht förderlich, sollten sie nicht Teil des nächsten Sprints werden. Berücksichtigen Sie dabei, dass eine angefangene User Story den Status „in Bearbeitung“ hat und damit die sogenannte Cycle Time (Zeit vom Start der Bearbeitung bis zum Abschluss - siehe Abschnitt 7.2.1.7) beeinflusst. Die Cycle Time wird oft als Kennzahl verwendet. Um diese zu beschönigen, findet folgender Trick gelegentlich Zuspruch: Halb fertige User Stories werden in zwei Stories unterteilt. Dadurch ist ein Element mehr im vorigen 95 6.2 Sprint Planning - Was wird wie im Sprint gemacht? Sprint fertiggestellt worden und die Cycle Time sieht besser aus. Dieses Verhalten sollte vermieden werden - zum einen entsprach die User Story vorher schon nicht der Definition of Done, und zum anderen wird eine für das Team wertvolle Kennzahl möglicherweise nutzlos. Das zweite Thema, das vor der Auswahl der Elemente für den Sprint berücksichtigt werden sollte, ist die Kapazität des Teams. Hierbei ist für jeden zu ermitteln wie viel Zeit für den Sprint geplant wird. Abwesenheitszeiten wie Urlaub, Feiertage oder Schulungen finden dabei genauso Berücksichtigung wie die Verteilung der Zeit. Ob die Festlegung der Kapazitäten dabei auf Gesamtstunden, Stunden pro Tag oder nur auf ganzen Tagen beruht, ist Geschmackssache. In der Praxis hat sich die Kapazitäts‐ erfassung auf Stundenbasis als sehr hilfreich bei der Planung erwiesen, insbesondere, wenn die Tasks der User Stories auf Basis von Stunden und nicht mit Story Points geschätzt werden. Wenn es keine Stundenschätzungen gibt, dann besteht das Ziel der Kapazitätserfassung eher darin, festzustellen, ob es eine Abweichung von der mittleren Verfügbarkeit des Teams gibt, um damit das Risiko auf die leistbaren Story Points pro Sprint zu berücksichtigen. Bei der Kapazität sollte grundsätzlich nicht auf 100 % geplant werden. Sofern sich das Team auch um den operativen Support kümmert, wird auch dafür ein Teil der Zeit benötigt. Zudem erleichtert ein einkalkulierter Freiraum im Sprint den Umgang mit unvorhergesehenen Tätigkeiten und Situationen. Darunter fallen zum Beispiel der Umgang mit Unsicherheiten einzelner Teammitglieder oder eine Aufgabe, die sich als komplexer als erwartet entpuppt. Manchmal führt ein einfacher fachlicher Austausch untereinander zu neuen Erkenntnissen, der deshalb mehr Zeit in Anspruch nahm. Dieser benötigte Freiraum entwickelt sich bei einigen Team ganz von allein. In anderen Teams hat die Idee des Freiraums jedoch starke Auswirkungen auf die Kapazität einzelner Teammitglieder bis hin zur Gesamtkapazität des Teams. In der Praxis kommt es vor, dass Teams gerade noch die Hälfte der eigentlich vorhandenen Kapazitäten angeben. Es ist jedoch nicht zielorientiert, die Hälfte der Kapazität für Unsicherheiten zu reservieren. Freiräume zwischen 10 und 25 % sind üblich. Nach diesen Vorarbeiten erfolgt eine erste Auswahl der Elemente aus dem Product Backlog. Während oder nach der Auswahl sollte jede User Story nochmals geprüft und bei Bedarf durch weitere Informationen ergänzt werden. Spätestens jetzt sollte auch das Verständnis der Definition of Done für Inkremente erneut auf den Prüfstand gestellt werden. Der Scrum Guide sieht die vollständige Auswahl der Elemente als zweite Phase an, wobei damit bereits festgelegt wird, was in einem Sprint umsetzbar ist. Erst in der dritten Phase soll die Arbeit geplant werden, indem die Elemente in kleine Aufgaben zerlegt werden. In der Praxis ist die Zerlegung der Elemente (User Stories) in kleine Aufgaben (Tasks) jedoch der Schlüssel für eine besser Abschätzung, und damit für die Auswahl der möglichen Elemente in einem Sprint. Die Schätzungen auf Basis der User Story ist maximal für eine Erstbewertung geeignet, was in einem Sprint denkbar wäre. Das wiederum hängt stark von der Kapazität des Teams ab. Insbesondere unerfahrene Entwickler überschätzen ihre eigene Leistungsfähigkeit auf Basis von User Stories erheblich. Das passiert auch sehr erfahrenen Entwicklern immer 96 6 Scrum Events - Effektive und effiziente Scrum Meetings wieder, besonders wenn es Themen sind, zu denen sie nicht auf einen langjährigen Erfahrungsschatz zurückgreifen können oder die Aufgabentypen eher selten auftreten. Daher ist ein Herunterbrechen von User Stories in einzelne Tasks mit Abschätzung jedes einzelnen Tasks ein bedeutender Faktor. Die Auseinandersetzung mit dem Thema und das Aufführen von Einzelschritten zeigt meist mehr auf als die mit der Umsetzung Beschäftigten erwartet hätten. Wenn die Kapazität in Stunden angegeben wurde und auch alle Tasks auf Stundenbasis geschätzt werden, gibt es immer wieder ein Erlebnis des ungläubigen Staunens, dass sich fast alle zu viel vorgenommen haben. Mittels der eben beschriebenen, sehr einfachen Methode kann das Team entspannter damit umgehen, weil Überlastungen nicht von vornherein geplant werden, sondern ein Freiraum sichergestellt werden kann. Ein wichtiger Punkt bei den Schätzungen, der Umsetzungsplanung und Zerlegung der Elemente ist, dass diese nicht in Zweifel gezogen werden - insbesondere nicht durch den Product Owner. Ein Team funktioniert auf Basis von Vertrauen und die Verantwortung und Umsetzung der zuvor genannten Aufgaben liegen allein bei denjenigen, die diese auch umsetzen. 6.3 Daily Scrum - Synchronisation des Entwicklerteams Eine tägliche Zeremonie der agilen Scrum Einheimischen ist das Daily Scrum. Dazu opfern sie gemeinsam 15 Minuten in einem täglichen Ritual, ohne das die Sonne am Scrum-Himmel nicht mehr aufgehen würde. Daher ist es so wichtig, hier die grundlegenden Gepflogenheiten und Abläufe zu kennen, damit das Projekt nicht im Dunkeln steht. Die Idee hinter dem Meeting ist, dass sich das Team täglich in nur 15 Minuten über den Fortschritt und das gemeinsame Vorgehen für den Tag mit Blick auf das Sprintziel miteinander abstimmt. In der Praxis gab es über Jahre hinweg fast überall ein gleichartiges Meeting, das in einem sklavischen Festhalten an so etwas wie Regentanz Rituale erinnerte - in der Hoffnung, dass es danach einen warmen Regen der „Erkenntnis“ gibt. Es fängt mit dem immer gleichen Platz an, an dem sich das Team zu immer gleicher Uhrzeit bzw. in Zeiten von internationalen Teams und New Work als Antwort auf die Corona-Pandemie virtuell trifft. Da das Daily Scrum kurz sein sollte, lohnt es sich nicht, sich hinzusetzen, weshalb das Event auch oft als Standup Meeting bezeichnet wird (was bei virtuellen Meetings vermutlich komisch aussähe). Eingeladen und moderiert wird es vom Scrum Master, wobei das Team teilnehmen muss, auch all diejenigen, die Aufgaben im Sprint haben. Gäste sind erlaubt, auch wenn diese grundsätzlich erst einmal kein Rederecht erhalten. Auf Rückfrage sollten sich jedoch auch die Gäste beteiligen. In diesem Kreis wurde jedem, der an den Aufgaben beteiligt ist, die immer gleichen drei Fragen gestellt: 1. Was hast Du seit gestern getan? 2. Was machst Du bis morgen? 3. Was behindert Dich oder gibt es Blocker? 97 6.3 Daily Scrum - Synchronisation des Entwicklerteams Ergänzt wurden diese Punkte um die Fortschrittsanfrage, wenn ein Task Board mit Stundenabschätzungen verwendet wurde. Wer das jeden Tag macht und immer die ähnlichen Antworten bekommt wie ■ 1. „gestern habe ich das und das gemacht“, 2. „heute mache ich das und das“ und 3. „keine Blocker“ (und ggf. Stunden habe ich aktualisiert), der fragt sich nach einer gewissen Zeit, ob er nicht mal dem Meeting fernbleibt, um lieber einen Kaffee zu holen oder bei guten Tagen mal ein Thema zum Wetter einbringt. Aus diesem Grund beinhaltet der neue Scrum Guide auch keine Vorgaben mehr, wie ein Meeting abzulaufen hat, solange das Daily Scrum sich auf den Fortschritt in Richtung des Sprintziels fokussiert und einen umsetzbaren Plan für den nächsten Arbeitstag erstellt, wodurch Fokussierung und Selbstmanagement gefördert werden. So weit so gut. Gleichzeitig bleibt der Zweck des Events, nämlich den Fortschritt in Richtung des Sprintziels zu prüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren. In der Praxis entsteht dadurch das erste Risiko: Der Scrum Master oder der Product Owner verwandeln den Termin zu einer reinen Statusabfrage, um dem Team vorzugeben, was sie als nächstes zu tun haben, damit die Ziele noch erreicht werden. Das Ergebnis drückt sich häufig in länger werdenden Arbeitstagen aus. Dabei ist der Ansatz des Meetings an sich völlig richtig und hier ist der Scrum Master gefragt. Der Product Owner ist Teil des Teams, aber nicht der Leiter des Teams. Es geht darum, den Austausch mit Informationen zu fördern und gemeinsam Entscheidungen zu treffen, welche Anpassungen im Sprintverlauf notwendig sind, um das Sprintziel zu erreichen. Insofern ist ein Blick in die Vergangenheit kaum relevant, sondern nur, was von diesem bis zum nächsten Daily Scrum gemeinsam gemacht werden kann, damit das Sprintziel voraussichtlich erreicht werden kann. Dazu hilft es, oft zu hinterfragen, wie sich das Team gegenseitig unterstützen kann. Legen Sie besonderen Wert darauf, weiterhin drei Fragen zu stellen, lesen Sie nachfolgend ein paar Ideen, wie diese offener gestaltet werden können: ■ Was könntest du bis morgen machen, um das Team zu unterstützen und ohne Unterbrechung weiterzuarbeiten, sodass wir gemeinsam das Sprintziel erreichen? ■ Wie könnte das Team dich bis morgen unterstützen, damit du ohne Unterbrechung weiterarbeiten kannst, sodass wir gemeinsam das Sprintziel erreichen? ■ Welche Risiken siehst du in deiner Tätigkeit oder der des Teams, die bis morgen oder darüber hinaus das Sprintziel gefährden könnten? Aus den Antworten und der Diskussion ist die Planung des Sprints entsprechend anzupassen. Durch die letzte Frage klärt sich indirekt auch, wie weit jemand mit der Erledigung der zugewiesenen Aufgaben fortgeschritten ist, ohne zu fragen, was er gestern gemacht hat. Wenn derjenige zum Beispiel länger für seine Aufgabe braucht, wäre das ein Risiko. Es ist grundsätzlich zu empfehlen, die Fragen von Zeit zu Zeit zu modifizieren, damit es nicht langweilig wird und die Teammitglieder in weiser 98 6 Scrum Events - Effektive und effiziente Scrum Meetings Voraussicht bereits Antworten zurechtgelegt haben, die am Ende kein echtes Bild des aktuellen Status abgeben. (Das kommt Ihnen bekannt vor? Ihr Instinkt hat Sie nicht getäuscht. Das ist ein typisches Problem von Wasserfallprojekten, die sehr lange „grün“ sind, und dann für viele überraschend plötzlich über Nacht in die Kategorie „tiefrot“ abrutschen.) Das müssen nicht zwangsläufig immer fachliche Fragen sein - damit das Team sich besser kennenlernt, können es auch Fragen aus dem privaten Bereich sein wie „Was hast du dieses Wochenende vor und welches Risiko siehst du dafür? “. Häufig kommt es in Sprints ebenfalls vor, dass Abhängigkeiten zwischen Aufgaben entstehen, die vorher nicht erkannt wurden. Damit der jeweilige Bearbeiter nicht dadurch geblockt wird und dann warten muss, was letztlich den Arbeitsfluss und damit die Performance des Teams als Ganzes negativ beeinflusst, ist es wichtig zu wissen, wie dieses Risiko minimiert werden kann. Dazu ist es gegebenenfalls notwendig, dass ein anderer Entwickler etwas machen muss, das zuerst nicht als nächster Schritt geplant war, damit alle weiterarbeiten können. Es kann dadurch allerdings zu einem unerwünschten Zustand kommen, bei dem ein Entwickler seine bisherige Aufgabe unterbricht, damit ein anderes Teammitglied weiterarbeiten kann. Damit erledigt dieser Entwickler zwei Aufgaben parallel. Dieses wird als Work in Progress (WIP) bezeichnet und führt nachweislich zu einer Verlangsamung bei der Umsetzung der geplanten Tätigkeiten. Das Gleiche könnte auch einem Entwickler passieren, der darauf wartet, dass eine Aufgabe nicht mehr geblockt ist und deshalb eine neue Aufgabe anfängt. Nehmen wir an, dass der Entwickler nun nach dem Start ebenfalls bei der Durchführung dieser Aufgabe geblockt ist, weshalb er eine dritte Aufgabe beginnt. Irgendwann sind die Hindernisse beseitigt, der Entwickler jedoch bewegt sich noch in der dritten Aufgabe, mit der er erst kürzlich gestartet hat. Sein WIP ist dann bereits drei. Ziel ist jedoch immer ein WIP von Eins, also eine Aufgabe zur gleichen Zeit. Dies ist bei jeder Umplanung im Sprint zu berücksichtigen. Weshalb ist die das WIP-Limit, also die Anzahl der zur gleichen Zeit bearbeiteten Aufgaben, so relevant? In der Praxis werden oft Boards zur Visualisierung von Arbeits‐ schritten verwendet. Das ist wichtig und richtig. Allerdings passiert nun oft Folgendes: Die Unternehmen bleiben genau hier unerkannt in ihrer agilen Transformation stehen und sind irritiert, dass keine Verbesserung erreicht wird. Der Grund hierfür liegt im beschriebenen WIP-Limit. Sie kennen vielleicht die Situation, dass ein Kunde, sei es intern oder extern, unverhältnismäßig lange auf ein Ergebnis wartet. Nehmen wir zur Verdeutlichung einfach an, dass die Erledigung der Aufgabe vier Stunden Aufwand bedeutet, der Kunde aber nach drei Wochen immer noch kein Ergebnis erhalten hat. Hier kommt nun das WIP-Limit ins Spiel. Ist der Mitarbeiter so mit Arbeit belegt, dass jede neue Anfrage erst nach Wochen begonnen werden kann, stimmt etwas nicht. Das WIP-Limit ist schlichtweg zu hoch, da zu viele Aufgaben parallel gemacht werden. Ein WIP-Limit von eins ermöglicht es dem Teammitglied, nach Abschluss des aktuellen Arbeitspaketes mit der neuen Aufgabe zu starten und diese auch zu beenden. Es ist ein anschauliches Beispiel, dass Multitasking die Effizienz verringert. Die Visualisierung von Arbeitsschritten allein bringt also keine Effizienzsteigerung mit sich, sondern die 99 6.3 Daily Scrum - Synchronisation des Entwicklerteams Einführung eines WIP-Limits. Für alle, die daran immer noch zweifeln: Es gibt einen mathematischen Beweis - das Gesetz von Little. Es besagt, dass die durchschnittliche Cycle Time der Quotient aus dem WIP-Limit und dem durchschnittlichen Durchsatz ist. Anschaulich ausgedrückt: Je größer das WIP-Limit, je mehr man also parallel an Aufgaben arbeitet, desto länger wird die Cycle Time. Die Erkenntnisse von Little sind nicht neu. Immerhin wurde das Gesetz im Jahr 1961 von ihm bewiesen. Es erfährt jedoch erst im Zuge agiler Transformationen eine wohlverdiente Renaissance. Und das Schöne an Mathematik ist ja, dass nach erfolgtem Beweis nichts mehr daran zu rütteln ist. Halten Sie sich nicht an Vorgaben, die nicht praktikabel sind. Das Daily Scrum darf schneller beendet oder zeitlich ausgedehnt werden, wenn zum Beispiel das Team Zuwachs bekommen hat oder das Produkt ein neues ist. Vielleicht ist das Team aber auch so klein, dass es nur fünf Minuten benötigt oder eine tägliche Abstimmung generell nicht notwendig ist. Das Daily Scrum - auch wenn der Name den täglichen Austausch impliziert - darf auch gerne zum Bi-Daily Scrum werden und alle zwei Tage stattfinden. Ebenso ist die Arbeitsweise mit sogenannten Task Boards und den Tools sehr unterschiedlich. Gut ist, wenn Teammitglieder ihre Aufgaben auf diesem Board selbstständig bearbeiten. Dazu wird je nach Detailgrad zwischen verschiedenen Zuständen der Aufgaben unterschieden. Typisch hierfür sind u. a. Sprint Backlog, To Do, Ready, Next, in Progress, Validation und Done. Es können mehr oder weniger sein. Achten Sie darauf, dass die Bearbeitungsstände „begonnen“ oder „abgeschlossen“ erkennbar sind. Auf diese Weise ist der Status schnell deutlich - insbesondere, wenn auf der Ebene der Tasks noch Stunden verfügbar sind. 6.4 Sprint Review als zentrale Feedbackschleife Das Ziel von Sprint Reviews ist einfach zusammengefasst. Die Ergebnisse des letzten Sprints werden analysiert und entsprechende Anpassungen für kommende Sprints werden vorgenommen. Der Ablauf eines Sprint Reviews kann von Team zu Team verschieden sein. Im Idealfall werden neu entwickelte Funktionalitäten des Produk‐ tinkrements vorgestellt. Aber auch Mock-ups oder Videoclips können verwendet werden. Hier sind der Kreativität keine Grenzen gesetzt, solange das übergeordnete Ziel von Sprint Reviews nicht aus den Augen verloren wird. Denn allen Sprint Reviews gemein ist, dass das Team die Ergebnisse des letzten Sprints an einen erweiterten Stakeholderkreis präsentiert und der Fortschritt in Bezug auf das Produktziel diskutiert wird. Gemeinsam wird nun über die nächsten Schritte entschieden. Diese können zum Beispiel sein, dass bisher alles gut läuft und keine größeren Veränderungen vor‐ genommen werden. Vielleicht erfolgen kleinere Anpassungen am Produktinkrement, die im nächsten Sprint erledigt werden können oder es wird festgestellt, dass das Produktinkrement wegen veränderter Rahmenbedingungen gar nicht mehr passt und 100 6 Scrum Events - Effektive und effiziente Scrum Meetings eine völlig neue Ausrichtung benötigt wird. Das hätte zur Folge, dass auch das Product Backlog angepasst werden muss. Das Sprint Review ist keine reine Präsentation von Ergebnissen durch das Scrum Team an Interessierte. Vielmehr ist es ein Arbeitsmeeting, in dem bestimmte Themen‐ punkte diskutiert und über die weiteren Schritte entschieden wird. Die Teilnehmer können ebenfalls über Schwierigkeiten im letzten Sprint sprechen, Abhängigkeiten - entweder innerhalb des Teams oder zu anderen Teams - noch einmal herausstellen oder auf die längerfristige Planung eingehen. Das Sprint Review ist das vorletzte Event in einem Sprintzyklus und auf maximal vier Stunden bei einem vierwöchigen Sprint begrenzt. Bei kürzeren Sprints kann diese Dauer entsprechend angepasst werden. In der Praxis hat sich eine Dauer von 90 bis 120 Minuten für einen zweiwöchigen Sprint als sehr praktikabel erwiesen. So bleibt genügend Zeit, um Ergebnisse vorzustellen, aber eben auch, um diese inhaltlich zu diskutieren und nächste Schritte zu vereinbaren. Natürlich stellt sich die Frage, wie viel Zeit das Scrum Team in die Vorbereitung eines Sprint Reviews stecken sollte. Diese kann ein echter Zeitfresser werden und sicherlich muss sich das Team einpendeln. Als Faustregel lässt sich sagen, dass jedes Teammitglied nicht mehr als eine Stunde Vorbereitung in ein Sprint Review investieren sollte. Wir hatten zu Beginn des Kapitels schon einmal in einem Satz die Aufgabe eines Sprint Reviews zusammengefasst. Nun wollen wir noch eine Ebene tiefer gehen. Ein wesentlicher Bestandteil ist, dass das Scrum Team das Forum Sprint Review für sich nutzt, um Erfolge sichtbar zu machen. Aber wie bereits erwähnt ist das Sprint Review eine Arbeitssession und keine Selbstbeweihräucherungszeremonie. Wichtig ist nämlich, dass die Chance genutzt wird, qualitativ hochwertiges Feedback von den Teilnehmern einzuholen. Das passiert nur dann, wenn das Forum einen sicheren Raum bietet. Am besten legt das Scrum Team vor, indem es mit Transparenz ein Fundament für offene Gespräche legt. Das fördert am Ende die Zusammenarbeit und die Gemeinsamkeit, und somit auch die Verankerung von Agilität im Unternehmen. Dadurch, dass offen über Fortschritt und Probleme gesprochen wird, könne auch früh‐ zeitig Hindernisse beseitigt werden. Zu guter Letzt sollten wir nicht den eigentlichen Sinn agiler Arbeitsweise vergessen, nämlich von Sprint zu Sprint einen erkennbaren Mehrwert für den Kunden zu schaffen. Ob das gelungen ist, wird sehr schnell in den Diskussionen deutlich, sodass das Scrum Team für den nächsten Sprint etwaige Anpassungen vornehmen kann, sollten sie notwendig sein. Für ein effizientes Sprint Review benötigt es die richtigen Teilnehmer. Sind Sie zum Beispiel auf der Suche nach Kundenfeedback, sollte mindestens ein Kunde als Gast am Sprint Review teilnehmen. Nachfolgend finden Sie einige denkbare Teilnehmergrup‐ pen: ■ Alle Mitglieder des Scrum Teams, einschließlich Freelancer und Kontraktoren ■ Kunden: Das können sowohl externe Kunden als auch interne, zum Beispiel aus anderen Fachabteilungen sein 101 6.4 Sprint Review als zentrale Feedbackschleife ■ Vertreter aus anderen Fachabteilungen, die am Produkt mitarbeiten und die über den Entwicklungsstand des Produktes Informationen benötigen. Das betrifft in der Regel das Marketing und den Sales Bereich ■ Andere Scrum Teams, die entweder Abhängigkeiten zum Produkt haben oder das Sprint Review als Lernsession ansehen ■ Höheres Management. Hier besteht die Gefahr, dass jedwede inhaltliche und ehrliche Diskussion gar nicht erst beginnt. Die Scrum Reviews sind eine gute Möglichkeit, den agilen Reifegrad des Unternehmens bzw. einzelner Mitarbeiter zu erkennen ■ Externe Partner, die an der Entwicklung des Produktes beteiligt sind oder aus anderen Gründen ein berechtigtes Interesse haben Nun fehlt uns noch ein detaillierter Blick darauf, wie eine Agenda konkret aussehen kann, damit ein Sprint Review auch ein Erfolg wird (siehe Abbildung 46). Jedes Meeting beginnt sinnvollerweise damit, dass kurz die Ziele des Meetings angesprochen werden, damit sich während des Termins jeder daran orientieren kann. Für Sprint Reviews kann es darüber hinaus sehr hilfreich sein, wenn die Regeln für den Termin verdeutlicht werden. Wie bereits angesprochen, kann ein Sprint Review sich erst dann vollends entfalten, wenn jeder Teilnehmer offen und ehrlich seine Meinung äußert - das beinhaltet unter Umständen auch Kritik. Ist nun jemand vom höheren Management anwesend, trauen sich manche nicht, offen ihre Meinung zu sagen. Möglicherweise wird die eigene Ansicht rhetorisch so verpackt, dass der eigentliche Sinn verzerrt wird und somit keinen zielführenden Beitrag mehr leistet. An dieser Stelle ist der Scrum Master gefragt, um dieser Entwicklung rechtzeitig entgegenzuwirken. Das ist nicht immer einfach und auch nicht immer von Erfolg gekrönt. Eine ideale Organisationsstruktur für Sprint Reviews sind sogenannte Holakratien. In solchen Organisationen nehmen Mitarbeiter in bestimmten Rollen an Meetings teil und legen ihren bisherigen Status vor Betreten des Meetingraums an der Garderobe ab. Es gibt einige Musterbeispiele, in denen diese Rollenverteilung auf fruchtbaren Boden gestoßen ist. Gleichzeitig war die Implementierung der holakratischen Struktur in circa einer gleichen Anzahl an Beispielen nicht erfolgreich. In der Praxis kann Holakratie ein angestrebtes Ziel von Organisationen sein. Sofern bisher jedoch nur wenige bis keine Erfahrungen mit der Agilität vorhanden sind, kann sich dieses Vorgehen als sehr schwierig oder gar nachteilig gestalten. Nachdem Ziele und Regeln vorgestellt wurden, können nun die Sprintergebnisse präsentiert werden. In einem ersten Schritt wird aufgezeigt, welche Aufgaben im Sprint erledigt wurden und welche der geplanten Aufgaben nicht erledigt werden konnten. Im Anschluss werden die Arbeitsergebnisse im Detail demonstriert. Damit Teilnehmer die Aufgaben einordnen können, insbesondere, wenn sie nicht tagtäglich mit dem Team arbeiten, können nun die gelieferten Ergebnisse in Bezug zur Product Roadmap gebracht werden. Somit kann jeder schnell einschätzen, ob das Team noch immer in die richtige Richtung marschiert oder, ob eine Anpassung der Roadmap notwendig ist. Es folgt ein Ausblick auf den nächsten Sprint. Das geht mit einem Blick ins aktuelle Backlog. In diesem 102 6 Scrum Events - Effektive und effiziente Scrum Meetings Zuge sollten Abhängigkeiten angesprochen werden, damit die Teilnehmer darüber diskutieren können, wie das Team mit diesen umgehen möchte und wie unerwünschte Abhängigkeiten aufgelöst werden können. Jedwede organisatorischen Aspekte, wie beispielsweise personelle Änderungen im Team, können als nächster Agendapunkt mitgeteilt werden, bevor die allgemeine Fragen- und Anmerkungenrunde beginnt. Spätestens hier zeigt sich, inwieweit das Sprint Review tatsächlich von den Teilneh‐ mern als Arbeitssession angesehen wird. Jetzt kommt der Punkt, an dem beseeltes Schweigen einsetzt oder jemand vom höheren Management, weil es von allen erwartet wird, ein Statement abgibt und damit entweder die Diskussion wirklich befeuert oder im Keim erstickt. Scrum Teams werden im ersten Sprint Review vermutlich noch kein brillantes Meeting hinlegen. Durch Feedback zu diesen Treffen und stetig wachsende Übung darin, ändert sich das. Ausschlaggebend ist, dass das Team damit beginnt Sprint Reviews anzubieten. In der Praxis werden diese Termine oft ausgelassen, wenn es aus Sicht der Teammitglieder keine nennenswerten Inhalte gibt. Das bringt uns zurück an den Anfang dieses Kapitels. Das Sprint Review soll den aktuellen Stand der Produktfortschritts zeigen und kein Selbstbeweihräucherungsmeeting sein. Das Scrum Team sollte es den Teilnehmern überlassen, was diese interessant finden. Eröffnung: Ziele und Regeln des Sprint Reviews 1 Sprint Ergebnisse zeigen: Erledigte und nichterledigte Aufgaben 2 Detailliertere Demo der Arbeitsergebnisse 3 Produkt Roadmap: Bezug der erreichten Sprintziele auf die Produkt Roadmap 4 Ausblick nächster Sprint mit Blick in das Backlog und Besprechen von Abhängigkeiten 5 Organisatorische Aspekte (wie z.B. Änderung der Teamstruktur) 6 Fragen erlaubt: offene Fragen und Anmerkungen 7 Figure 46: Beispielhafte Agenda eines Sprint Reviews Abbildung 46: Beispielhafte Agenda eines Sprint Reviews 103 6.4 Sprint Review als zentrale Feedbackschleife 6.5 Kontinuierlich besser werden mit der Sprint Retrospektive Die Sprint Retrospektive befasst sich damit, die Zusammenarbeit innerhalb des Scrum Teams zu verbessern. Im Gegensatz zum Sprint Review nehmen an der Sprint Retro‐ spektive demnach nur die Mitglieder des Scrum Teams teil. Die Sprint Retrospektive ist ein wichtiger Teil von Scrum, da sie sicherstellt, dass sich das Team um kontinuier‐ liche Verbesserung bemüht. Während der Sprint Retrospektive wird der letzte Sprint hinsichtlich einer Vielzahl von Fragestellungen bewertet und mögliche Verbesserungen vereinbart. Damit erfüllt die Sprint Retrospektive eines der zwölf Prinzipien des Agile Manifest: Regelmäßig reflektieren und die Arbeitsweise anpassen, um effektiver zu werden. Folgende Fragestellungen können im Rahmen einer Sprint Retrospektive behandelt werden, stellen aber lediglich eine mögliche Auswahl dar: ■ Was lief richtig gut während des letzten Sprints? Was lief nicht so gut? ■ Wie war die Zusammenarbeit zwischen des Teammitgliedern? Gab es Konflikte, die es zu lösen gilt? ■ Wie wurden Probleme während des Sprints durch das Scrum Team gelöst oder eben nicht gelöst? ■ Wurden Abhängigkeiten zwischen den Teammitgliedern nicht adäquat berück‐ sichtigt und hatten negativen Einfluss auf das Sprintziel? ■ Gibt es prozessuale Themen, die das Team angehen sollte, weil sie die Effizienz negativ beeinflussen? ■ Werden die User Stories wie vereinbart geschrieben, damit bereits von Anfang an ein Augenmerk auf Qualität und Effizienz gelegt wird? ■ Wird die Definition of Done eingehalten oder müssen hier etwaige Verbesserun‐ gen vorgenommen werden? ■ Sind getroffene Annahmen noch gültig oder müssen Anpassungen vorgenommen werden? ■ Werden Tools so genutzt wie vereinbart? Gibt es hier Verbesserungsbedarf ? Die Verbesserungen, die den größten Einfluss auf Zufriedenheit, Qualität und Effizienz des Scrum Teams haben, werden nun so bald wie möglich angegangen. Das kann zum Beispiel dadurch geschehen, dass einige Verbesserungen als User Stories ihren Weg in das Sprint Backlog finden. Die Sprint Retrospektive ist das letzte Event in einem Sprintzyklus und auf maximal drei Stunden bei einem vierwöchigen Sprint begrenzt. Bei kürzeren Sprints kann diese Dauer entsprechend angepasst werden. In der Praxis hat sich auch hier eine Dauer von 90 bis 120 Minuten für einen zweiwöchigen Sprint als sehr praktikabel herausgestellt. So hat das Scrum Team genügend Zeit, um zu diskutieren, was gut und was nicht so gut lief, und welche Maßnahmen als nächstes angegangen werden sollen, um sich entsprechend als Team weiterzuentwickeln. 104 6 Scrum Events - Effektive und effiziente Scrum Meetings Wie kann nun die Durchführung einer Sprint Retrospektive in der Praxis aussehen? Esther Derby und Diana Larsen stellen in ihrem Buch „Agile Retrospectives: Making good teams great“ ein 5-Phasen-Schema vor, das sich als äußerst praktikabel heraus‐ gestellt hat und nachfolgend kurz erläutert werden soll (siehe Abbildung 47). Den Boden bereiten (Set The Stage) 1 Daten sammeln (Gather Data) 2 Erkenntnisse ableiten (Generate Insights) 3 Entscheidung über nächste Schritte (Decide What To Do) 4 Abschluss der Retrospektive (Close The Retrospective) 5 Figure 47: 5-Phasen-Schema einer Sprint Retrospektive Abbildung 47: 5-Phasen-Schema einer Sprint Retrospektive Phase 1: Den Boden bereiten (Set The Stage): Offenheit und Transparenz sind wichtige Merkmale agiler Hochleistungsteams. Damit das auch während der Sprint Retrospektiven so bleibt, soll in dieser Phase ein sicherer Rahmen gebildet werden, damit nicht verheimlicht wird, sondern alle gemeinsam an einem Strang ziehen, um das Team besser zu machen. Ein wichtiger Grundsatz lautet demnach, dass alle Teammitglieder davon ausgehen, dass jeder im Rahmen seiner Möglichkeiten und seines Wissensstandes das Beste für das Team gegeben hat. Primär geht es also darum, die Teammitglieder abzuholen, auf den Termin einzustim‐ men und schon mal zum Reden zu bringen. Dahinter steckt der psychologische Ansatz, dass es Menschen wesentlich leichter fällt, sich an einer Diskussion zu beteiligen, wenn sie während des Meetings bereits etwas gesagt haben. Der Scrum Master als Moderator hat hier also die Aufgabe, vor allem schüchterne Teammitglieder zum Sprechen zu bewegen. Das kann durch die einfache Frage nach den Erwartungen an das Meeting geschehen, die dann reihum von allen beantwortet wird. Oder es wird ein kurzes Spiel zur Einstimmung gemacht. Der Kreativität sind hier keine Grenzen gesetzt. Sorgen Sie nur dafür, dass alle einmal das Schweigen gebrochen haben (und nicht nur, indem sie „ja“ oder „ok“ von sich gegeben haben). 105 6.5 Kontinuierlich besser werden mit der Sprint Retrospektive Phase 2: Daten sammeln (Gather Data): In dieser Phase geht es darum, möglichst viel Informationen zu sammeln. Hierbei spielt es zunächst keine Rolle, ob das gute oder schlechte Ergebnisse aus dem letzten Sprint betrifft. Wichtig ist, dass alle Erkenntnisse und Erfahrungen offen, ehrlich und transparent auf den Tisch gebracht werden. Es liegt in unserer Natur, sich an dieser Stelle auf negative Erkenntnisse zu beschränken. Das ist nicht nur schade, sondern hat letztlich auch einen negativen Einfluss auf das Scrum Team. Wenn das Team sehr gute Arbeit leistet, ist dies es auch wert, angesprochen und mit einem Lob versehen zu werden. Wer hört nicht gerne ein Lob? Zwei Methoden sind dabei besonders beliebt in der Praxis. Die (verdeckte) Karten‐ abfrage oder das Histogramm in Verbindung mit einer Zeitachse (siehe Abbildung 48). Bei der (verdeckten) Kartenabfrage sammelt zunächst jedes Teammitglied positive und negative Erkenntnisse für sich. Danach werden diese gemeinsam angesehen und passende Karten einander zugeordnet. So entsteht anhand der Anzahl von Karten innerhalb einer Gruppierung ein guter Überblick darüber, welche Themen die Team‐ mitglieder am meisten bewegen. Beim Histogramm in Verbindung mit einer Zeitleiste werden die positiven und negativen Erkenntnisse auf einer Zeitleiste, welche die Dauer des letzten Sprints abbildet, eingeordnet. Zusätzlich können die Teammitglieder ihre Stimmungen in Bezug auf die Erkenntnisse entlang der Zeitleiste einzeichnen. So entsteht ein übersichtliches Gesamtbild. (Verdeckte) Kartenabfrage Histogramm in Verbindung mit einer Zeitachse S t i m m u n g Tag 1 2 … 3 4 5 Figure 48: Daten sammeln während der Sprint Retrospektive Abbildung 48: Daten sammeln während der Sprint Retrospektive Phase 3: Erkenntnisse ableiten (Generate Insights): In dieser Phase sollen aus den gemachten Beiträgen die wichtigsten Erkenntnisse abge‐ leitet werden. Das geschieht zum Beispiel dadurch, dass die Teammitglieder die Inhalte ihrer Beiträge kurz erläutern und - wie in der Beschreibung zu Phase 2 bereits angedeutet 106 6 Scrum Events - Effektive und effiziente Scrum Meetings - gleiche oder ähnliche Themen einander zugeordnet werden. So stellt sich schnell ein gutes Gesamtbild darüber ein, was das Team im Positiven wie Negativen bewegt. Es ist jedoch nicht notwendig, strikt nach den bereits beschriebenen Phasen vorzu‐ gehen. Vor allem Phase 2 und Phase 3 verschwimmen in der Praxis oft miteinander. Das ist völlig in Ordnung. Wichtig ist nicht, sich dogmatisch an ein Phasenmodell zu halten, sondern den für das Team besten Weg zu finden, um kontinuierliche Verbesserungen zu erzielen. Phase 4: Entscheidung über nächste Schritte (Decide What To Do): In Phase 3 können endlose Diskussionen entstehen. Auch wenn diese gut und richtig sein mögen, muss das Team irgendwann an den Punkt kommen, dass es sich klar über die nächsten Schritte wird. Dafür sorgt Phase 4. In dieser Phase wird entschieden, welche Verbesserungsvorschläge als nächstes im Fokus stehen sollen und den höchsten Mehrwert liefern. Am einfachsten kann das durch eine Punkteabfrage geschehen, in der jedes Teammitglied eine bestimmte Anzahl von Bewertungspunkten erhält, die es den einzelnen Gruppierungen zuordnen kann. Hier gibt es ganze Theorien dazu, wie viele Punkte ein Teammitglied maximal bekommen darf. Machen Sie sich das Leben nicht unnötig kompliziert. Folgendes hat sich in der Praxis bewährt: Geben Sie jedem Teammitglied halb so viele Punkte wie es Gruppierungen (Themen) gibt. Haben Sie also zehn Gruppierungen, so bekommt jedes Teammitglied fünf Punkte. Bei sieben Gruppierungen geben Sie jedem Teammitglied vier Punkte. Nachdem die Punkte auf die Gruppierungen verteilt wurden, wird schnell klar, auf welche Verbesserungen sich das Team im nächsten Sprint fokussieren will. Das Team sollte sich dabei nicht zu viel vornehmen. Eine einfache Regel, angelehnt an Toyota Kata, einer Continuous Improvement-Methode, die durch Mike Rother eine starke Verbreitung fand, kann helfen: Im nächsten Sprint wird immer nur eine Verbesserungsidee umgesetzt. Das mag wenig klingen, kann aber Wunder wirken. Denn dadurch vermeidet man zum einen eine Überlastung des Teams, und zum anderen, dass der kontinuierliche Verbesserungsprozess im Laufe der Zeit ausläuft und de facto gar nicht mehr stattfindet. Phase 5: Abschluss der Retrospektive (Close The Retrospective): Diese Phase schließt die Retrospektive ab. Hier sind vor allem drei Aspekte wichtig. Zum einen sollten die Ergebnisse der Retrospektive noch einmal durch den Scrum Master zusammengefasst werden und die Zustimmung des Teams hinsichtlich nächster Schritte eingeholt werden. Außerdem lohnt es sich, auch die Retrospektive einer kon‐ tinuierlichen Verbesserung zu unterziehen und Feedback einzuholen. Die einfachste Methode ist sicherlich eine kurze Bewertung mit Smileys am Ende der Retrospektive, bei der jedes Mitglied entweder ein lächelndes, ein neutrales oder ein weinender Smiley vergibt. Zu guter Letzt ist es immer ratsam, die Retrospektive mit einer positiven Stimmung zu beenden. Ein kurzes abschließendes Spiel kann dabei Wunder wirken. Auch hier sind der Kreativität keine Grenzen gesetzt. 107 6.5 Kontinuierlich besser werden mit der Sprint Retrospektive 7 Status-Reporting und Metriken - Risiken und Probleme managen Besuchen wir die unterirdischen Höhlen der Reports und bringen etwas Licht in das Grau der theoretischen Grundlagen. Tauchen Sie mit uns ins Gewölbe der Metriken hinab in den stillen See der Kennzahlen und erkunden die Untiefen der berühmten Sprint Performance. Allerdings müssen wir Sie warnen: Danach betrachten Sie vermut‐ lich einige Dinge im agilen Umfeld anders. Daher ist dieses Kapitel nichts für Reisende mit schwachen Nerven in Bezug auf die heile Scrum-Welt, in der die weit verbreitete Vorstellung einer perfekten agilen Umgebung herrscht, in der ein Produkt von einem oder mehreren kleinen Teams für eine klar definierte Kundengruppe erstellt wird, in der die agilen Kontroll- und Steuermechanismen immer und ausnahmslos greifen, in der jeder Sprint einen nachprüfbaren Wert liefert, und in der es genügt, wenige Diagramme mit einfachen Steuerungsgrößen zu haben, um den Projektfortschritt zu jeder Zeit ganzheitlich zu messen. Aufgrund der guten Qualität bedarf das Produkt zudem praktisch keinen operativen Aufwand. In der Realität zeigt sich jedoch meist ein anders Bild. Insbesondere in großen Unternehmen, welche sich sehr oft noch in einer Transitionsphase von Wasserfall-Mo‐ dellen auf agile Methoden befinden. Dort gibt es ein gewünschtes Gesamtprodukt, das aus mehreren Einzelprodukten besteht, die von verteilten, internen Teams in unterschiedlichen Ländern und externen Lieferanten (ebenfalls mit verteilten Teams) erstellt werden. Die Teams sollen dabei gleichzeitig eine Ende-zu-Ende-Verantwortung von der Entwicklung bis zum Betrieb haben. Steuerung und Kontrolle der externen Dienstleister erfolgt bis zu einem gewissen Grad mittels agiler Methoden durch den Auftraggeber. Kunden sind unternehmensinterne Bereiche mit unterschiedlichen Sich‐ ten auf das Zielprodukt, konkurrierenden Anforderungen hinsichtlich der Prioritäten und ohne nachprüfbare Bewertung eines Business Values, der nach unterschiedlichen Methoden ermittelt wurde. Der Reifegrad der agilen Organisation ist eher gering, eine einheitliche Vision mit zugehörigen Strategien fehlt, jedes Team arbeitet mit eigenem Backlog in Silos ohne übergreifende Abstimmung und die Metriken, sofern diese genutzt werden, orientieren sich an sehr einfachen, eindimensionalen Standards. Abgesehen davon, dass die Organisation insgesamt, der Breakdown von der Vision bis zum Product Backlog und eine geeignete Definition der Ways of Working hier meist der zentrale Schlüssel für den Erfolg sind, stellen sich insbesondere in dem beschriebenen Umfeld andere Anforderungen an die notwendigen Metriken als in einer idealen agilen Welt. Eine typische Ausgangssituation bei internen, agilen Projekten ist, dass sehr oft viele verschiedene, einfache Diagramme (zum Beispiel Sprint Burndown Charts mit Anzahl der abgeschlossenen User Stories oder Velocity auf Basis von Story Points) gezeigt werden, um den Fortschritt und Status zu dokumentieren. Für sich allein genommen sind diese im Grunde jedoch wenig geeignet, den wirklichen Fortschritt zu zeigen oder gar Probleme frühzeitig erkennen zu lassen, um geeignete Gegenmaßnahmen ableiten zu können. Es kommt zu reinen Show- oder Ego-Dashboards, denen weder eine Zielbeschreibung der Metriken zugrunde liegt, noch sind sie an den möglichen Zielgruppen der Dashboards ausgerichtet. Damit trägt so ein Dashboard nicht dazu bei, den möglichen Informationsmehrwert zu transportieren. Grundsätzlich sollte eine Metrik immer zu einer Entscheidung führen oder Ableitungen von Maßnahmen ermöglichen. Dazu ist es notwendig, dass die Kernfragen hinsichtlich Projektfortschritt mit echten Messdaten beantwortet werden können, die Datengrundlage der Messwerte nicht manipuliert wird und diese Daten über einen gewissen Zeitraum miteinander vergleichbar sind und nicht nur auf einmaligen Ereignissen beruhen. Eric Ries unter‐ scheidet in seinem Buch The Lean Start-up zwischen Vanity Metriken und Actionable Metriken. Vanity Metriken sind dabei Kennzahlen, die zwar schön aussehen und nach außen hin ein gutes Bild abgeben, aber im Grunde nicht brauchbar sind, da sie keine Aussagen darüber liefern, welche Maßnahmen im Falle bestimmter Risiken oder Probleme angewendet werden können. Im Gegensatz dazu bieten Actionable Metriken eben genau das an und sind somit immer den reinen Show Metriken vorzuziehen. Nun scheint sich seit einiger Zeit trotzdem die Meinung zu verbreiten, dass mit den einfachen Diagrammen der gängigen Tools bereits alle Metriken in perfekter Form vorliegen und damit alle Probleme leicht erkannt sowie passende Gegenmaßnahmen abgeleitet werden können. Das ist in etwa so wahrscheinlich wie die Hoffnung, dass mit einer agilen Arbeitsweise alles sehr einfach mit einem großartigen Team gelöst werden kann, kein Projekt mehr scheitert, alles schneller entwickelt wird, die Kosten in einem fantastischen Verhältnis zum Nutzen stehen, der Kunde immer glücklich ist und dabei gleichzeitig kein oder nur ein sehr einfaches Reporting notwendig wäre. Weit gefehlt - agile Projekte können auch sehr viele Probleme haben, nur dass diese oft nicht oder nicht rechtzeitig erkannt werden (unter anderem aufgrund fehlender Metriken) oder eine Offenlegung der Probleme schlichtweg nicht erfolgte - zumindest nicht, bis das Geld ausgeht. Erinnern Sie sich an das Kapitel Daily Scrum und den Verweis auf Wasserfallprojekte? Dabei sahen die Diagramme doch immer so gut aus! Eventuell könnten Probleme bereits bei den einfachen Diagrammen auffallen, aber eben nur, wenn klar ist, worauf im Detail zu achten ist - dafür bedarf es allerdings viel Erfahrung. Das Scrum Framework und auch andere agile Methoden haben dazu eigentlich klare Feedback- und Steuermechanismen, diese werden jedoch häufig nicht oder unzureichend genutzt oder es fehlt einfach an messbaren Fakten. Und das, obwohl grade in agilen Projekten mehr nützliche Kennzahlen und Informationen in viel kürzeren Intervallen verfügbar sind als in Wasserfallprojekten. Insbesondere mit dem Einsatz der heutigen Tools stehen nahezu alle Daten direkt zur Verfügung oder können mit sehr wenig Aufwand bereitgestellt werden. Im nachfolgenden Abschnitt werden daher einige vereinfachte Möglichkeiten erör‐ tert, wie Kennzahlen zur Risikominimierung durch Früherkennung von typischen Problemsymptomen in Projekten beitragen können. 110 7 Status-Reporting und Metriken - Risiken und Probleme managen 7.1 Zielgruppen und Informationsbedarf 7.1.1 Grundlagen zu Kennzahlen im agilen Umfeld Bei dem ersten Kontakt mit internen, agilen Projekten ist oft zu hören, „wir arbeiten agil, daher sagen wir nur, was in dem nächsten Sprint passiert“, oder noch unkonkreter, „wir sagen nach dem Sprint, was wir geschafft haben“. Der Status ist aus dem „Dashboard“ mit vielen Diagrammen ersichtlich. Der klare Vorteil dieser Arbeitsweise ist, dass das Projekt per Definition niemals fehlgeht und jeder Schritt nach dem agilen Framework ausgerichtet wurde. Teuer wird dieses Vorgehen meist dann, wenn bei internen Projekten externe Lieferanten genauso arbeiten oder gesteuert werden. Es kommt hierbei zu Beauftragungen von einer Anzahl von Sprints (Zeit) mit einer gewissen personellen Kapazitätszusicherung, meist ohne Lieferziele. Dies ist sicher eine flexible Lösung nach dem Muster Time and Materials (T&M)-Beauftragungen, jedoch wird es ohne Kennzahlen nicht möglich sein, brauchbare Schätzungen zu möglichen Zielwünschen abzugeben. Damit kann die Kernfrage, „welches Ziel soll und kann mit der Beauftragung bis wann erreicht werden“, nicht beantwortet werden. Alternativ gibt es gute Methoden, einen ersten Ausblick auf Kosten und Zeit eines Projektes auch im agilen Umfeld zu geben. Hierbei wird anhand einer kurzen Erkun‐ dungsphase ein voraussichtliches Umsetzungsvolumen, wie zum Beispiel die Anzahl von umgesetzten Referenz-Elementen innerhalb einer definierten Bearbeitungszeit abgeleitet. Ziel ist es, sowohl den Projektumfang als auch das Umsetzungsvolumen über einen Zeitraum konkreter abschätzen zu können. Dadurch kann der Kostenrahmen als Umsetzungsvolumen angegeben werden und ermöglicht einen definierten Output, der als Zielwert benannt werden kann. Das beinhaltet auch die sogenannten Risk Shares, die das Verfahren beschreiben, wie mit signifikanten Änderungen umzugehen ist. Eine regelmäßige Prüfung der Parameter im Projektverlauf ermöglicht zudem weitere Anpassungen. Die Voraussetzung dafür ist die Wahl der richtigen Metriken. Das agile Vorgehen soll an dieser Stelle nicht zu einer Wasserfallplanung werden, in der alle Anforderungen nach einer Spezifikationsphase verfügbar sind. Dennoch können auch im agilen Modell nur dann Aussagen zu zum Beispiel einem möglichen Lieferumfang treffen, wenn zuvor einige Kennzahlen ermittelt werden und bekannt sind. Mit diesen können dann wichtige Fragen wie „welche Kosten sind in der nächsten Zeit zu erwarten“, „welcher Nutzen kann voraussichtlich erzeugt werden“, „wie lange würde die Umsetzung eines größeren Themenblocks vermutlich dauern“ beantwortet werden. In diesem Zusammenhang kann es geschehen, dass das agile Vorgehen in das Wasserfallmodell übergeht, was den Vorteil bringt, dass keine Statusberichte mehr erstellt werden müssen und Zeitvorgaben weniger konkret sind. Typische Signale, anhand derer Sie diese Entwicklung bemerken können, erscheinen bereits in den ersten Sprints. Diese befassen sich dann primär mit Spezifikationen, Analysen, Design der Applikation oder nur mit einzelnen Komponenten. 111 7.1 Zielgruppen und Informationsbedarf Ein weiteres Zeichen, dass eine Organisation eine Produktentwicklung eher nach dem Wasserfallmodell gestaltet und sich nicht mehr im agilen Vorgehen befindet, ist ein prall gefüllter Backlog. Ist dieser zusätzlich bereits für mehrere Monate ausgestattet, sodass im Grunde bereits alle konkreten Anforderungen bis zum finalen Produkt vorliegen, entspricht die Vorgehensweise eher der tradierten Methodik. Die Gründe dafür sind vielfältig. Möglicherweise bestehen noch Herausforderungen, das Konzept des agilen Vorgehens in Gänze zu verstehen oder es wird nicht vollständig akzeptiert. Der Weg dorthin ist ein lebendiger Prozess, da mit Agilität eben auch Veränderungen im Verhalten und lang einstudierter Denkweisen verbunden sind. Der Gegenpol, sich fortan akribisch an die agilen Methoden nach Lehrbuch zu halten, birgt genauso Risiken, denn eine Punkt-für-Punkt-Befolgung der ausgewählten, agilen Vorgehensweisen garantiert nicht, dass ein Projekt erfolgreich abgeschlossen wird. Im Verlauf kommt es immer wieder zu Hindernissen, die unerwartet auf die Fahrbahn gelangen. Das hat zur Folge, dass die Lehrbuch-Methodik, die auf eine hindernisfreie Strecke ausgelegt ist, nicht mehr greift, um am Hindernis vorbeisteuern zu können, und deshalb nicht mehr zum Erfolg führt. Das Unternehmen muss sich mit jeder neuen Veränderung die Frage stellen, wie mit diesen Hindernissen am zielführendsten umgegangen werden kann. Um passende Lösungen zu finden, benötigt das Scrum Team einen Ermessensspielraum, auch wenn dadurch klare definierte Prozessregeln umgangen werden. Leitlinien, die frühzeitig und gemeinsam vom Scrum Team aufgestellt wurden, stellen dabei sicher, dass die verwendeten Mittel weiterhin zur Unternehmensphilosophie und zu den Grundwerten der Teammitglieder passen, denn nicht „der Erfolg heiligt die Mittel“. Die Leitlinien orientieren sich dabei außerdem an einem agilen Framework und das Team nimmt mit Augenmaß Prozessanpassungen vor, wo diese nötig sind, um den Leitlinien zu entsprechen. Diese Ways of Working bilden die Grundlage für ein erfolgreiches Arbeiten. Wann kommen die Kennzahlen ins Spiel und was haben sie mit alledem zu tun? Kennzahlen haben einen Offenbarungscharakter. Bewusste oder unbewusste Heraus‐ forderungen spiegeln sich in diesen wider. Gab es vorher bereits ein Gefühl, dass irgendetwas nicht richtig ist und konnte dies jedoch nicht näher betitelt werden, kann dies nun durch die Kennzahlen konkret beziffert und benannt werden. Das ermöglicht es dem Scrum Team, effiziente Lösungen zu finden und eben nicht nur Symptome zu behandeln. Daher ist es so elementar, die richtigen und wichtigen Metriken zu kennen und diese auch zu nutzen. Letztendlich wird das Team dadurch in seiner Arbeit unterstützt. Finden Sie einen Mittelweg. Die Transitionsphase ist in vielen Unternehmen gezeichnet von zwei sehr konträren Entwicklungsprozessen. In dem einen werden keine oder nur wenige Metriken verwendet, sondern einzelne Elemente, wie zum Beispiel der Sprint Burndown auf Basis erledigten User Stories gezeigt. Der andere Entwicklungsprozess beinhaltet nahezu alle denkbaren Zahlen, unabhängig von deren Relevanz oder Priorität. Sicher kann es nützlich sein, alle Daten zu haben und bei Abweichungen je Bereich prüfen zu können, woran es gelegen hat. Diese 112 7 Status-Reporting und Metriken - Risiken und Probleme managen Methode erzeugt jedoch in erster Linie eine Anhäufung von Daten, ohne dass diese genutzt werden können, da weder Ziel noch Bedeutung klar sind. Aus solchen Zahlen lassen sich keine Maßnahmen ableiten. So werden zum Beispiel Zahlen zu „erstellte Codezeilen pro Sprint“, „Anzahl erfolgreicher Builds“ oder Daten wie „gefundene Fehler während eines Sprints“ bei externen Lieferanten ermittelt. Das mögen Steuergrößen beim Lieferanten sein, zum Steuern des Lieferanten tragen sie jedoch nicht bei. Dass Metriken nur eine geringe Bedeutung beigemessen wird, scheint daran zu lie‐ gen, dass bereits die Beschäftigung mit dem Thema erstmal keinen direkten Mehrwert für das Projekt zu bringen scheint. Ein vollständiger Katalog von Metriken gleich zu Beginn des Projektes unterstreicht dies. Fangen Sie deshalb kleiner an. Richten Sie die Metriken am Reifegrad Ihres Teams aus. Sie sollen es dem Team und den Mitgliedern ermöglichen, eine weitere Stufe der Reife zu erreichen. Am Ende ist das schließlich auch eine Art agiles Vorgehen, oder? Damit Ihre Metriken aussagekräftig werden, beschreiben Sie vorab, welche Ziele mit welchen Metriken erreicht werden sollen und welche Zielgruppe angesprochen wird. Das wird Ihnen helfen, anschließend Maßnahmen daraus ableiten zu können. Definieren Sie vorher außerdem, welches agile Framework verwendet wird und wie das Team arbeiten möchte. Diese Ways of Working-Beschreibung enthält Begriffsbe‐ stimmungen wie die Definition of Ready und die Definition of Done sowie eine Prozessablaufbeschreibung. In dieser wird unter anderem der Umgang mit Prioritäten, dem Business Value, mit Risiken, Aufwandschätzungen, Abhängigkeiten und Sortie‐ rungen des Backlogs festgelegt. 7.1.2 Metriken und Zielgruppen Welcher Weg könnte nun gegangen werden, um sinnvolle Metriken zu erstellen? Hier gibt es verschiedene Ansätze. Ein praktikabler Weg ist, zuerst festzustellen, wer welche Information benötigt - also wer etwas über das Projekt wissen möchte und welchen Einfluss die Person auf mögliche Verbesserungen haben könnte. Der letzte Punkt ist besonders wichtig, denn bei allen späteren Metriken ist immer kritisch abzuwägen, ob der Aufwand der Datensammlung und Analyse im Verhältnis zum Nutzen steht. Nur um die Neugier einzelner Personen ohne Projekteinfluss zu befriedigen, sollten keine Metriken erstellt werden - dafür ist jeder Aufwand zu hoch, selbst wenn sich sehr viele Indikatoren mit den heutigen Tools sehr leicht ermitteln lassen. Zudem stellt sich die Frage, ob sich von allen Indikatoren Metriken ableiten lassen, die förderlich für das Projekt oder das Team sind. Messwerte können negativ ausgelegt werden und unerwünschte Folgen haben, wenn kein klares Ziel mit einer Metrik verfolgt wird. Schnell werden dann typische Standardmessgrößen, wie zum Beispiel die Lead Time (vgl. Standard-Metriken), aus dem Zusammenhang gerissen und, sei es aus Absicht oder Unerfahrenheit, negativ bewertet, weil der Wert hoch ist. Das Verständnis, wie diese Zahlen zu deuten sind, hat eine wesentlich höhere 113 7.1 Zielgruppen und Informationsbedarf Bedeutung. Diese Punkte sollten immer beachtet werden, denn längst nicht alles was ermittelbar ist, ist sinnvoll oder nützlich. Nicht alle möglichen Performance-In‐ dikatoren sind automatisch Key Performance-Indikatoren - das gilt auch im agilen Umfeld. Vertrauen Sie dem Team! Das ist ein besonders wichtiger Rat zum Thema Metriken, den Sie immer beachten sollten. Eines der größten Risiken von Zieldefinitionen ist die Nutzung der Ergebnisse als Leistungskontrolle oder Leistungsbewertung. Werden Indikatoren ermittelt, die in erster Linie der Überwachung des Teams oder einzelner Teammitglieder dienen, kann sich das störend auf das gesamte Team auswirken. Krea‐ tivität und Produktivität überleben in einem Umfeld der Überwachung nur mühsam. Zudem findet in solchen Fällen Goodharts Gesetz Anwendung: Wenn eine Messgröße zum Ziel wird, hört sie auf, eine gute Messgröße zu sein. Die Wahrscheinlichkeit, dass die Kennzahlen zum Vorteil des Teams manipuliert werden, steigt. Grundsätzlich darf es bei Zielwerten daher nicht um Leistungsziele im weiteren Sinn gehen, sondern ausschließlich darum, unterstützende Maßnahmen für das Team frühzeitig starten zu können. Daher kann nur wiederholt werden, dass längst nicht jeder Indikator, der ermittelbar ist, gleichzeitig sinnvoll oder nützlich ist; ebenso wie auch nicht jede nützliche Metrik für jeden Empfänger automatisch sinnvoll ist. Es kommt immer darauf an, wer Empfänger der Information sein soll. Damit kommen wir zur Eingangsfrage zurück: Wer braucht welche Information? Was sollte ein Manager, der in erste Linie an Kosten und Time to Market interessiert ist, mit Metriken zur Applikation über Reaktionszeiten, Speicherauslastung und CPU-Nutzung anfangen? Richten Sie jede Metrik immer an der Zielgruppe aus. Nachdem dies geschehen ist, beschreiben Sie im nächsten Schritt, welche Zielgrup‐ pen durch welche Ziele und mithilfe welcher Metriken erreicht werden, um daraus weitere Maßnahmen ableiten zu können. 7.1.3 Zielgruppenbestimmung Die Ermittlung der Zielgruppen kann sich an dem genutzten, agilen Framework ausrichten, wie zum Beispiel bei Scrum mit Product Owner, Scrum Master, Team und Kunde beziehungsweise Nutzer. Spätestens in den internen Projekten fällt auf, dass es weitere Gruppen gibt, die Informationen benötigen - insbesondere in der Transitionsphase von Wasserfall auf agile Methoden. Es fängt damit an, dass es einen oder mehrere Manager gibt, die das Projekt finanzieren und geht damit weiter, dass Abteilungsleiter hinzukommen, welche die Ressourcen stellen. Auch technische Leiter, die grundsätzliche Vorgaben zur technischen Umsetzung machen, wünschen sich Updates und weiterführende Informationen. Aufwändiger wird es, wenn Teams von externen Lieferanten in ähnlichen Strukturen organisiert sind. Hier werden weitere spezifische Informationen benötigt, um zum Beispiel wirtschaftlich zu arbeiten. Nun kann das beauftragende Management entscheiden, dass externe Lieferanten nicht im Fokus stehen und sich selbst überlassen sind - unserer Meinung 114 7 Status-Reporting und Metriken - Risiken und Probleme managen nach ist dies ein grober Fehler -, denn auch die externen Lieferanten sind Teil des Teams und liefern Produktteile. Die externen Lieferanten nicht beim Erstellen der Metriken einzubinden, bedeutet, wichtige Steuerungsmechanismen aus der Hand zu geben. Welche Zielgruppen ermittelt werden, unterscheidet sich von Produkt zu Produkt. Gleich sind sicher die Gruppe der Entwickler im weiteren Sinne und das Scrum Team. Bezüglich dieser Zielgruppe stellen sich sowohl intern als auch extern sehr ähnliche Fragen, die es zu beantworten gilt. Dazu gehören die Themenbereiche Qualität, Performance und Stabilität. Die Fragen, ob die Anforderungen verständlich sind und wie Wartungen und Anpassungen zukünftig handzuhaben sind, interessieren auch beide Gruppen. Es gibt Leitungsebenen, die mehr daran interessiert sind, ob sich das Projekt „on track“ befindet, welche Kriterien die Entwicklung behindern oder welche Prozessoptimierungen notwendig sind, um weitere Verbesserungen zu erzielen. Hinzu kommen verschiedene Management-Ebenen, die mehr über Kosten-Nutzen und Time to Market wissen wollen, oder wie es um die Ziele zu der Produktvision oder Business-Strategie steht. Nicht zuletzt ist für Personal- und Führungsverantwortliche sehr wichtig, wie hoch die Mitarbeiterzufriedenheit ist. Auch diese kann zum Beispiel mittels Tags pro User Story in Schulnoten oder im Rahmen von Retrospektiven gemessen werden. Eine einfache Methode, alle wichtigen Zielgruppen zu ermitteln, ist im Rahmen des Stakeholder-Managements möglich. Wenn die Stakeholder und deren Funktion und Rolle bereits bekannt sind, kann zum Beispiel in Interview-Form ermittelt werden, welche Fragen sie gerne beantwortet hätten. Dabei ist zu berücksichtigen, welchen Einfluss die Gruppen auf notwendige Entscheidungen hätten, die sich aus den Metriken ergeben. Sind es zum Beispiel Budget- oder Ressourcenverantwortliche, so kann die Zielgruppe einen hohen Einfluss auf strategische Entscheidungen haben oder durch eine gute Vernetzung im Unternehmen Hindernisse leichter aus dem Weg räumen. Eine einfache Möglichkeit, sich einen Überblick über die Art und Weise der Kommunikation zu den Stakeholdern zu verschaffen, ist die Stakeholder-Matrix (siehe Abbildung 49). Diese stellt auf einer Achse die Entscheidungsbefugnis von Stakeholdern dar, aufgeteilt in niedrig und hoch, und auf der anderen Achse das Interesse am Projekt, ebenfalls aufgeteilt in niedrig und hoch. Somit ergeben sich vier mögliche Konstellationen, die jeweils eine andere Art und Weise der Kommunikation benötigen. Hat ein Stakeholder ein geringes Interesse am Projekt und zudem auch noch eine geringe Entscheidungsbefugnis, so genügt es, diesen Stakeholder einfach über den Projektfortschritt zu informieren. Sollte ein Stakeholder mit geringer Ent‐ scheidungsbefugnis jedoch ein hohes Interesse am Projekt haben, zum Beispiel weil er fachspezifisches Expertenwissen hat, so sollte man diesen Stakeholder themen‐ abhängig mit einbeziehen. Stakeholder mit hoher Entscheidungsbefugnis müssen anders „abgeholt“ werden. Sollte ein solcher Stakeholder ein geringes Interesse am Projekt haben, so wäre es dennoch sinnvoll, ihn beratend einzubeziehen. Sollte er 115 7.1 Zielgruppen und Informationsbedarf Themenabhängig einbeziehen Zusammenarbeit sicherstellen Informieren Beratend einbeziehen N i e d r i g e s I n t e r e s s e H o h e s I n t e r e s s e Niedrige Entscheidungsbefugnis Hohe Entscheidungsbefugnis Figure 49: Stakeholder Matrix Abbildung 49: Stakeholder Matrix jedoch ein hohes Interesse haben, so ist in jedem Fall zu empfehlen, eine engere Zusammenarbeit mit dem Stakeholder sicherzustellen. Generell gilt, je mehr eine Zielgruppe das Team unterstützen kann, zum Beispiel bei der Durchsetzung von Entscheidungen, umso wichtiger wird diese Gruppe. Womit sich dann wiederum ein höherer Aufwand bei der Ermittlung der Metriken rechtfertigt. In einer simplen Tabelle (siehe Abbil‐ dung 50) mit Funktion/ Rolle auf einer Achse und Bewertung des Einflussfak‐ tors und möglichen Fragen auf der an‐ deren Achse kann durch Ankreuzen leicht erkannt werden, welche Gruppie‐ rungen (Zielgruppen) sich ergeben und worauf dabei jeweils der Fokus zu legen ist. Es ist dabei gut möglich, dass es Über‐ schneidungen gibt, aber das zeigt bereits, was bei einem Dashboard für die Ziel‐ gruppe später zu berücksichtigen sein wird. Figure 50: Zielgruppen-Mapping P r o d u c t O w n e r B u s i n e s s E n t s c h e i d e r P r o g r a m m M a n a g e r T e c h n i s c h e r L e i t e r L i e f e r a n t e n K e y - A c c o u n t … Einflussfaktor (1-10) 10 8 10 7 4 Kosten / Sprint intern und extern Nutzen / Sprint Kapazität / Sprint Kapazitätsauslastung Einhaltung von Zusagen bei Sprintinhalten … Abbildung 50: Zielgruppen Mapping 116 7 Status-Reporting und Metriken - Risiken und Probleme managen 7.2 Kennzahlen im agilen Umfeld verstehen und festlegen 7.2.1 Standard Metriken Die typischen Widgets der gängigen Tools zeigen bereits gut dargestellte Messwerte; das macht sie allerdings noch nicht zu Metriken. Zu einer Metrik gehört vorab die Definition, welche Ziele inklusiver der Zielgruppen durch welchen Metriken erreicht werden, damit daraus Maßnahmen abgeleitet werden können. Die häufigsten Standardmesselemente sind User Stories, Story Points, Stunden (im Sinne von Aufwand als Ergänzung oder anstelle von Story Points), Business Value und Zeiten. Dazu gehören unter anderem die Zuordnung von vorherigen Elementen zu Sprints oder Laufzeiten von Elementen wie Leads oder die Cycle Time. Auf diese Messelemente folgen die Auswertungen mit diversen Funktionen, wie zur Anzahl, zum Mittelwert oder zur Differenz. Typische Diagramme und Einsatzgebiete werden in den folgenden Kapiteln behandelt. 7.2.1.1 Velocity Dieser Chart ermöglicht den Vergleich von geplanten und abgeschlossenen Werten pro Sprint mit früheren Sprints (siehe Abbildung 51). Der dadurch ermittelte Wert heißt Sprintkontinuität. Genutzt wird häufig die Velocity mit Story Points, also wie viele Story Points wurden geplant und geliefert. Für die Zielgruppe der Business Verant‐ wortlichen kann dieses zur Verbesserung der Planungssicherheit führen. Anhand des Mittelwertes der Story Points aus einem vorherigen Vergleichszeitraum mit mehreren Sprints wird oft geschätzt, was im nächsten und in zukünftigen Sprints geliefert werden kann. Dieses Bild betrachtet noch nicht die Ursachen für mehr oder weniger Story Points pro Sprint, weshalb sich noch keine Maßnahmen zur Verbesserung ableiten lassen. Zudem ist eine Velocity auf Basis von Story Points mit Vorsicht zu behandeln. Hier kann es zu erheblichen Abweichungen kommen bis hin zu dem Punkt, an dem keine Muster anhand der Story Points erkennbar sind. Es gibt auch Velocity Charts auf Basis von der Anzahl der User Stories oder der Business Value. Welche Velocity auch immer genutzt wird - sichtbar wird nur, dass es Abweichung zwischen Soll- und Ist-Werten gibt. Je nach Aufwand oder Abhängigkeiten zwischen User Stories kann es zu starken Schwankungen bei den Werten von Sprint zu Sprint kommen. Bei einer Velocity mit Business Value kann die Zielgruppe der Business-Verantwortlichen immerhin erkennen, welcher Wert im Sprint erzeugt wurde. Mit Glück ist dieser schon früh im Sprint hoch, sodass es für das Business verkraftbar ist, wenn nicht alles geliefert wird. Alle Velocity-Werte (User Story, Story Points und Business Value) zusammen ergeben zumindest einen Hinweis auf die „Sprintgesundheit“, wenn diese richtig bewertet werden. In dem Beispiel zur Velocity (siehe Abbildung 51) werden sechs Sprints aufgeführt, wobei der Sprint 6 der aktuelle ist, der vermutlich circa zur Hälfte abgeschlossen ist. 117 7.2 Kennzahlen im agilen Umfeld verstehen und festlegen Zu erkennen ist zudem, dass in Sprint 1, 2 und 4 die Anzahl der geplanten User Stories nicht erreicht wurde. Im Sprint 5 wurden alle Elemente bearbeitet und im Sprint 3 wurde mehr erfüllt als anfänglich geplant war. Weshalb im dritten Sprint mehr erfüllt wurde, kann hierbei nicht ermittelt werden. Die naheliegende Annahme ist, dass die geplanten Aufgaben schneller erledigt wurden und daher weitere User Stories dem Sprint hinzugefügt werden konnten. Eine andere Vermutung ist, dass ein Entwickler aus dem Urlaub zurückgekommen ist, der bei der Planung nicht dabei war und deshalb zusätzliche Anforderungen umgesetzt wurden. Deutlich wird hierbei, dass weitere Kennzahlen notwendig sind, um treffendere Aussagen zu den Abweichungen treffen zu können. A n z a h l U s e r S t o r i e s Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 PLAN IST Figure 51: Velocity Chart mit Anzahl User Stories Abbildung 51: Velocity Chart mit Anzahl User Stories Werden viele Sprints betrachtet, so könnte, ein Mittelwert oder ein möglicher Zielkorridor ermittelt werden. In Abbildung 52 ist ein Korridor mittels der gestrichelten Linien eingezeichnet, der sich um den Mittelwert befindet. Dabei wird deutlich, dass es einen deutlichen Abfall bei der Anzahl der gelieferten User Stories gab und sich nur langsam eine Erholung einstellte, was durch die gepunktete Linie dargestellt wird. Was in der Zeit, in der die Lieferleistung unter den Erwartungen lag, passierte, kann hieraus nicht abgeleitet werden. Es könnten erneut Spekulationen erfolgen, ob es sich eventuell um eine Urlaubszeit gehandelt hat, zumal auch die Anzahl der geplanten User Stories unter dem Zielkorridor lag. Ohne ergänzende Informationen lassen sich diese Vermutungen nicht weitere spezifizieren. Selbst die Kombination mit zum Beispiel der Story Point Velocity kann kein Licht ins Dunkel bringen. Es ist daher eine wichtige Erkenntnis, dass einzelne Kennzahlen nicht ausreichen, um Risiken zu erkennen und Maßnahmen abzuleiten. Figure 52: Velocity Chart mit Zielkorridor A n z a h l U s e r S t o r i e s Sprints PLANIST Zielkorridor Abbildung 52: Velocity Chart mit Zielkorridor 118 7 Status-Reporting und Metriken - Risiken und Probleme managen 7.2.1.2 Cumulative Flow Diagram (CFD) Das Cumulative Flow Diagram (CFD) zeigt den kumulierten Anstieg von diversen Messwerten über einen definierten Zeitraum in einer Überlagerung der Werte an (siehe Abbildung 53). Der typische CFD enthält die User Stories mit Status. Es kann daraus zum Beispiel abgeleitet werden, wie viele User Stories im Backlog abgeschlossen oder in Arbeit sind. Für die Zielgruppe Management oder Business Verantwortliche kann es zeigen, wie sich das Verhältnis zwischen neuen und abgeschlossenen User Stories verhält. Wird der Abstand zwischen dem Backlog und erledigter User Stories immer größer, könnte das auf ein Problem hindeuten. Zumindest wird offensichtlich, dass mehr neue Elemente erstellt als erledigt werden. Wird der Abstand kleiner (vgl. Punkt 3 in der Abbildung 53), zeigt sich, dass mehr abgearbeitet wird als Neues hinzukommt. Wie dieses zu deuten ist, hängt von diversen Faktoren ab. Die beste Auslegung wäre sicher, dass sich das Projekt dem Ende nährt und bald alle Aufgaben abgeschlossen sind. Im schlechteren Fall könnte es einfach daran liegen, dass der Product Owner in letzter Zeit keinen neuen User Stories erstellt hat. Auffällig ist in dem unten dargestellten CFD, dass es eine Zeit gab, in der scheinbar keine User Stories bearbeitet wurden (vgl. Punkt 1 in Abbildung 53) und sich das Product Backlog später verkleinert hat (vgl. Punkt 2 in Abbildung 53). Die Zeit, in der vermutlich keine User Stories bearbeitet wurden, könnte wieder eine Urlaubszeit sein, wie zum Beispiel rund um Weihnachten. Interessanter ist der Punkt 2, bei dem das Backlog reduziert wurde, also User Stories gelöscht wurden. Dieses deutet auf einen normalen Prozess hin, der von Zeit zu Zeit nötig wird, wenn das Backlog zu viele alte Elemente enthält. Gleichzeitig ist direkt danach ein deutlicher Anstieg von neuen User Stories erkennbar, was zeigt, dass sich das Team vermutlich mit den nächsten, anstehenden Themen intensiv beschäftigt hat. Das CFD kann selbstverständlich andere Werte wie Story Points oder Business Value anzeigen. Diese beiden Werte sind in Kombination interessant für das Manage‐ ment. Sofern das Produkt zu einem gewissen Grad beschrieben, abgeschätzt und mit Business Value versehen wurde, kann anhand des gelieferten Business Values und den verbleibenden Anforderungen geprüft werden, ab welchen Zeitpunkt das Projekt voraussichtlich als abgeschlossen angesehen wird. Das ist nicht zwingend bei erreichtem 100 % Business Value und 100 % ausgeführten User Stories der Fall. Es ist möglich, dass zum Beispiel bei 80 % gelieferten Business Value und bei verbleibenden 50 % an User Stories das Projekt unter Kosten- und Nutzen-Aspekten beendet wird. 119 7.2 Kennzahlen im agilen Umfeld verstehen und festlegen Zeit User Story Product Backlog Arbeitsstatus 1 Arbeitsstatus 2 Abgeschlossen Figure 53: Cumulative Flow Diagram Zeitrahmen ohne Abschluss von User Stories Reduzierung Product Backlog Elemente Trendlinien Product Backlog und Bearbeitungsfortschrittschritt 1 2 3 Abbildung 53: Cumulative Flow Diagram 7.2.1.3 Burnup-Diagramme Im Grunde ist diese Diagrammform eine Abwandlung des Cumulative Flow Diagram (siehe Abbildung 54) mit Fokus auf ein kumuliertes Einzelelement wie die Story Points, User Story oder dem Business Value mit dem Status „Done“. Für die Zielgruppe Business Verantwortliche könnte wichtig sein, wie sich die Werte über die Zeit (zum Beispiel Wochen oder Sprints) hinweg entwickeln. Im Prinzip muss der nächste Balken für einen Zeitraum immer höher sein als der vorherige. Wenn er gleichbleibt, wurde nichts für das Einzelelement abgeschlossen. Wenn er sogar kleiner sein sollte, dann wurden Elemente wiedereröffnet. Gehen wir davon aus, dass zehn User Stories im Sprint enthalten sind und in der aktuellen Woche nur fünf davon abgeschlossen wurden, würde bei einem Diagramm mit dem Einzelelement User Story der aktuelle Balken um fünf höher sein als der vorherige Balken. Möglicherweise ist jedoch beim Business Value der Balken gleich oder nahezu gleichgeblieben. Wie kann das sein? Wenn die fünf User Stories nur einen sehr geringen oder keinen Business Value hatten, dann wurden zwar fünf User Stories abgeschlossen, ohne jedoch einen Mehrwert aus Business-Sicht zu erzeugen. Das kann passieren, wenn es zum Beispiel reine Analyse-User Stories (Spikes) gibt, die per Definition keinen Business Value liefern. Oder es sind Dokumentations-User Stories für die Online-Hilfe, denen der Product Owner einen sehr geringen Wert zuordnet. Wenn noch die Story Points als drittes Diagramm für die Gegenüberstellung zur User Story und Business Value genommen wird, kann es durchaus eine hilfreiche Metrik zur Gesamtperformance ergeben. Jedoch ist bei der Interpretation der Ergebnisse immer Vorsicht geboten. Wie bei den anderen Charts sind diese nur mit einem entsprechenden Hintergrundwissen 120 7 Status-Reporting und Metriken - Risiken und Probleme managen richtig zu deuten. So weist das nachfolgende Diagramm im ersten Abschnitt (vgl. Punkt 1 in Abbildung 54) eine geringe Steigung auf, es gibt sogar Rückschritte, was auf eine falsche Herangehensweise für Scrum hindeutet. Würde auf dieser Basis eine Prognose zum zeitlichen Projektverlauf erfolgen, könnte es zeigen, dass die Laufzeit hinter den Zielen mit den definierten Erfolgsfaktoren, wie der Zeit, zurückbleibt. Aufgrund dieser Erkenntnis könnten Maßnahmen eingeleitet worden sein, die eine deutliche Performancesteigerungen im zweiten Abschnitt zur Folge hatten (vgl. Punkt 2 in Abbildung 54). Solche Maßnahmen könnten Wissensaufbau, Veränderung der Arbeitsweisen oder eine Teamverstärkung sein. Im dritten Abschnitt (vgl. Punkt 3 in Abbildung 54) ist erneut eine reduzierte Leistung erkennbar, wenngleich diese mehr als nur deutlich über dem ersten Abschnitt liegen, aber eben hinter den Leistungen aus dem zweiten Abschnitt zurückbleiben. Die Gründe dafür können vielfältig sein. Zudem ist die Frage, ob es überhaupt ein Alarmsignal in dem unteren Beispiel ist. Teams werden über die Zeit immer Schwankungen in den Leistungen verzeichnen. Die Retrospektiven zeigen hier meist die Ursachen auf, sodass frühzeitig Maßnahmen abgeleitet werden können. Zeit U s e r S t o r y Abgeschlossen 1 2 3 Figure 54: Burnup-Chart mit User Stories Trendlinien abgeschlossener Elemente in verschiedenen Zeitabschnitten 12 3 Abbildung 54: Burnup Chart mit User Stories 7.2.1.4 Sprint Burndown-Diagramm Dieses Chart wird gerne dazu genutzt, den Fortschritt eines Sprints anzuzeigen, indem über die Zeit die abgeschlossenen Werte in einem Diagramm dargestellt werden (vgl. Punkt 3 in Abbildung 55). Eine Idealline (vgl. Punkt 1 in Abbildung 55) zeigt den gewünschten Verlauf an. Der Chart auf Basis von Aufwand und Kapazität zeigt anhand einer weiteren Linie den Verlauf der verbleibenden Kapazität an (vgl. Punkt 2 in Abbildung 55). Bei einer Planung auf Basis von benötigtem Aufwand und der Kapazität des Teams kann frühzeitig erkannt werden, ob das Team die Ziele voraussichtlich 121 7.2 Kennzahlen im agilen Umfeld verstehen und festlegen erreichen kann. Eine Schwierigkeit bei den Charts ist, dass der Aufwand je User Story durchaus erfasst wurde, ebenso wie die Teamkapazität. Jedoch werden die idealisierten Verläufe und weitere wichtige Faktoren wie die Abhängigkeiten, neue Erkenntnisse im Sprint (inklusive Mehraufwand) und die Verfügbarkeit einzelner Teammitglieder nicht berücksichtigt. Zudem bedeutet Aufwand nicht gleich Dauer. Daher kann es nur als Hinweis auf Fehlentwicklungen dienen. Die tägliche Planung im Rahmen des Daily Scrum kann damit trotzdem unterstützt werden - vor allem, wenn erkannt wird, dass sich der Restaufwand der verbleibenden Teamkapazität nähert. Das kann bei der Priorisierung für den weiteren Sprintverlauf helfen. Im umgekehrten Fall, wenn eine hohe Kapazität des Teams im absehbaren Zeitraum nicht mehr genutzt würde, kann über die Aufnahme von weiteren Product Backlog-Elementen in das Sprint Backlog nachgedacht werden, sofern es dem Sprintziel zuträglich ist und auf das nächste Produktziel einzahlt. Deutlich ersichtlich ist zudem, dass eine anfängliche Auslastung nahe der Teamkapazität keine gute Idee ist, weil Freiräume für einen Kapazitätsausgleich im Team fehlen. Wenn alle Entwickler zu fast 100 % ausgelastet sind, kann niemand unterstützen, wenn sich ein Entwickler im Aufwand seiner Aufgaben verschätzt haben sollte. Eine mögliche Konsequenz kann sein, dass das gesamte Sprintziel verfehlt wird. Besonders beliebt ist der Burndown mit User Stories. Der Wert dieser Darstellung ist allerdings fragwürdig. Wenn zum Beispiel acht von zehn User Stories einen Story Point-Wert beziehungsweise einen Aufwand von unter drei haben und zwei User Stories einen Wert von über 21, dann sieht der Sprint bereits lange gut aus, wenn die acht User Stories mit einem kleinen Story Point-Wert zuerst bearbeitet werden. Die bessere Alternative ist ein Sprint Burndown mit Story Points beziehungsweise viel besser mit Aufwand in Stunden, wie oben bereits beschrieben. Der Product Owner, die technische Leitung oder Business-Verantwortliche können dann besser erkennen, ob es eventuell Probleme mit der Sprintzielerfüllung geben wird. Die Aussagekraft der Burndown Charts hängt jedoch immer maßgeblich vom Herunterbrechen in entsprechend kleine Arbeitspakte ab. Bei großen Paketen entstehen zwar häufiger Treppenverläufe, es kann jedoch sein, dass nur Stunden abgezogen werden, was nicht zwingend zu einem Treppenverlauf führt. Das hilft nicht, wenn die Aufgabe an sich nicht abgeschlossen wurde. Daher ist der tägliche Informationsaustausch wichtiger als zwingend die Idealline zu erreichen. Seltener ist ein Burndown Chart mit Business Value. Bezogen auf das obige Beispiel mit User Stories könnte der Sprint lange gut aussehen, wenn die zwei User Stories mit dem großen Story Point-Wert zuerst bearbeitet werden, diese aber ausgerechnet einen niedrigsten Business Value haben und die anderen User Stories nicht mehr bearbeitet werden können. Hierbei ist festzuhalten, dass dann wahrscheinlich bereits ein Fehler bei der Reihenfolge oder in der Priorisierung im Sprint Backlog vorlag. Interessant ist, beide Werte zu kombinieren - mit User Stories und Story Points beziehungsweise Aufwand in Stunden in Kombination entsteht eine weitaus aussagekräftigere Auskunft zum Status des Sprints. Wie bereits im allgemeinen Teil beschrieben, zeigt sich 122 7 Status-Reporting und Metriken - Risiken und Probleme managen hier erneut, dass erst mehrere Werte in Kombination eine hilfreiche Metrik ergeben könnten. Wird noch der Business Value hinzugenommen, kann zum Beispiel bei einem Schiefstand innerhalb des Sprints noch eine Korrektur an der Bearbeitungsreihenfolge vorgenommen werden, sodass ein möglichst hoher Wert für das Sprintergebnis ent‐ steht. Wenig hilfreich ist der Sprint Burndown, wenn eine Definition of Done existiert, die erst nach gleichzeitiger UAT-Abnahme aller User Stories am Sprintende oder nach dem Sprint Review den Status auf „Done“ setzt und dies zum Beispiel erst im Rahmen der Sprint Retrospektive erfolgt. Um dann einen Fortschritt zu erkennen, müsste auf andere Werte von zum Beispiel Tasks oder die benötigte Restzeit zurückgegriffen werden. Dieses sollte nach dem aktuellen Scrum Guide jedoch nicht mehr der Fall sein, weil mehrere Inkremente je Sprint zulässig sind. 1 2 3 Zeit A u f w a n d Arbeitsfreie Zeit Figure 55: Burndown-Chart auf Basis von Aufwand und Kapazität 1 3 2 Remaining Remaining Capacity Ideal Trend Arbeitsfreie Zeit Abbildung 55: Burndown Chart auf Basis von Aufwand und Kapazität 7.2.1.5 Burnup-/ Burndown-Diagramm für Releases oder Epics Anhand historischer Datenauswertungen ermöglicht die Darstellung eine Vorschau, wann ein größeres Thema, wie ein Release oder das gesamte Projekt, abgeschlossen sein könnte (siehe Abbildung 56). Die einfachste Form ist die Vorschau anhand abgeschlossener User Stories in der Vergangenheit über einen Zeitraum, projiziert auf einen möglichen Verlauf in der Zukunft. Im Grunde ist dies ähnlich zu mögli‐ chen Ableitungen aus der Velocity und genauso wenig aussagekräftig, wenn nicht die richtigen Parameter zur Kalkulation ausgewählt oder ergänzt werden oder gar nicht erst zur Verfügung stehen. Es könnte zum Beispiel sein, dass nur wenige User Stories abgeschlossen wurden, der Untersuchungszeitraum zu klein ist oder die Entwicklung des Backlogs nicht berücksichtigt wurde. Richtig angewendet, kann dieses Chart für die Zielgruppen Product Owner, Business-Verantwortliche oder für das Management hilfreich Informationen liefern, um diese für weitere Planungen 123 7.2 Kennzahlen im agilen Umfeld verstehen und festlegen berücksichtigen zu können. In der nachfolgenden Grafik ist zu erkennen, dass die Entwicklung des Backlogs und der abgeschlossenen Elemente über einen gewissen Zeitraum erfasst wurden (vgl. Punkt 1 in Abbildung 56). Anhand dieser Informationen wird der zukünftige Verlauf des Product Backlogs und der abgeschlossenen Elemente berechnet (vgl. Punkt 2 in Abbildung 56). Dabei wird bei den zu erledigenden Aufgaben immer zwischen dem besten und dem schlechtesten Verlauf unterschieden, der zu einem Abschlussdatum in der Zukunft führt (vgl. Punkt 3 in der Abbildung 56). Die Vorhersagen werden hierbei über die Zeit immer konkreter. Bereits nach wenigen Monaten lassen sich gute Ergebnisse erzielen, sofern die äußeren Umstände nicht zu vielen Änderungen, wie einem Abbau der Teamkapazität, Personalwechsel oder größere Produktzielanpassungen, unterworfen sind. Voraussetzungen für eine gute Projektion ist, die richtigen Grundlagen früh im Projekt gelegt zu haben. Dabei sind die Kapitel zum Product Backlog in diesem Buch ein entscheidender Baustein. Zeit A n z a h l Projektion „Abschluss bekannter Backlog Elemente 1 Figure 56: Burnup-Chart / Projektion Abschlusszeit 2 3 Bisherige Entwicklung Projizierte Entwicklung Zielkorridor der Abschlusszeit Abbildung 56: Burnup Chart / Projektion Abschlusszeit 7.2.1.6 Lead Time Die Lead Time beschreibt, wie viel Zeit ein Element, zum Beispiel eine User Story, vom Erstellungsbis zum Fertigstellungszeitpunkt benötigt. Die typischen Diagramme (siehe Abbildung 57) sind für den ungeübten Betrachter gewöhnungsbedürftig und schwer lesbar. Die Punkte repräsentieren je nach Größe ein oder mehrere abgeschlos‐ sene Elemente. Die Trendlinie (vgl. Punkt 1 in Abbildung 57) zeigt den Mittelwert der 124 7 Status-Reporting und Metriken - Risiken und Probleme managen Dauer für abgeschlossene Elemente in einem Zeitraum an. Das Band (vgl. Punkt 2 in Abbildung 57) um die Trendlinie herum stellt wiederum die Standardabweichung dar. Punkte, die sich weit außerhalb der Standardabweichung befinden, werden oft als „Outliner“ (vgl. Punkt 3 in Abbildung 57) bezeichnet. Zeitlicher Verlauf B e a r b e i t u n g s d a u e r 1 2 3 Figure 57: Lead-Time Trendlinie Standardabweichung Outliner Abbildung 57: Lead Time Natürlich gibt es einfache Formen, die nur eine Linie des Mittelwertes über die Zeit anzeigen, wie in der nachfolgenden Abbildung 58 mit der Lead Time in Kombination mit der Cycle Time, die im nächsten Kapitel näher beschrieben wird. 125 7.2 Kennzahlen im agilen Umfeld verstehen und festlegen Zeitlicher Verlauf B e a r b e i t u n g s d a u e r Figure 58: Einfacher Lead-/ Cycle-Time Chart 12 Lead Time Days Cycle Time Days 1 2 Abbildung 58: Einfaches Lead / Cycle Time Chart Für die Zielgruppe Team und Business-Verantwortliche zeigt das Diagramm, wie sich die Dauer der bisherigen Elemente im Verhältnis zum Mittelwert verhält, und ob sich Änderungen in der Lead Time einstellen. Es kann ein guter Wert für verschiedene Auswertungen sein. Die häufigste Aussage der Lead Time ist, dass das Team zwischen x und y Tage von der Erstellung bis zum Abschluss einer User Story benötigt und daher davon ausgegangen werden kann, dass sich zukünftige User Stories auch in diesem Zeitkorridor befinden werden. Wird diese Aussage genauer geprüft, stellt sich die Behauptung oft als falsch dar. Das typische Problem könnte gewesen sein, dass am Anfang sehr viele User Stories für das Produkt angelegt wurden, womit der Zähler der Lead Time startete. Je nachdem wie (über-)fleißig der Product Owner hierbei war, können es User Stories für sehr viele Sprints gewesen sein. Die Lead Time für diese User Stories wird in den ersten Sprints sehr kurz gewesen sein, weil diese zeitnah erledigt wurden. Die Trendlinie zeigt nach unten, ist also positiv beziehungsweise verläuft auf einem sehr niedrigen Niveau. Das kann für eine längere Zeit so sein, aber irgendwann werden auch die Aufgaben erledigt, die bereits sehr lange im Backlog sind. Dann geht die Lead Time, und damit die Kurve, nach oben, wird also aufgrund der Outliner negativ, obwohl es durchaus positiv ist, dass auch ältere Aufgaben erledigt werden. Zu einem späteren Zeitpunkt im Projekt, nämlich wenn es sich dem Ende zuneigt, werden wieder weniger User Stories im Backlog angelegt und die Lead Time wird wieder kleiner. Werden die Kurven allerdings mit den hinterlegten Story Points oder dem Aufwand und der Priorität der User Stories bewertet, kann sich ein ganz anderes Bild ergeben, als es sich allein aus der Kurve ableiten lassen würde. Das Problem ist meist nicht die so oft benannte Team Performance, sondern ist in den Ways of Working (WoW) und in der Backlog-Gesundheit zu suchen - auch das zeigt das Diagramm unter anderem für die Zielgruppen technische Leitung oder Abteilungsleiter anhand der Outliner. Denn insbesondere zu viele und historische Elemente im Backlog sorgen meist dafür, dass 126 7 Status-Reporting und Metriken - Risiken und Probleme managen viel Aufwand zur Bearbeitung, Nachprüfung, Wiedervorlage etc. benötigt wird und damit Kapazität für die Entwicklung verloren geht. Zudem könnte es sein, dass sich alte Elemente durch die neuen Erkenntnisse erledigt haben oder deutlich überarbeitet werden müssen. Ein Alarmsignal liegt ebenfalls vor, wenn die Lead Time nahe an der sogenannten Cycle Time (Zeit vom Bearbeitungsstart bis zum Abschluss) liegt - in diesem Fall werden die User Stories wohl immer sehr kurz vor einem Sprint angelegt. Das führt oft zu unzureichend definierten User Stories und einem höheren Planungsrisiko. Ein Ziel könnte daher sein, nicht mehr Elemente im Backlog zu haben, wie in den nächsten paar Sprints abgeschlossen werden können. Dazu aber später mehr. 7.2.1.7 Cycle Time Ähnlich zu der Lead Time zeigt die Cycle Time eine Durchlaufzeit an, allerdings nicht vom Erstellungszeitpunkt, sondern vom Bearbeitungsstart bis zum Abschluss. Damit spielt es keine Rolle, wie lange sich das Element bereits im Backlog befand. Zeitlicher Verlauf B e a r b e i t u n g s d a u e r 1 2 Figure 59: Cycle-Time 12 Lösungszeitraum nach Verbesserungsmaßnahmen Lösungszeitraum vor Verbesserungsmaßnahmen Abbildung 59: Cycle Time Im Idealfall ist die Cycle Time der User Stories immer kleiner als die Sprintdauer. Hier zeigt sich auch schon ein Nutzen, wenn sehr viele User Stories eine höhere Cycle Time haben als ein Sprint dauert. Daran könnte erkennbar sein, dass der Breakdown in User Stories nicht optimal funktioniert. Jedoch erst mit weiteren Informationen lassen sich die Daten richtig interpretieren. Dazu gehört als Erstes, festzustellen, wie viel Prozent der User Stories unterhalb und oberhalb der mittleren Cycle Time liegen. Sollte das Verhältnis ziemlich ausgeglichen sein, handelt es sich vermutlich um eine realistische Cycle Time. Sind aber zum Beispiel 80 % der User Stories unterhalb der mittleren Cycle Time, dann ist diese sehr wahrscheinlich durch Outliner zu hoch. Ein Gesamtbild ergibt sich erst, wenn weitere Messwerte in die Bewertung einfließen. Das können 127 7.2 Kennzahlen im agilen Umfeld verstehen und festlegen die Priorität oder die hinterlegten Story Points sein. Auch der Task-Aufwand und die Dauer, für die eine User Story geblockt war, zum Beispiel durch Abhängigkeiten, oder welche Verweildauer es je Status gab, zum Beispiel lange Validierungszeiten, spielen dort hinein. So ist zum Beispiel eine längere Cycle Time bei User Stories mit einer niedrigen Priorität eher akzeptabel als bei User Stories mit einer hohen Priorität. Um hier nur ein zusätzliches Element herauszugreifen, wird zum Beispiel mit den Story Points erkennbar, ob die Cycle Time zu der Schätzung passt. So sollten niedrige Story Point-Schätzungen eigentlich unterhalb der mittleren Cycle Time liegen, während sich hohe Story Point-Schätzungen eher oberhalb befinden sollten. Ist das im Trend nicht erkennbar, so zeigt sich, dass die Abschätzungen möglicherweise unzureichend sind. Eine realistische Cycle Time, um eine zuverlässige Planung aufzustellen, lässt sich allein aus der Standardkurve kaum ableiten. Als erster grober Anhaltspunkt zur Durchlaufzeit von User Stories kann sie jedoch gut genutzt werden. Neben der reinen Cycle Time wird in dem obigen Graphen mittels der Standardab‐ weichung ein Band um den Mittelwert angezeigt. Dieser Korridor (vgl. Punkt 1 und 2 in Abbildung 58) kann als Planungsunterstützung genutzt werden, indem er als zeitlicher Rahmen gesehen wird, in der eine begonnene User Story voraussichtlich abgeschlossen werden kann. Dieser Korridor kann sehr groß sein, sodass eine Aussage zur Bearbeitungslänge von einer Anforderung wenig hilfreich ist. So ist im Chart in der ersten Hälfte erkennbar, dass eine lange Bearbeitungszeit benötigt wurde. Gleichzeitig wurden nur wenige Elemente in dieser Zeit umgesetzt. Der zugehörige Umsetzungs-Korridor (vgl. Punkt 1 in Abbildung 58) weist eine hohe Abweichung mit starken Schwankungen aus. In der zweiten Hälfte stellt sich eine deutliche Veränderung dar. Die Anzahl der umgesetzten Elemente ist deutlich angestiegen, wobei gleichzeitig die Umsetzungszeit deutlich kürzer wurde und über einen langen Zeitraum stabil bleibt. Der zugehörige Umsetzungs-Korridor (vgl. Punkt 2 in Abbildung 58) ist ein erheblich schmaleres Band um die Cycle Time und zeigt, dass verlässliche Aussagen zur Umsetzungszeit nun getroffen werden können. Die Gründe oder Maßnahmen, die zu dieser Verbesserung geführt haben, sind aus dem Chart nicht abzulesen. Die Erkennung der Fehlentwicklung in der ersten Hälfte mittels dieses Charts könnte auf jeden Fall der Auslöser gewesen sein, hier tätig zu werden. Bei allen Unsicherheiten mit einzelnen Kennzahlen - die Cycle Time ist eine der wichtigsten Parameter für alle projektions‐ basierten Abschätzungen und bei der Früherkennung von Fehlentwicklungen. 7.2.2 Ermittlung von Metriken Eine Metrik ist nur dann sinnvoll, wenn damit ein Ziel verfolgt wird. Jedoch stellt bereits die Definition von Zielen oftmals eine Herausforderung dar. Zielbeschreibungen wie „Es sollen mehr User Stories pro Sprint geliefert werden“ mit dem Unterziel „Vergleich der Anzahl von geplanten und gelieferten User Stories in einem Sprint“ sind nicht zielführend. Daraus kann kaum mehr abgeleitet werden als dass es eine mehr oder 128 7 Status-Reporting und Metriken - Risiken und Probleme managen weniger starke Abweichung der gelieferten User Stories in einem Sprint gegenüber der Planung gibt. Insgesamt ist die Frage nach der Anzahl gelieferter User Stories in einem Sprint an sich bereits fragwürdig. Je nach Aufwand oder Abhängigkeiten könnten es mehr oder weniger User Stories sein, die von Sprint zu Sprint sehr stark schwanken. Viel wichtiger ist hierbei, dass durch den Versuch der Zielbeschreibung unklar bleibt, warum die Daten erfasst werden, wer was mit den Daten anfangen soll und welche Maßnahmen aus den Ergebnissen abzuleiten sind. Erinnern Sie sich an die Vanity und Actionable Metrics in The Lean Startup von Eric Ries, die wir im Kapitel 7 beschrieben haben? Eine bessere Zielbeschreibung könnte sich zum Beispiel an einer sehr vereinfach‐ ten Form des Goal-Question-Metric-Modells (GQM) anlehnen. Die Zielbeschreibung würde dann in etwa wie folgt aufgebaut werden: ■ Was ist zu analysieren (zum Beispiel Prozess, Produkt, Modul, …) ■ zu welchem Zweck (zum Beispiel Optimierung, Überwachung, Planung, …) ■ mit welchem Fokus (zum Beispiel Performance, Skalierbarkeit, Qualität, Time to Market, …) ■ aus welcher Sicht (zum Beispiel Product Owner, Entwickler, Management, …) ■ in welchem Kontext (zum Beispiel Projekt, Team, Lieferant, …)? Abgeleitet daraus könnte ein Ziel lauten: ■ Analyse des Sprintprozesses ■ zum Zweck der Optimierung ■ mit Fokus auf die Planungsqualität ■ aus Sicht des Product Owners ■ für das Projekt XYZ Dieses Ziel sollte in genauere Unterziele aufgeteilt werden wie „Optimierung der Planungssicherheit für einen Sprint“ (siehe Abbildung 60) oder „Optimierung der Epic-Roadmap-Planung“. Im nächsten Schritt werden auf Basis der Zielbeschreibung und der Unterziele die Faktoren und Hypothesen mit den jeweiligen Einflüssen beschrieben. Insbesondere die Hypothesen können falsch sein - das sollten dann die späteren Metriken zeigen. Nachfolgend finden Sie ein Beispiel, das ein Abstraction Sheet für das Unterziel „Optimierung der Planungssicherheit für einen Sprint“ zeigt. 129 7.2 Kennzahlen im agilen Umfeld verstehen und festlegen Faktoren zur Zielbeschreibung: 1. Komplexitätsschätzung auf Basis von Story Points und Aufwand 2. User Stories / Tasks im Sprint pro Entwickler 1 Hypothesen: 1. Gelieferte Story Points/ Sprint sind 50% unter den geplanten Werten 2. Anzahl der parallel bearbeiteter User Stories / Entwickler ist zu hoch (WIP > 2) 2 Einflüsse auf die Faktoren: 1. Qualität der Schätzungen 2. Qualität der Anforderungsbeschreibung 3. Breakdown von Aufgaben 4 Einflüsse auf die Hypothesen: 1. Teamkapazität bzw. Kapazität von Experten für Spezialbereiche 2. Abhängigkeiten zwischen Aufgaben im Team und zu anderen Teams 3 Figure 60: QGM Abstraction Sheet Abbildung 60: GQM Abstraction Sheet Ausgehend vom Abstraction Sheet werden die einzelnen Fragen zu dem Ziel abgeleitet. Die Fragen sollten in diesem Fall die Sicht des Product Owners widerspiegeln, sie müssen über ermittelbare Indikatoren beantwortet werden können und Antworten darauf liefern, was letztlich mit den Ergebnissen anzufangen ist (zum Beispiel Ablei‐ tung möglicher Maßnahmen). Aus der Praxis können wir nur dazu raten, nicht zu viele Fragen zu stellen und diese so einfach und eindeutig wie möglich zu formulieren. Als Richtwert orientieren Sie sich an zwei bis fünf Fragen pro Ziel oder Unterziel. Zudem ist bei jeder Frage auch immer zu klären, ob es im Kosten-Nutzen-Verhältnis steht. Zu dem obigen Beispiel könnten folgende Fragen (plus Fragen zur Maßnahmenab‐ leitung) formuliert werden: ■ Wie viele Story Points werden vom Team pro Sprint im Mittel über einen definierten Referenzzeitraum geplant und geliefert? • Können die Ergebnisse zur Planung weiterer Sprints genutzt werden, sodass nicht mehr Story Points geplant werden, als im Mittel in der Vergangenheit (Referenzzeitraum) geliefert wurden? • Ist es möglich, an den Werten zu erkennen, ob eine Optimierung der Komple‐ xitätsschätzungen im Team notwendig ist? ■ Wie viele Story Points werden pro Sprint im Mittel über einen definierten Referenzzeitraum je Modul und je Teilprodukt geplant und geliefert? • Kann daraus abgeleitet werden, ob es einen unterschiedlichen Erfüllungsgrad bei einzelnen Modulen oder Teilprodukten gibt, damit Schätzungen dazu verbessert werden können? • Ist es möglich, daraus zu erkennen, ob die Kapazitäten von Experten oder Expertenwissen für spezielle Tasks in Teilbereichen von Use Stories nicht ausreichen, um gemeinsam die Sprintziele zu erreichen (Verzögerungen bei User Stories durch „Warten auf Experten“ bzw. „unzureichende Kenntnisse des Teams in speziellen Bereichen“)? 130 7 Status-Reporting und Metriken - Risiken und Probleme managen ■ Mit welchem Mittelwert pro Sprint von parallel in Arbeit befindlichen User Stories pro Teammitglied ist zu rechnen? • Kann anhand der Ergebnisse erkannt werden, ob erhöhte Mittelwerte in Bezug auf Verzögerungen und nicht gelieferten User Stories stehen, damit der Auflauf im Sprint zum Bereich „Work in Progress“ optimiert werden kann? • Könnte ermittelt werden, welche Ursachen zu parallelen Starts von User Stories führten, um die Anzahl von Work in Progress zu reduzieren? ■ Wie viele User Stories (inklusive zugehöriger Story Points) werden pro Sprint im Mittel über einen definierten Referenzzeitraum aufgrund von Abhängigkeiten und Blockern nicht abgeschlossen? • Kann damit überprüft werden, ob eine verbesserte Abstimmung innerhalb des Teams oder teamübergreifend notwendig ist? • Ist erkennbar, welche Bereiche (zum Beispiel Teams oder Module) häufig in Zusammenhang mit Abhängigkeiten und Blockern inklusive der Dauer des Zustands in Verbindung gebracht werden, damit Optimierungen in diesen Bereichen erfolgen kann? ■ Wie viele User Stories inklusive zugehöriger Story Points werden pro Sprint im Mittel über einen definierten Referenzzeitraum aufgrund von Spezifikationsklä‐ rungen der User Stories nicht abgeschlossen? • Könnte aus den Informationen erkennbar werden, dass die Definition der User Stories unzureichend war (hinsichtlich der Definition of Ready), damit eine Qualitätsverbesserung der User Stories erfolgen kann? • Ist daraus abzuleiten, dass Expertenwissen im Team fehlt, um die Spezifika‐ tionen in kürzerer Zeit zu bearbeiten? Nun ist zu prüfen, ob und wie die Daten ermittelt werden können und wie eine Darstellung der Werte in verständlicher Art erfolgen kann (zum Beispiel durch geeignete Diagramme). Sollte sich zeigen, dass sich keine geeigneten Werte finden lassen, um die Fragen zu beantworten, sollten zuerst die Fragen geprüft werden. Wenn das nicht die Ursache war, kann es auch sein, dass es bisher keine Messwerte dazu gibt. Meist sehr einfach verfügbar sind folgende Informationen zu den obigen Fragen: ■ Anzahl Story Points pro User Story im Sprint ■ Story Points pro (Sub-)Task mit zum Beispiel Tags pro User Story (zum Beispiel für Komplexität pro Modul) ■ Anzahl User Stories im Sprint je Teammitglied mit Status „in Progress“ zum Beispiel, um die Anzahl von parallelen Aufgaben in Arbeit zu vermeiden. Das Risiko ist hier die Erfassung der historischen Daten, wenn erst eine User Story im Sprint abgeschlossen ist. ■ Anzahl User Stories mit Status „geblockt“ (durch Abhängigkeiten oder manuell gesetzten Status „geblockt“). Das Risiko ist auch hier die Erfassung von histori‐ schen Daten. 131 7.2 Kennzahlen im agilen Umfeld verstehen und festlegen ■ Geplante Dauer und Komplexität und benötigte Dauer und Komplexität von Spe‐ zifikationstasks in User Stories. Alternativ können unzureichende Beschreibungen von User Stories durch Teamrückmeldung über Tags mit Schulnoten (zum Beispiel Tag: „Spec.-Quality: Note 4“) ermittelt werden. Fazit: eine eindimensionale Betrachtung (von zum Beispiel nur gelieferten Story Points pro Sprint) reicht nicht, um seriöse Maßnahmen daraus ableiten zu können. Im Schnitt werden zwei bis fünf, in Bezug zueinanderstehende, Messwerte für eine sinnvolle Metrik benötigt. Die Herausforderung besteht am Ende in der gemeinsamen, lesbaren Darstellung der Gesamtmetrik. Bei dem hier abgewandelten GQM-Modell werden im letzten Schritt wünschens‐ werte Zielwerte festgelegt. Ein ambitioniertes Ziel, das nicht gleich erreicht wird, ist besser als ein Ziel, das nach den nächsten zwei bis drei Sprints bereits erreicht oder übertroffen wurde. Diese sollten nicht die einfachen Mittelwerte von bisherigen Daten sein, sondern deutlich darüber liegen. Grundsätzlich ist zu empfehlen, immer Erwartungsbereiche anstelle eines festen Wertes zu definieren. Wenn ein einziger Ziel‐ wert benötigt wird, so kann dieser durchaus am oberen Ende des Erwartungsbereichs liegen, aber die Erwartungen sind im Prinzip erfüllt, wenn sich der aktuelle Wert im Erwartungsbereich befindet. Anhand von Erwartungsbereichen kann zudem der Status einfacher in zum Beispiel einer Ampel-Darstellung erfolgen. Um allerdings geeignete Basiswerte zu erhalten, wird eine gewisse Zeit zur Sammlung von Daten benötigt. In der Praxis sind das meist zwei bis drei Monate, bevor erste Erkenntnisse vorliegen. Anfangs könnten daher halbjährliche Prüfungen und Anpassungen der Zielwerte notwendig sein. Später sollten jährliche Prüfungen und Anpassungen ausreichen. Damit kann der Status mit einfachen, aussagekräftigen Zahlen dargestellt werden, die vielleicht nicht für das Team interessant sind, aber für eine Management-Zielgruppe durchaus. 7.3 Metriken als Präventionsmaßnahme gegen Fehlentwicklungen Eine zentrale Frage ist, welche Metriken sich besonders zur Erkennung von Fehlent‐ wicklungen eignen. Im Folgenden werden einige Metriken genauer betrachtet, die sich in der Praxis als hilfreich erwiesen haben: 7.3.1 Backlog-Gesundheit Die ersten Metriken in einem großen Projekt sollten sich auf das Backlog ausrichten. „Was soll am Backlog schon überprüft werden? “, werden sich einige fragen. Ausge‐ rechnet das auf den ersten Blick unscheinbar wirkende Backlog ist der Startpunkt für alle weiteren Entwicklungsprozesse. Für einen gelungenen Auftakt ist es von Bedeutung, sich das Backlog genauer anzusehen. Und nicht allein darauf zu hoffen, dass das Backlog Refinement alle Risiken aufzeigt oder spätestens in der Sprintplanung alles bekannt ist. Wir wollen hier nichts unnötig schwarzmalen. Für einfache Projekte 132 7 Status-Reporting und Metriken - Risiken und Probleme managen kann es durchaus ausreichen, sich auf das Backlog Refinement oder gar nur auf die Sprintplanung zu stützen. Für komplexe Projekte ist dies jedoch nicht ausreichen. Der Verlauf des Projektes wird durch die Ways of Working und der Definition, wann ein Backlog-Element vollständig ist, sodass es entwickelt werden kann, begünstigt. Diese Definition of Ready sollte sich daher frühestmöglich an den späteren Messzielen orientieren. Zudem raten wir dazu, Regeln für die Anzahl, die Komplexität und für den Business Value von Backlog-Elementen festzulegen und Maßnahmen zu bestimmen, wenn diese Werte über- oder unterschritten werden. Mit zu vielen Elementen im Backlog, insbesondere, wenn dieser gut sortiert ist und die wichtigsten Elemente sofort erkennbar oben stehen, verhält es sich manchmal wie mit Dingen im Keller: Sie geraten in Vergessenheit. Die Hoffnung, nach Jahren noch auf ein „Schätzchen“ zu treffen, das in einem „Bares für Rares“-Prozess an den Fachbereich verkauft werden kann, wird in der Regel nicht erfüllt. Wenn dann einige alte Elemente doch noch erledigt werden, verändern diese auch noch die Lead Time, sodass ein brauchbarer Messwert verloren geht, sofern nicht Outliners aus der Lead Time ausgeschlossen werden. Eine sinnvolle Maßnahme aus dieser Kennzahl könnte das Meeting „Keller aufräumen“ sein. Dabei werden alle User Stories, die älter als x Tage sind (Backlog-Verweildauer) auf den Prüfstand gestellt und gegebenenfalls aus dem Backlog entfernt. Sehr oft haben sich solche gealterten User Stories durch neue Entwicklungen bereits erledigt. Wenn die Trennung von den Elementen schwerfällt, werfen Sie einen Blick auf die Priorität, die Komplexität (Story Points) und den Business Value und überlegen nochmal, ob es wirklich noch wichtig ist. Wenn ja, planen Sie die User Story zeitnah in einen Sprint ein, bevor Sie in die Situation geraten, das Element ein zweites Mal besprechen zu müssen und damit die doppelte Zeit benötigen. Sind hingegen zu wenige Elemente im Backlog, dann kann dadurch eine gute Sprint-Planung aufgrund fehlender Auswahlmöglichkeiten erheblich behindert wer‐ den. Es kommt zu mehr und mehr Analyse-Tätigkeiten in Sprints, um neue User Stories erstellen zu können. Dieser Vorgang schafft keinen direkten Business Value. Im Backlog sollten daher immer „Ready“-Elemente für circa anderthalb bis drei Sprints zur Verfügung stehen. Ob und wie diese gekennzeichnet werden hängt davon ab, ob eine Metrik daran ausgerichtet werden soll. In diesem Zusammenhang kann die Bearbeitungszeit der Elemente im Backlog von der Erstellung bis „Ready“ in einer Art Cycle Time ermittelt werden, um zu prüfen, ob zum Beispiel der Product Owner überlastet ist. Neben der reinen Anzahl von Elementen im Backlog sind auch die Prioritäten, die Story Points, der Business Value und die Risikobewertung wichtige Faktoren bei den Metriken. Eine tiefergehende Ausführung zu den Werten, wie diese genutzt werden könnten und welche Basis die Vergleichbarkeit sicherstellt, könnte vorab in den Ways of Working definiert werden. Zum Start helfen schon einfache Messwerte zur Backlog-Hygiene wie: ■ Vergleich der Elemente im Backlog gegenüber festgelegten Zielwerten (typisch sind Elemente im Backlog für circa zwei bis drei Monate), damit es nicht zu einer 133 7.3 Metriken als Präventionsmaßnahme gegen Fehlentwicklungen Sammlung von später nicht mehr benötigten User Stories kommt. Das ist häufig der Fall, wenn eine Umstellung von Wasserfallprojekten auf agiles Vorgehen stattfindet, wobei dann schnell Elemente für die nächsten ein bis zwei Jahre vorhanden sind. Nun sind allerdings Elemente im Backlog nur selten mit einer Auf‐ wandsschätzung versehen. Außer der reinen Anzahl von User Stories im Backlog sind oft kaum weitere Informationen vorhanden. Insofern ist eine Abschätzung, wie viele Elemente in etwa eine Zeitdauer von zwei bis drei Monaten ausmachen, doch recht schwer. Es gilt zwar die Regel, dass eine User Story in einem Sprint zu erledigen sein soll, aber jede User Story mit der Sprintdauer abzuschätzen, wäre kaum praktikabel. Ein einfacher Vergleich mit der Velocity auf die Anzahl an User Stories pro Sprint gegenüber der Anzahl an User Stories im Backlog ist ebenfalls zu gewagt. Daher ist es besser, auf die Sprint Velocity der Story Points oder die User Story Cycle Time zu schauen. Der User Story-Mittelwert aus x-vorherigen Sprints könnte mit der Anzahl der Backlog User Stories multipliziert werden, um einen Anhaltspunkt zu erhalten, wie viele User Stories ein Backlog für zwei bis drei Monate umfassen sollte. Eine Projektion, wie lange eine Umsetzung der bisherigen Product Backlog-Elemente benötigt, könnte mittels eines Burnup Charts ermittelt werden. Auf diese Weise kann sehr einfach die richtige Menge an notwendigen Product Backlog-Elementen ermittelt werden. Dazu wird anhand des Inhalts des Backlogs (vgl. Punkt 1 in Abbildung 61) und der abgeschlossenen Elemente über einen gewissen Zeitraum (vgl. Punkt 2 in Abbildung 61) die voraussichtliche Zeit ermittelt, bis wann das bisherige Backlog abgearbeitet werden könnte (vgl. Punkt 3 in Abbildung 61). Sollte eine zusätzliche Unterscheidung auf Ready-Elemente im Backlog erfolgen, so sollte auch ein Vergleich gegenüber festgelegten Zielwerten (zum Beispiel „User Stories in „Ready“ für anderthalb bis drei Sprints“) erfolgen, damit die nächste Sprintplanung sichergestellt wird. ■ Verweildauer von Elementen im Backlog und die Dauer zwischen Erstellung und Übergang in den Status „Ready“ oder in einem Sprint ■ Stehen die User Stories im Sinne von Kosten-Nutzen in einem akzeptablen Verhältnis? ■ Sind die User Stories so geschnitten, dass sie innerhalb eines Sprints erledigt werden könnten? Wie zeigt sich dabei die Verteilung von User Stories auf die Story Points? Wenn viele hohe Werte enthalten sind, dann ist davon auszugehen, dass der Breakdown der Epics auf User Stories nicht gut gelingt. ■ Verteilung User Stories auf Priorität, Story Points, Business Value und Risikobe‐ wertung inklusive der Abhängigkeiten, damit das Backlog richtig sortiert werden kann und an den richtigen Dingen zuerst gearbeitet wird. Bedenken Sie dabei, dass nicht immer die User Story mit der höchsten Priorität und dem höchsten Business Value am Anfang der Liste steht - so hat zum Beispiel das Dach eines Hauses vielleicht den höchsten Business Value und die höchste Priorität, um nicht nass zu werden, wenn es regnet, aber zuerst werden trotzdem Fundament und Wände benötigt. 134 7 Status-Reporting und Metriken - Risiken und Probleme managen Zeit A n z a h l Inhalt Product Backlog Verlauf abgeschlossene Elemente Projektion Product Backlog Umsetzungszeit 1 2 3 Figure 61: Burnup Chart zur richtigen Skalierung der Backlog-Elemente Lösungszeitraum Abbildung 61: Burnup Chart zur richtigen Skalierung der Backlog-Elemente Für die Zielgruppen Business-Verantwortliche oder Abteilungsleiter könnte eine ein‐ fache Darstellung der Backlog-Hygiene reichen, die sich zum Beispiel auf die Anzahl von Elementen im Backlog gegenüber einer Zielgröße bezieht. Ist beispielsweise die Zielgröße 100 aktuell, wird jedoch ein Wert von 80 erreicht, kann man einen Erfül‐ lungsgrad von 80 % errechnen. Das kann für verschiedene Messgrößen wie User Stories, Story Points, Business Value, Priorität oder Risikolevel erfolgen. Mit einer Kombination unterschiedlicher Messwerte können auch mehr Fragen zum Status des Backlogs beantwortet werden. Viel entscheidender als möglichst viele Fragen zu beantworten ist es allerdings, die wichtigen Fragen zur richtigen Zeit für die richtige Zielgruppe mit den richtigen Datenauswertungen zu beantworten. Stellen Sie zu Beginn besser einfache Fragen, die einen hohen Nutzen und Informationsgehalt haben. Meist sind es erstaunlicherweise die einfachen Grundlagen, die später Probleme verursachen, wie zu große und nicht klar verständliche User Stories, ein unzureichendes Kosten-Nut‐ zen-Verhältnis oder einfach eine falsche Prioritätenverteilung. Im Folgenden soll an einem einfachen Beispiel mit den bekanntesten Parametern von Backlog-Elementen 135 7.3 Metriken als Präventionsmaßnahme gegen Fehlentwicklungen gezeigt werden, wie eine Darstellung der Backlog-Hygiene für zwei unterschiedliche Zielgruppen aussehen kann. Anhand von typischen Fragestellungen (vgl. oben) soll zudem geprüft werden, ob und welche Maßnahmen aus den Ergebnissen abgeleitet werden könnten. Figure 62: Detaillierter Backlog Status Chart Abbildung 62: Detailliertes Backlog Status Chart Lassen Sie uns nun gemeinsam an einem Beispiel zeigen, wie der Product Backlog-Sta‐ tus anhand der drei typischen Kennzahlen ermittelt wird. Dabei wurde mittels Burnup Chart der jeweilige Zielwert für User Stories, Story Points und Business Value ermittelt. Status der Ready-Elemente im Backlog inklusive Priorität mit den Zielgrößen (Summe): ■ User Stories: 100 aktuelle Anzahl: 60 → 60 % Erfüllungsgrad, ■ Story Points (Komplexität): 400 ■ aktuelle Anzahl: 320 → 80 % Erfüllungsgrad ■ Business Value: 3000 aktuelle Anzahl: 2100 → 70 % Erfüllungsgrad → Gesamterfüllungsgrad (Mittelwert): 70 % Für den Business-Verantwortlichen lässt sich anhand der unterschiedlichen Werte schnell erkennen, wo Handlungsbedarf besteht. Für das Management könnte zum Beispiel der Mittelwert aller Erfüllungsgrade (gegebenenfalls mit einer Gewichtung) 136 7 Status-Reporting und Metriken - Risiken und Probleme managen den Zustand des Backlogs in einer einzigen Zahl zeigen. Im Idealfall erfolgt die Darstellung im Vergleich mit einem Referenzzeitraum und einer Bewertungsskala über Ampelfarben, wozu zum Beispiel der Mittelkreis verwendet werden kann (siehe Abbildung 63). Dazu wird eine Festlegung von Bereichen benötigt, ab wann der Status auf rot, gelb oder grün steht. Zum Beispiel entspricht es rot, wenn der Wert unter 30 % liegt. Bewegt sich der Wert zwischen 30 und 60 % steht die Ampel auf gelb und auf grün, sobald mindestens 60 % erreicht wurden. In unserem Beispiel scheint sich aus Management-Perspektive eine positive Entwicklung abzuzeichnen. Es gab eine Verbesserung gegenüber dem vorherigen Zeitraum und der Status steht auf grün. Figure 63: Einfacher Backlog Status Chart Abbildung 63: Einfaches Backlog Status Chart Auf den ersten Blick wirken die Werte in Abbildung 62 für zum Beispiel den Business Verantwortlichen gut. Aus der Darstellung ergibt sich auf den zweiten Blick jedoch ein deutlicher Handlungsbedarf. Die drei Werte Anzahl User Stories, Summe der Story Points und Summe des Business Values stehen nicht im Verhältnis zueinander. So können mit dem Gesamtanteil bei vierter Priorität Themen von 14 % der User Stories bei nur 11 % der Story Points ein Business Value von 29 % erzeugt werden, wohingegen die erste Priorität Themen mit 15 % der User Stories mit 48 % des Aufwandes vergleichsweise kaum mehr Business Value (nämlich 37 %) erzeugen. Daraus lassen sich mehrere Prüfungen ableiten. So ist offensichtlich, dass zumindest einige User Stories mit der Priorität Eins vermutlich zu groß sind, zu viele Story Points und User Stories angenommen werden und der Business Value bei Themen aller Prioritätsstufen zu prüfen ist. Weitere Risiken lassen sich aus der hohen Anzahl von User Stories mit zweiter Priorität (50 %) bei einem minimalen Anteil von Story Points (16 %) erkennen, was 137 7.3 Metriken als Präventionsmaßnahme gegen Fehlentwicklungen darauf hinweisen könnte, dass es zum Beispiel zu viele zu kleine User Stories gibt, was einen hohen administrativen Aufwand bedeutet, oder der Aufwand in Story Points pro User Story schlichtweg unterschätzt wurde. Zudem wird mit einem geringen Aufwand (Story Points 16 %) doch recht viel Business Value (20 %) erzeugt. Aus reiner Kosten-Nutzen-Sicht würden hiernach zuerst die Themen mit der Prio‐ rität Vier bearbeitet werden müssen, gefolgt von den Themen der Priorität Zwei, bevor es an die höchstpriorisierten Elemente geht. Nicht berücksichtigt sind die Abhängig‐ keiten und die Sortierung des Backlogs, aus denen sich bezüglich der notwendigen Bearbeitungsreihenfolge eine andere Sicht ergeben könnte. Es wird auch hier deutlich, dass sich zwar viele Daten darstellen lassen, aber nur die kombinierte Auswertung in Bezug auf eine vorher definierte Fragestellung mit Hypothesen einen Sinn ergibt. Erkennbar ist aber bereits in diesem Beispiel, dass das Backlog nicht ausreichend bewertet wurde, und damit keine gute Vorbereitung für die späteren Prozessschritte erfolgte. Wie schon erwähnt wurde, ist das Backlog der Startpunkt und stellt damit die Vorbereitung für alle weiteren Aktivitäten dar. Denken Sie daher immer an das Motto: Eine gute Vorbereitung reduziert das Risiko von schlechten Ergebnissen. 7.3.2 Kapazität und Auslastung Nachdem die Grundlagen im Backlog gelegt sind, beginnen viele Projekte direkt mit der Planung von Sprints. Eine wichtige Größe bei jeder Sprintplanung ist jedoch die Kapazität des Teams. Neben den typischen Meetings und Abstimmungen im agilen Umfeld der Produktentwicklung, kommt in vielen Bereichen der operative Teil bei der Ende-zu-Ende (E2E) Verantwortung hinzu. Es ist nicht selten, dass das Team bei einer E2E-Zuständigkeit einen hohen Teil der Kapazität auf das operative Geschäft legen muss, sodass am Ende vielleicht noch 40 bis 60 % (oder weniger) für die Entwicklung verbleibt. Insbesondere das Verhältnis zwischen Entwicklung und operativem Geschäft ändert sich oft innerhalb der Laufzeit der Projekte. Bei der Festlegung der Zielwerte für eine Entwicklungskapazität sollte dieses bereits ebenso berücksichtigt werden wie auch sonstige Ausfallzeiten, wie zum Beispiel Krankheit, Weiterbildung oder Linienaufgaben. Gegenüber dieser verbleibenden, theoretischen Team-Kapazität kann die Auslastung gezeigt werden. Die einzelne Sprintplanung selbst sollte daher immer mit der Abfrage der Kapazität der einzelnen Teammitglieder (zum Beispiel geplante Kapazität pro Tag in Stunden und Abwesenheit innerhalb des Sprints) beginnen. Zwar sagt die Kapazität des Teams am Anfang nicht viel darüber aus, wie viele Story Points erledigt werden können, aber das ist auch nicht das erste Ziel. Für eine gute Planung ist wichtig zu wissen, wie realistisch die Zusagen des Teams zu den gestellten Aufgaben sind. Hierzu gibt es eine Reihe von Messwerten, die genutzt werden können, aber ohne die Kapazität des Teams zu kennen, ergeben sich keine belastbaren Werte. Eine erste typische Frage lautet meist: „Ist das Team mit den Aufgaben ausgelastet oder gar überlastet? “. Dazu wird ein Messwert benötigt, der auf die Kapazität umgelegt werden kann. Hier kommen in erster Linie die Story Points in Frage. Gleichzeitig ist es 138 7 Status-Reporting und Metriken - Risiken und Probleme managen mit den Schätzungen zur Komplexität in Story Points und der Überlastung des Teams so eine Sache. Ein typisches Verfahren ist, dass von vorherigen Sprints die geplante Team-Kapazität durch die Story Points geteilt wird, um zu ermitteln, wie viele Stunden auf einen Story Point fallen. In der Praxis hat sich das als sehr ungenau und als wenig hilfreich herausgestellt. Ein einfaches Beispiel ist, dass vier Teammitglieder an zwei unterschiedlichen Kompo‐ nenten (A und B) arbeiten, wobei bei Komponente A mit 13 Story Points der gleiche Aufwand in Stunden wie bei Komponente B mit nur fünf Story Points benötigt wird. Der Mittelwert aus beiden würde nur dann passen, wenn die Aufgaben je Komponente jeweils im gleichen Verhältnis stünden. Story Points sind eine gute Methode, einer User Story eine Zahl zuzuordnen, die viele Aspekte der Komplexität abdecken kann. Nicht umsonst sollen die Story Points, insbesondere bei der Nutzung der Fibonacci-Folge, einen Bereich für die Komplexität darstellen und nicht den genauen Aufwand. Diese dann, vermutlich noch mit nur wenigen Werten, wieder auf eine Zahl herunterzubrechen, ist immer ein Risiko und verleitet gleich von Story Points auf „Aufwand in Stunden“ umzuschwenken, womit es nicht besser wird. Wenn eine Umrechnung erfolgen soll, dann sollten zumindest Bereiche angegeben werden, wie ein Story Point benötigt im Mittel zwischen vier und acht Stunden. Im Idealfall sollten alle Zielwerte immer in Bereichen angegeben werden. Zur Vereinfachung erfolgt dieses in diesem Buch nur in Ansätzen. Die bekannteste Aussage in Hinsicht auf Team-Kapazität und Story Points ist meist, dass die Story Point Velocity der letzten Sprints doch allein reichen würde, um Schätzungen abzugeben, wie viele Story Points in einem Sprint voraussichtlich erledigt werden könnten. Nur wie ist es mit der Verteilung auf die Teamkapazität und auf die Teammitglieder bestellt? Sind nur ein oder zwei Teammitglieder mit Aufgaben beschäftigt, die zum Beispiel 90 % der Story Points benötigen, während fünf weitere Mitglieder nur die restlichen 10 % bearbeiten? Wie immer zeigt sich, dass eine einzeln betrachtete Größe nur unzureichende Informationen liefern kann. Zur Erinnerung: Story Points sind eine Methode, einer User Story eine Zahl zuzuordnen, die viele Aspekte der Komplexität abdecken kann. Nicht umsonst sollen die Story Points, insbesondere bei der Nutzung der Fibonacci-Folge, einen Teilaspekt der Komplexität darstellen, und nicht den genauen Aufwand. Diese Story Points im Nachgang wieder auf eine Zahl in Stunden herunterzubrechen, ist immer ein Risiko. Wenn schon eine Umrechnung erfolgen soll, dann empfiehlt es sich, wenigstens Bereiche anzugeben. So kann man festlegen, dass ein Story Point im Mittel zwischen vier und acht Stunden benötigt. Dazu sollte jedoch zuvor intensiv geprüft werden, ob sich überhaupt Muster ermitteln lassen, die eine Umrechnung von Story Points zu Aufwand überhaupt zulassen. Bei den meisten Projekten ist es in der Praxis nicht erkennbar. Eine typische Auswertung von Story Points zu Aufwand zeigt sich im folgenden Chart. 139 7.3 Metriken als Präventionsmaßnahme gegen Fehlentwicklungen Figure 64: Durchschnittlicher Aufwand Erwarteter Aufwandsverlauf Story Points Tage 1 Abbildung 64: Story Points und Aufwand Zur Vereinfachung wurde hier der Story Point-Bereich von 1 bis 21 gewählt (nach der Idee von T-Shirt-Größen: 1=XXS, 2=XS, 3=S, 5=M, 8=L, 13=XL, 21=XXL). Es wurde über einen längeren Zeitraum ermittelt, welcher Aufwand pro Story Point-Wert benötigt wurde. Auf Basis eines gewissen Referenzzeitraums von zum Beispiel drei Monaten stellt die Ideallinie (vgl. Punkt 1 in Abbildung 64) den erwarteten Umrechnungswert je Story Point-Wert in Aufwand (Tage) dar. In diesem Beispiel war demnach der Aufwand für einen Story Point etwas über 0,5 Tage. Für zwei Story Points ergibt sich ein Wert von 1,0 Tage, was noch in eine lineare Abbildung passt. Bei drei Story Points bzw. fünf Story Points wäre die Erwartung, dass sich Aufwände von 1,5 Tagen bzw. 2,5 Tagen ergeben. Auch hier sind die tatsächlichen Aufwände mit 1,2 Tagen bzw. 2,2 Tagen durchaus noch im Rahmen. Scheinbar passt der lineare Zusammenhang in den kleineren Story Point-Werten. Ein Effekt, der sich in der Praxis häufig bestätigt. Spätestens jedoch bei acht Story Points wird es merklich anders. Hier sollten es bei linearer Fortschreibung vier Tage (8 multipliziert mit 0,5) Aufwand sein. Tatsächlich ergeben sich aber nur zwei Tage Aufwand, also die Hälfte des erwarteten Wertes. Bei den weiteren Story Point-Werten bestätigt sich, dass eine lineare Fortschreibung nicht möglich ist. Alle Aufwandswerte liegen weit unter den Erwartungen. Das zeigt, dass es bei kleinen Story-Point-Werten durchaus möglich ist, Story Points mit Aufwand gleichzusetzen, jedoch bei höheren Werten nicht mehr von einem linearen Zusammenhang gesprochen werden kann. Das Fazit daraus ist, dass User Stories und Tasks so gut wie möglich definiert werden sollten, und dann so kleinteilig wie eben sinnvoll aufgeteilt werden, damit genauere Schätzungen für überschaubare Zeiträume abgegeben werden können. Eine höhere Genauigkeit mit den Story Points gegenüber der Kapazität kann durch Auswertungen auf Komponentenebene erreicht werden, sofern die Informationen zur Verfügung stehen. Neben dem Effekt, dass erkennbar wird, welche Komponenten den höchsten Entwicklungsaufwand haben, kann zusammen mit der Teammitglieder‐ 140 7 Status-Reporting und Metriken - Risiken und Probleme managen zuordnung noch differenzierter betrachtet werden, ob zum Beispiel Experten für einen speziellen Bereich oder eine spezielle Komponente überlastet sind. In der Praxis wird häufiger eine einfache Variante auf Basis von Stundenschätzungen (Aufwand) für die einzelnen Tasks der User Story anstelle von Story Points genutzt. Durch den Vergleich der verfügbaren Stunden und den geplanten Stunden (Aufwand - nicht Dauer) aller Tasks je Team und Teammitglied kann leichter eine ausbalancierte Planung erfolgen. Zusätzlich könnten weitere Informationen durch die Erfassung benötigter Stunden während des Sprints genutzt werden. Dieses ist aber oft ein Problem hinsichtlich der Erfassung von Arbeitsleistungen, und könnte nicht nur vom Team als negativ empfunden werden. Die Idee sollte mehr sein, zu prüfen, ob das Team sich bei der Planung auch realistische Ziele setzt, ohne sich zu überlasten und nicht, um das Team bei der späteren Arbeitsleistung zu kontrollieren. Wie oft haben wir bei Sprintplanungen schon erlebt, dass viele Teammitglieder nur auf die Story Points schauen und der Meinung sind, eine Aufgabe noch zu schaffen, obwohl die groben Stundenschätzungen der Tasks von anderen User Stories bereits eine deutliche Über‐ lastung aufzeigen. Es ist daher ein sehr einfaches Mittel, die Planung zu vereinfachen und einer Überlastung vorzubeugen. Es wäre möglich, direkt Stunden, statt Story Points für die User Story zu verwenden, aber damit wird nur eine Scheinsicherheit erzeugt. Außerdem geht damit der Vorteil der Story Point-Schätzung verloren. Kommen wir nun wieder auf die Zielgruppen zurück. Das Management hat Interesse daran, zu erfahren, wie eine Auslastung des Teams gegenüber den Zielwerten und im Vergleich zu einem Referenzzeitraum aussieht (siehe Abbildung 65), um daraus Maßnahmen ableiten zu können. In der Abbildung wird erkennbar, dass die Kapazität sich nur auf einem mittleren Level befindet, aber noch im grünen Bereich. Die Kapazität hat zwar gegenüber der Referenzperiode nur leicht abgenommen, aber die Auslastung ist deutlich geringer als es die Kapazität ermöglichen würde. Allein für sich betrachtet werden die Ergebnisse allerdings nur eine geringe Aussagekraft haben, gleichzeitig wird ein mögliches Problem sichtbar. 141 7.3 Metriken als Präventionsmaßnahme gegen Fehlentwicklungen Figure 65: Einfacher Kapazitätsstatus Chart Abbildung 65: Einfaches Kapazitätsstatus-Chart Für Business-Verantwortliche, wie zum Beispiel den Product Owner, ist es wichtiger, die Auslastung auch anhand von Komponenten zu betrachten, um zu erkennen, ob Überlastungen in einzelnen Bereichen vorliegen (siehe Abbildung 66). Hier wird hauptsächlich erkennbar, dass eine Überlastung an Aufgaben für die Komponenten A und D existiert, während eine Unterlast bei der Komponente C vorliegt. Bedenklich ist zudem die Komponente B, für die eine 100-prozentige Auslastung geplant wird. Zwar ist der Mittelwert der Kapazität fast im grünen Bereich (gegenüber den definierten Zielbereichen aus unseren anderen Beispielen), aber es zeichnet sich ein Problem im Sprint ab. 142 7 Status-Reporting und Metriken - Risiken und Probleme managen Figure 66: Detaillierter Kapazitätsstatus auf Komponentenbasis Abbildung 66: Detaillierter Kapazitätsstatus auf Komponenten-Basis 7.3.3 Fortschrittsstatus Im Laufe eines Sprints stellt sich immer die Frage, ob das Sprintziel erreicht wird und wie realistisch die Erreichung des Ziels ist. Abhängig von der Definition eines Sprintziels ergeben sich Messwerte, die zu einer Metrik kombiniert werden können, sodass die Fragen der unterschiedlichen Zielgruppen beantwortet werden können. Es darf dabei nicht vergessen werden, dass die Erreichung nicht allein von der Teamka‐ pazität oder der Anzahl von Aufgaben im Sprint abhängt, sondern es eine Vielzahl von Einflussfaktoren gibt. Dazu gehören beispielsweise die Teamzufriedenheit, die Qualität der Anforderungen inklusive der Abnahmekriterien, die Abhängigkeiten zwischen den Anforderungen und die übergreifende Zusammenarbeit von Teams (sowohl mit internen als auch mit externen Teams). Es kann daher leicht zu Fehleinschätzungen führen, wenn lediglich das Burndown Chart für den Sprint betrachtet wird, auf dem geschätzte Story Points oder der Aufwand in Stunden gegen geleistete Story Points oder Arbeit in Stunden über die Zeit verglichen werden. Sofern in dem Chart auch noch die verbliebene Kapazität angezeigt wird, kann dies schnell zu einer fehlerhaften Interpretation führen. Sind zum Beispiel kurz nach dem Sprintstart einige wenige zentrale Elemente aufgrund von Abhängigkeiten geblockt, werden die Entwickler an‐ dere Aufgaben beginnen, womit zunächst die Anzahl der Aufgaben in Arbeit (Work in Progress, WIP) je Entwickler steigen könnte. Diese als Zweites begonnenen Aufgaben werden zudem so schnell erledigt, dass es einen guten Burndown-Verlauf gibt. Das Burndown Chart zeigt keine Warnsignale, bis es keine anderen Aufgaben mehr gibt als die bereits geblockten, und der Sprint abrupt einen Leistungsabfall anzeigt. Bei einem anderen Szenario würden sich vielleicht die Blocker erledigen, während die als 143 7.3 Metriken als Präventionsmaßnahme gegen Fehlentwicklungen Zweites begonnenen Aufgaben noch bearbeitet werden. Auch hier gäbe es demnach eine erhöhte Anzahl von Work in Progress. Nun könnte ein Entwickler zwei oder mehr Aufgaben parallel bearbeiten, was automatisch zu längeren Bearbeitungszeiten führt. Damit werden Aufgaben nicht mehr im Sprint erledigt und werden auf spätere Sprints verschoben. In beiden Fällen kommt es also zu Verzögerungen. Wenn nun ausgerechnet die wichtigsten Elemente mit dem höchsten Business Value nicht bearbeitet werden, kann das Sprintziel nicht erreicht werden, und zwar unabhängig davon, wie viele Story Points bearbeitet wurden. Minimal sind daher also zwei Burndown Charts zu überwachen: Story Points (und/ oder Aufwand von zum Beispiel allen Tasks) und Business Value. Zusätzlich sollte der Aufwand von geblockten Elementen gegenüber der Restkapazität über die Zeit aufgezeigt werden, um zu ermitteln, ob diese Elemente noch innerhalb des Sprints erledigt werden könnten, wenn die Blocker aufgelöst werden. Falls nein, so ist über eine Alternative für dieses Element nachzudenken oder darüber, ob die freiwerdende Entwicklungskapazität in anderen Bereichen den Sprint unterstützen kann. Ein zusätz‐ licher Abgleich von der Anforderungspriorität und der Risikobewertung gegenüber der Bearbeitungsreihenfolge inklusive des Business Values hilft, die richtigen Dinge zuerst zu bearbeiten, um damit den Wert des Produktes am Ende des Sprints zu maximieren. Die einfachste Darstellung zur Prüfung des Status würde sich aus verschiedenen Standard-Charts zusammensetzen lassen. Bei den bisherigen, sehr generischen Ziel‐ gruppen Management und Business-Verantwortliche wäre eine Darstellung aus ver‐ schiedenen Charts eventuell für die Business-Verantwortlichen vertretbar. Für die Zielgruppe Management ist eher eine einfache Form (siehe Abbildung 67) zu wählen, die den Soll-Ist-Zustand für zwei bis drei Messwerte (typisch Story Points, Business Value und Kapazität) aufzeigt, die im Mittelwert oder gewichtet eine Statusbewertung abgeben. Figure 67: Einfach Chart Sprint Status Abbildung 67: Einfaches Sprint Status Chart 144 7 Status-Reporting und Metriken - Risiken und Probleme managen Aus dem sehr einfachen Chart lässt sich entnehmen, dass der aktuelle Status auf gelb steht. Grund hierfür ist die Abweichung der Soll-Ist-Werte aus den Mittelwerten von Story Points und Business Value. Auffällig ist, dass zwar aktuell ein hoher Erfüllungs‐ grad bei den Story Points vorliegt, aber sich ein Risiko hinsichtlich des erreichbaren Business Values zeigt. Aufgrund des aktuellen Soll-Wertes ist zu prüfen, warum nicht User Stories mit höherem Business Value bearbeitet wurden. Gegebenenfalls ist eine Anpassung notwendig. Ein hohes Risiko bei der Beurteilung des Sprintfortschritts liegt oftmals in den Story Points. Wie bereits ausgeführt, stehen Story Points bei höheren Werten meist nicht in einem linearen Zusammenhang zum Aufwand. Bei der Beurteilung des Fortschritts ist zum einen Teil sicher der Aufwand wichtig, aber ein anderer Teil ist die Dauer einer Aufgabe. In der nachfolgenden Grafik soll das Beispielprojekt mit der Auswertung für Story Points erneut betrachtet werden - dieses Mal aus Sicht der Dauer je Story Point. Dazu wurde die Cycle Time je Story Point-Wert ermittelt und mit einer Idealline (vgl. Punkt 1) auf Basis der Umrechnung von Story Points in eine Dauer in Tagen ermittelt. Figure 68: Durchschnittliche Cycle Time Erwarteter Verlauf Cycle Time Story Points T a g e Abbildung 68: Cycle Time je Story Point-Gruppe Aus dem Chart ist ersichtlich, dass die Dauer von Elementen gegenüber den geschätz‐ ten Story Points in keinem Verhältnis steht. Erstaunlicherweise ist in diesem Fall über einen Zeitraum von mehr als einem Jahr kein erkennbares Muster entstanden. Nun sieht es so aus, als wären zumindest alle Elemente mit einer Abschätzung von 21 Story Points auch die Elemente, die am längsten benötigen. Allerdings zeigt sich oft bei weiteren Analysen, dass nur wenige Elemente mit 21 Story Points abgeschätzt wurden. Daher ist die Aussagekraft am geringsten. In der Praxis ist immer wieder erkennbar, dass Aufgaben, wenn sie noch neu und nicht genau bekannt sind (oder schlechtere „Noten“ bei der Bewertung der Qualität erhalten haben), hinsichtlich der Dauer eher überschätzt werden. Gleichzeitig werden bekannte und gut beschriebene Aufgaben zu gerne in der Dauer unterschätzt, wenngleich der Aufwand meist recht gut beurteilt 145 7.3 Metriken als Präventionsmaßnahme gegen Fehlentwicklungen wird. Der Effekt scheint sich immer wieder zu verstärken, wenn folgendes Vorgehen angewendet wird. Zuerst werden in Sprints kleine und gut bekannte Aufgaben angegangen, um sich dann nach kurzer Zeit, wenn sich das Team ein wenig eingespielt hat, auf komplizierte Aufgaben zu stürzen, da sich im Team die Meinung ausbildet, kleinere und einfachere Aufgaben wären problemlos leistbar und können somit nach hinten geschoben werden. Die Folgen sind meist, dass zunächst der WIP steigt, und damit oft auch der Stress. Außerdem scheint hier ein klares Kommunikationsproblem zu herrschen, da womöglich die Priorität des Product Owners nicht beachtet wird. Es ist daher von entscheidender Bedeutung, dass das Team fokussiert und nach Priorität die Aufgaben bearbeitet. Aufgrund dieser Ergebnisse ist zu empfehlen, den Story Points nicht zu viel Aufmerk‐ samkeit hinsichtlich des Fortschritts im Sprint zu widmen. Deutlich aussagekräftiger zur Erkennung von Problemen im Sprint und zur Ableitung entsprechender Maßnah‐ men sind Aufwand und Cycle Time. 7.3.4 Sprint Performance Nach dem Abschluss eines Sprints ist eine Prüfung der erreichten Ergebnisse hilfreich, um Abweichungen bewerten und Maßnahmen ableiten zu können. Am häufigsten sind dabei Messwerte anzutreffen, wie sie auch für die Statusbewertung eines Sprints (also bestehend aus Burndown Charts) oder in der Velocity anzutreffen sind. Dazu gehören meist die Anzahl der User Stories, die Summe der Story Points und die Summe des erzeugten Business Values. Hinzu kommen typische Werte wie Anzahl und Laufzeit geblockter Elemente, Verweildauer je Prozessschritt, Anzahl der Bugs, Anzahl der Code Drops oder Builds und Lines of Code, um nur einige zu nennen. Zu empfehlen sind weitere Werte wie die Qualität der Anforderung und die Zufriedenheit des Teams mit dem Sprint anhand von Bewertungen jeder User Story durch das Team. Dieses kann einfach mittels Tags pro User Story in Schulnoten gemessen werden. Anhand der Ergebnisse können tiefergehende Analysen erfolgen, zum Beispiel in welchem Produktteil besonders schlechte Noten verteilt wurden, und wie sich dieses auf die Laufzeit von Elementen auswirkt. Mit diesen Informationen können dann, zum Beispiel im Rahmen der Retrospektiven, die Ursachen und Maßnahmen deutlich einfacher besprochen werden. Alle Messwerte sind in passender Kombination ein Teil der Metrik. Ein weiterer bedeutender Teil ist die tatsächlich eingesetzte Kapazität in dem Sprint (vgl. vorheriges Kapitel), um eine Bewertung der Performance vornehmen zu können. Wie immer ist zu beachten, an welche Zielgruppe die Ergebnisse ausgerichtet sind. Bei den bisherigen Zielgruppen Management und Business-Verantwortliche könnte für das Management wieder eine Zusammenfassung aus verschiedenen Messwerten genutzt werden. Ein sehr einfaches Beispiel ist im nachfolgenden Chart zu sehen, bei dem die drei häufigsten Kennzahlen bestehend aus Anzahl User Stories, Summe Story Points und Summe Business Value gegenüber Zielwerten verglichen wird. Über einen Mittelwert (wird ein Gesamtergebnis des Sprints im Mittelkreis aufgezeigt. 146 7 Status-Reporting und Metriken - Risiken und Probleme managen Gegebenenfalls kann auch eine entsprechende Gewichtung vorgenommen werden, falls eine der drei Kennzahlen gegenüber den anderen für das Management wichtiger ist. Die Bewertung erfolgt erneut über Ampelfarben zur schnelleren Erfassung Hierbei ist in dem Chart eine deutliche Verbesserung von 29 Prozentpunkten gegenüber eines Referenzzeitraums erkennbar, wenngleich das Ergebnis mit 57 % noch im „gelben Bereich“ liegt. Figure 69: Einfacher Chart „Sprint Performance“ Abbildung 69: Einfacher Chart zur Sprint Performance Für Business-Verantwortliche ist der Vergleich zwischen Planung und Ergebnis zu‐ sätzlich relevant. Zudem ist für eine Bewertung der Vergleich mit den Zielbereichen hilfreich. Es könnte gezeigt werden, welcher Anteil je Kennzahl auf geblockte und nicht erledigte Aufgaben entfallen ist, oder wie viele Elemente nicht abgearbeitet, also offengeblieben sind. Im folgenden Chart sind einige typische Punkte zusammengefasst. Dabei fällt unter anderem auf, dass ein hoher Business Value von 87 % erreicht wurde, obwohl rund 20 % der Aufgaben, welche die restlichen 13 % Business Value erzeugen würden, nicht bearbeitet werden konnten. Eine andere wichtige Aussage für Business-Verantwortliche ist, dass 80 % der User Stories mit einem Business Value von 87 % in nur 65 % der Zeit bearbeitet wurden. Die zweite Aussage ist jedoch insofern als kritisch zu sehen, als dass Story Points synonym für Zeit verwendet werden. Im vorherigen Kapitel haben wir jedoch gezeigt, dass dieser Zusammenhang nicht zwingend gilt. 147 7.3 Metriken als Präventionsmaßnahme gegen Fehlentwicklungen Figure 70: Detaillierter Chart „Sprint Performance“ Abbildung 70: Detaillierter Chart zur Sprint Performance 7.4 Herausforderungen, Widerstände und Lösungsansätze Über die Weiten der einfachen Scrum-Welt hinaus gibt es viele Herausforderungen, die Scrum als taktische Umsetzungsmethode nicht immer vermeiden kann. Es fängt bei der Gruppe an, die zu einem Team werden soll, geht bei der Einigung über einzusetzende Tools und Architekturen weiter und endet noch lange nicht damit, dass man sich über eine übergreifende Führung im Rahmen der Skalierung einigen muss. Die Herausforderungen, insbesondere wenn die Idee aufkommt oder sogar schon der erste Schritt gemacht wurde, agile Arbeitsweisen einzuführen, sind vielfältiger als es Scrum abdecken kann. Wichtig ist daher, abschätzen zu können, in welchem Stadium von Herausforderungen sich das Vorhaben befindet. Dazu gibt es in der Theorie mehrere Varianten und Ausführungen. Bei den meisten Varianten wird davon ausgegangen, dass sich ein agiles Vorhaben in genau einer Phase befindet und, wenn eine Phase der Herausforderungen überwunden ist, startet die nächste (siehe Abbildung 71). 148 7 Status-Reporting und Metriken - Risiken und Probleme managen Methoden Team Werkzeuge Ausrichtung & Skalierung Führung A u s w i r k u n g e n Zeitliche Abfolge Produkt Nutzen Produkt Finanzierung Reorganisation Figure 71: Beispiel von Phasen unterschiedlicher Herausforderungen Abbildung 71: Beispiel von Phasen unterschiedlicher Herausforderungen 149 7.4 Herausforderungen, Widerstände und Lösungsansätze In der Praxis lassen sich in vielen agilen Vorhaben kaum einzelne feste Phasen, sondern eher Cluster von Phasen erkennen. Diese Cluster der Herausforderungen bestehen aus mehreren Elementen, die in unterschiedlicher, paralleler und wiederholender Reihenfolge auftauchen und sich gegenseitig beeinflussen. In Bezug auf die obige, sehr einfache Darstellung wird eine Produktausrichtung mit einer Skalierung der agilen Methoden automatisch mindestens Auswirkungen auf die Teams und Tools haben. Spätestens eine Reorganisation wird sich auf die vielen vorherigen Phasen auswirken. Die Auswirkungen oder die Herausforderung nehmen nicht mit jeder Phase zu. So kann die Herausforderung für zum Beispiel Tools und Architektur viel geringer sein als ein Team zu formen, weil es für diese keine Vorgaben gibt. Allerdings lassen sich Muster der Zusammenhänge erkennen, die es erleichtern, die nächsten Herausforderungen besser einzuschätzen und entsprechende Vorbereitungen zu treffen. 7.4.1 Herausforderung „agile Methoden“ Typische Startbereiche sind das Arbeitsumfeld mit den richtigen Methoden zur Pro‐ blemlösung, das Formen des Teams mit agilen Arbeitsweisen und das Produkt selbst. Je nachdem ob es ein neues Produkt ist oder ein bestehendes weiterentwickelt wird, stellt sich die Frage, warum soll es mit Scrum erfolgen beziehungsweise weshalb soll eine Umstellung auf Scrum erfolgen? Dazu sollte vorab geprüft werden, ob Scrum die richtige Umsetzungsmethode ist. Da sich Scrum mittlerweile als das am häufigsten verwendete Rahmenwerk etabliert hat, stellt sich zurecht die Frage, weshalb das richtige Vorgehen erst noch geprüft werden soll. Da jedes Unternehmen und jedes Produkt seine besonderen Eigenheiten haben, kann die Produktentwicklung nur dann erfolgreich werden, wenn das passende Vorgehensmodell gefunden und nicht einfach ein populäres übergestülpt wird. Eine Erstbewertung des Produktes ist deshalb entscheidend, um zu prüfen, ob das Produkt zu Scrum passt. Der erste klassische Ansatz ist der Blick auf die Stacey Matrix (siehe Abbildung 72) in Kombination mit dem Cynefin Modell. 150 7 Status-Reporting und Metriken - Risiken und Probleme managen Einfach Kompliziert Komplex Chaotisch Wasserfall Agilität Wasserfall Agilität Agilität Wie (Technologie/ Prozess) bekannt unbekannt W a s ( A n f o r d e r u n g e n ) k l a r u n k l a r Figure 72: Stacey Matrix Abbildung 72: Stacey Matrix Man spricht von einem einfachen System, wenn vor Beginn eines Vorhabens bekannt ist, was konkret umzusetzen ist und in welcher Art und Weise dies erfolgen soll. Einen Plan auszuarbeiten, gestaltet sich dann einfach. Für alle Anforderungen sollen die Beziehungen zwischen Ursache und Wirkung eindeutig sein. Dies ermöglicht eine eindeutige Lösung. Das Umsetzungsverfahren dazu wird meist „Best Practice“ oder „Wasserfall-Methode“ genannt. Ein komplexeres System wird es, wenn zwar ein klarer Bezug zwischen Ursache und Wirkung existiert, es aber ohne weiteres Wissen nicht möglich ist, das Verhalten vorherzusehen. Es gibt also mehrere, unterschiedliche Einflussfaktoren in Bezug auf die Wirkung, die nicht klar zu erkennen sind. Erst durch weitere Analysen können diese Zusammenhänge ermittelt werden. Ob in diesem Fall ein Wasserfall-Modell oder eine agile Arbeitsweise zum Tragen kommt, hängt von dem Grad der bekannten Ein‐ flussfaktoren ab. Je offensichtlicher diese sind, umso höher ist die Wahrscheinlichkeit, dass das Wasserfall-Modell die bessere Entscheidung ist. Dies ist besonders dann der Fall, wenn es um politische Entscheidungen mit entsprechenden Verhandlungen geht und weniger darum, eine Entscheidung auf Bewertungen aufzubauen, die sich auf neue Erkenntnisse durch Analysen stützen (agile Methoden). Komplizierter wird es, wenn mehrere Beziehungen zwischen Ursache und Wirkung bestehen. Dabei sind nicht nur die Einflussfaktoren unbekannt, sondern auch inwie‐ weit diese sich in der Kombination gegenseitig beeinflussen. Das Ergebnis scheint zu sein, dass sich neue Eigenschaften oder Strukturen je nach Kombination der Einflussgrößen herausbilden, die erst im nachherein erkennbar sind. Diese können nur durch Analysen und Experimente von Experten herausgefunden werden. Dafür eignet sich am besten ein agiles Vorgehen mit entsprechenden Iterationen. 151 7.4 Herausforderungen, Widerstände und Lösungsansätze Chaotisch wird das System, wenn kein systematischer oder logischer Zusammen‐ hang zwischen Ursache und Wirkung erkennbar ist. In diesem Fall kann auf Analysen verzichtet werden, das Handeln steht im Vordergrund. Ziel ist es, das chaotische System Stück für Stück anzugehen und dabei eine Wirkung zu erzielen. Anhand der Wirkung versucht man zu erkennen, welche Zusammenhänge bestehen, um darauf in der Form zu reagieren, dass das System stabilisiert wird. Wie bei den komplexen Systemen ist hier eine agile Methode die beste Wahl. Sofern nicht ersichtlich wird, mit welchem der Typen die Organisation umzugehen hat, wird die Handhabung problematisch. Die zielführendste Lösung ist in diesem Fall, so viele Informationen wie möglich zu sammeln und anschließend zu prüfen, in welchen Bereich das System passt. Hierzu ist ein agiles Verfahren sicher eine gute Idee, aber dazu etwas später mehr. Die vorige Bewertung ist nur ein Schritt Richtung Auswahl der richtigen agilen Methode, denn die Methode sollte für den jeweiligen Kontext geeignet sein. So ist der Einsatz von Scrum in einem chaotischen System möglicherweise nicht die richtige Wahl, wenn dieses aus Kundensicht näher betrachtet werden sollte. In diesem Fall eignet sich „Design Thinking“ besser als agile Methode. Dazu helfen in der Praxis neben der zuvor besprochenen Ursache-Wirkung-Beurteilung zusätzlich die Faktoren, auf welche Gruppe das Modell primär ausgerichtet sein und für welchen Abschnitt in der Lebenszeit des Produkts das Verfahren genutzt werden soll. Anhand dieser drei Faktoren kann eine Klassifizierung vorgenommen werden. Wie in Abbildung 73 zu sehen ist, beziehen sich Ursache und Wirkung auf die bekannte Stacey Matrix mit den vier Unterscheidungen von „Einfach“ bis „Chaotisch“. Der zweite Punkt betrachtet die Ebenen, auf die sich die agile Methode primär ausrichtet. Hier sind drei mögliche Unterscheidungen in Bezug auf den Kunden/ Nutzer, das Team und die Steuerung des agilen Umfelds im Unternehmen getroffen worden. Insbesondere die Steuerung von mehreren Teams für ein Produkt stellt hierbei eine Herausforderung dar, die im Kapitel 8.1 näher beschrieben wird. Der dritte und letzte Punkt beschäftigt sich mit dem wichtigen Aspekt des Lebenszyklus eines Produkts, der in Erkundung, Prüfung, Ausbauen (Weiterentwicklung) und Erhalten (Maintenance) unterschieden wird. Anhand dieser drei Punkte kann besser erkannt werden, welche agile Methode einzusetzen ist. Dabei ist eine Kombination unterschiedlicher Methoden über die Zeit ein sehr guter Ansatz. So ist eine häufige Empfehlung mit Design Thinking zu starten, um die Kunden-/ Nutzerprobleme besser zu erfassen und erste Problemlösungen zu erarbeiten. Nach dieser Erkundungsphase wird im zweiten Schritt mittels der Lean Startup-Methode überprüft, welches die besten Wege sein könnten, um die Problemlösung anzugehen. Dazu gehören auch erste, minimal funktionsfähige Produkte (MVP), um Ideen und Hypothesen überprüfen zu können. Im letzten Schritt erfolgt eine Weiterentwicklung des Produkts mittels Scrum. Es wird damit deutlich, dass Scrum nicht für jedes Problem das richtige Werkzeug ist und eben am besten funktioniert, wenn die Probleme bereits verstanden wurden und 152 7 Status-Reporting und Metriken - Risiken und Probleme managen mögliche Lösungsansätze existieren - also Vision und Produktziele formuliert werden können (siehe Kapitel 5.1). Life Cycle Ausrichtung Ursache & Wirkung Team Steuerung Kunde/ Nutzer Einfach Kompliziert Chaotisch Komplex Design Thinking Chaotisch Komplex Kunde/ Nutzer Team Erkundung Kanban Komplex Kompliziert Team Erhalten Ausbauen SCRUM Kompliziert Team Ausbauen Lean Startup Chaotisch Komplex Kunde/ Nutzer Überprüfung Auswahl agiler Methode Ursache-Wirkung Ausrichtung Life Cycle Erkundung Überprüfung Erhalten Ausbauen Überprüfung Überprüfung Figure 73: Übersicht zur Auswahl agiler Methoden Abbildung 73: Auswahl agiler Methoden 153 7.4 Herausforderungen, Widerstände und Lösungsansätze 7.4.2 Herausforderung „Team“ und „Werkzeuge“ In der Hoffnung, dass die richtige, agile Methode zur Umsetzung identifiziert wurde - nehmen wir an, es handelt sich um Scrum - kommt meist das Herausforderungscluster Team und Werkzeuge. Als erstes fällt auf, dass eine Gruppe von Experten noch lange kein Team ergibt. Da hilft es auch nicht, das Arbeitsumfeld so zu gestalten, dass es jung, frisch und hipp wirkt. Ansprechend gestaltete und offene Arbeitsbereiche allein helfen nicht, wenn alle Führungsebenen die Teams in unterschiedlichen Abteilungen organisieren und leiten. Daher ist ein Umdenken auf allen Ebenen notwendig, um agile Methoden im Unternehmen einführen zu können. Bleiben wir aber bei der Methode Scrum. Hierfür wird eine Gruppe von Experten benötigt, die die Verantwortung haben, eine Lösung für ein Problem zu entwickeln. Das Verständnis über die Tätigkeiten des Product Owners ist weniger scharf. Dieser wird gelegentlich nur als Teilzeitkraft im Scrum Team eingesetzt, da er mit vielen anderen Aufgaben betraut ist und die Meinung vorherrscht, das Team sei für die Umsetzung zuständig. Es erfolgt an dieser Stelle bereits eine erste Unterscheidung in „das Team“ und den Product Owner, der sich nicht zwingend als Teil des Teams sieht, sondern oftmals als derjenige, der die Anforderungen formuliert. Da auch die Tätigkeiten des Scrum Masters in der Praxis unterschätzt werden, besetzen Organisationen diese Stelle manchmal gar nicht oder mit unerfahrenen Scrum Mastern. Aus einer Gruppe ein Team zu formen und gleich‐ zeitig neue Arbeitsmethoden einzuführen, ist eine zeitintensive Herausforderung. Die richtige Teambesetzung ist daher ein wichtiger Erfolgsschlüssel (siehe Kapitel 4). Insgesamt ist jedoch die Bildung eines Teams (siehe Kapitel 4.5) und die Einführung von Scrum als Methode selten ein großes Problem - insbesondere, weil das Rahmenwerk sehr klar ist und sich erste Erfolge meistens schnell einstellen. Große Herausforderungen finden sich in der Einstellung zu der neuen Vorgehensweise und der damit verbundenen Prozesse. Wenn die Mitglieder der Gruppe aus einer langen Reihe von Wasserfallprojekten kommen, führt die neue Arbeitsweise häufiger zu Unbehagen. Es wird nicht mehr genau gesagt, was umzusetzen ist, selbst Verantwortung zu übernehmen war nur im Rahmen der zugewiesenen Aufgaben aus dem Projektplan notwendig. Es fanden vorher gefühlt weniger Meetings statt, da jeder durch den Plan genau wusste, was bis wann zu erledigen ist. Darauf konnte auch der Urlaub gut abgestimmt werden und es gab keine ständigen Änderungen im Projekt. Alles war im Vorfeld genaustens definiert und spezifiziert. Der ständige Kontakt zu einem Product Owner, der die Kundensicht einnimmt, kann als anstrengend und störend empfunden werden. Bisherige Tools, Reports und andere Arbeitsmittel können nicht mehr verwendet werden und wurden durch neue ersetzt. Durch die vielen Veränderungen kann ein Gefühl des Kontrollverlustes entstehen, obwohl genau das Gegenteil der Fall ist. Mit dem agilen Vorgehen liegen mehr Informationen vor und die engen Abstimmungen zeigen zu jeder Zeit den Stand der Dinge auf. Korrekturen können kurzfristig umgesetzt werden und selbst Prozessverbesserungen werden schnell etabliert. Dazu sind die Retrospektiven ein sehr gutes Mittel. Trotzdem macht die Umstellung viele Experten unzufrieden und sie werden ärgerlich, weil immer alles besprochen werden muss. Der Wunsch, in Ruhe zu 154 7 Status-Reporting und Metriken - Risiken und Probleme managen arbeiten, kann bei agilen Vorgehensweisen nicht mehr in der gewohnten Form erfüllt werden. Der Umgewöhnungsprozess kann Monate oder gar Jahre dauern. Zeit, die oft nicht zur Verfügung steht. Daher ist es so wichtig, einen sehr erfahrenen Scrum Master einzusetzen, der mit Methodik, gutem Unterricht und Coaching allen Teammitgliedern hilft, in kurzer Zeit zum Teil des Teams zu werden. Die neue Art und Weise, eine Anforderung zu erfassen (siehe auch Kapitel 5.3) kann eine weitere Herausforderung bedeuten. Die Art, die Anforderungen in mehreren Schritten bis auf die Ebene der User Stories und Tasks herunterzubrechen, stellt die meisten Experten vor völlig neue Herausforderungen. Der Widerstand gegen die Methode wächst zusätzlich, wenn Aufgaben nicht innerhalb der Sprints erledigt werden. Daher ist es hilfreich, eine der wohl wichtigsten Kennzahlen - die Cycle Time - regelmäßig anzuschauen. Wie bereits im Kapitel 7.2.1.7 beschrieben, geht es dabei um die Zeit vom Start bis zu Abschluss der Umsetzung. Die Cycle Time sollte auf Ebene der User Stories und der Tasks getrennt bewertet werden. Dabei hilft es, die Cycle Time der User Stories, die Aufwandschätzungen, die Priorität und die Risikobewertung in Relation zu setzen. Fällt dabei auf, dass die Cycle Time ab einer erkennbaren Schwelle bei der Aufwandschätzung zu lang wird, sind diese User Stories in Zukunft weiter herunterzubrechen. In gleicher Art erfolgt die Auswertung auf Basis der Priorität und Risikobewertung. Insbesondere bei der Priorität ist darauf zu achten, dass sich mehr User Stories mit hoher Priorität in einem Sprint befinden als mit niedriger Priorität. Bei der Risikobewertung ist zu prüfen, ob die hohen Risikolevel besonders hinsichtlich der Cycle Time auffallen. R i s i k o l e v e l Cycle Time in Tagen XL L M S Figure 74: Chart Cycle Time je Risikolevel Abbildung 74: Chart Cycle Time je Risikolevel 155 7.4 Herausforderungen, Widerstände und Lösungsansätze Wenn sich über einen Kontrollzeitraum Muster abzeichnen, ist zu prüfen, ob die User Stories in Zukunft weiter analysiert werden sollten, die einer auffälligen Risikoklasse zugeordnet sind. Eine weitere Vergleichsgröße mit der Cycle Time ist die Bewertung der User Stories mittels Schulnoten. Häufiger mögen Menschen in Gruppen nicht so offen sein, wie es nötig wäre. Daher geben diese auch gerne bessere Noten für eine User Story als es richtig wäre. Sollte sich hier ein Muster ergeben, kann ein Handlungsbedarf zum Beispiel schon bei einer Vier vorliegen, wenn die Cycle Time signifikant länger ist als es zu erwarten wäre. Bei der Beurteilung der Cycle Time für einen Sprint ist Vorsicht geboten. Wenn die Cycle Time einer User Story größer ist als die Sprintlänge, dann wirkt sich die Cycle Time, je nach eingesetztem Tool oder Verfahren, erst im nächsten Sprint aus - und zwar negativ auf diesen neuen Sprint und nicht auf den Sprint, in dem die User Story gestartet wurde. C y c l e T i m e Sprints mit Prioritätsverteilung Zielbereich 1 2 Figure 75: Bewertung Cycle Time / Sprint 1 2 Auffälliger Sprint oberhalb des Zielbereichs Auffälliger Sprint unterhalb des Zielbereichs Abbildung 75: Bewertung Cycle Time/ Sprint Wenn also fünf User Stories im Sprint Zehn (siehe Punkt 1 in Abbildung 75) gestartet wurden, aber erst in Sprint 13 (siehe Punkt 2 in Abbildung 75) geschlossen werden, sieht es so aus, als wäre das Problem in Sprint 13 aufgetreten. Das Problem lag aber im Sprint Zehn, in dem die User Stories nicht abgeschlossen wurden. Genauso können die verschobenen Elemente für einen späteren Sprint positiv aussehen, wenn zum Beispiel die Velocity auf Basis von User Stories im Sprint beurteilt wird. Gehen wir davon aus, dass im Schnitt zehn User Stories pro Sprint abgeschlossen werden können. Würden also unsere vorherigen fünf User Stories aus Sprint Zehn in Sprint 13 abgeschlossen, gab es zwar ein erkennbares Problem in Sprint Zehn, weil nur fünf Elemente abgeschossen wurden, aber der Sprint 13 war der Wahnsinn, weil vielleicht 13 User Stories abgeschossen wurden. Auf den ersten Blick wird nicht erkannt, dass der Sprint wahrscheinlich eher mittelmäßig war, denn der Aufwand in Sprint 13 für die fünf User Stories aus Sprint Zehn war vermutlich mittlerweile nur noch sehr niedrig. An diesen Beispielen ist erkennbar, dass eine sinnvolle Interpretion der Metriken nur möglich ist, wenn die hierfür notwendigen Informationen vorliegen und genügend Erfahrung vorhanden ist, diese zu deuten. 156 7 Status-Reporting und Metriken - Risiken und Probleme managen 7.4.3 Herausforderung „Ausrichtung/ Skalierung“ und „Führung“ Das nächste Cluster von Herausforderungen entsteht meist, wenn sich die ersten Erfolge einstellen und sich ein Team gebildet hat, das mit den richtigen Werkzeugen arbeitet. Sicher läuft es noch nicht perfekt, aber genau in diese Zeit fällt sehr häufig die Neuausrichtung des Produktes. Dabei wird erkannt, dass die bisherigen Ziele nicht ambitioniert genug sind. Meist nachdem in den wenigen Sprints ein deutlicher Mehr‐ wert aufgrund der (hoffentlich) richtigen Priorisierung und Sortierung des Product Backlogs geschaffen wurde. Das Business freut sich und die Erfolgsfaktoren werden zusammen mit der deutlichen Erweiterung des Produkts angepasst - also kommt nun auch das Thema Time to Market auf. Es wird ersichtlich, dass das mit nur einem Team nicht mehr erreicht werden kann (siehe Kapitel 8.1). Es erfolgt eine Skalierung - nicht nur auf mehrere Teams für ein Produkt, sondern gleich für mehrere Produkte und alles sind auf einmal agil und arbeiten mit Scrum. Hier wird die Auswirkung auf alle vorherigen Herausforderungen deutlich. Alle Elemente werden erneut durchlau‐ fen, wenngleich nicht zwingend mit der gleichen Länge - je nachdem wie gut die Umstellung ausgeführt wird. Jedoch kommt gleichzeitig die Erkenntnis, dass mehr agile Teams sich nicht automatisch miteinander synchronisieren, insbesondere, wenn sie an unterschiedlichen Produkten arbeiten, die dennoch Abhängigkeiten zueinander aufweisen. Es entstehen teamübergreifende Abhängigkeiten und die Lieferung der Produkte stockt. Spätestens hier wird deutlich, dass eine Führung oder Steuerung über aller agilen Vorhaben benötigt wird (siehe Kapitel 8). Das ist eine schwere Zeit, in der viele Überlegungen zum weiteren Vorgehen notwendig werden. Dabei steht nicht nur das einzelne Produkt im Fokus, sondern es bedarf einer Idee, wie eine Kultur der agilen Prinzipien aufzubauen ist. Dazu gehören auch Richtlinien, an denen sich die Teams orientieren können. Einer der häufigsten Fehler ist der Versuch, das bisherige, organische Wachstum durch einen vollständigen Top Down-Ansatz zu ersetzen. Dabei werden möglicher‐ weise zu große Methoden genutzt, um einen kleinen agilen Bereich umzugestalten. Das Ergebnis kann sein, dass die bisherigen, sehr agilen Teams wieder stärker in formale Prozesse eingebunden werden, die Scrum so nicht vorsieht. In dieser Phase liegt eine hohe Verantwortung beim Scrum Master, das Team zusammenzuhalten und die neuen Ansätze bestmöglich in die bisherigen Arbeitsmethoden einzubinden. Hierfür sind ebenfalls die Tools und Kennzahlen erneut anzupassen. Aufgrund der vielen Teams reicht ein Product Owner nicht mehr aus. Der Einsatz von zwei oder mehr Product Ownern kann zu unterschiedlichen Produktzielen führen. Besonders sollte in dieser Zeit daher auf die neuen Risiken und Abhängigkeiten sowie den Business Values geachtet werden. Es entsteht eine Zeit, in der mehr technische und nichtfunk‐ tionale Anforderungen im Vordergrund stehen, wobei gleichzeitig zusammen mit unterschiedlichen Product Ownern fast automatisch eine Überleitung in das nächste Herausforderungscluster erfolgt. 157 7.4 Herausforderungen, Widerstände und Lösungsansätze 7.4.4 Herausforderung „Produktnutzen“ und „Produktfinanzierung“ Dieses Cluster von Herausforderungen folgt beinahe automatisch nach oder bereits während der vorherige Herausforderungscluster noch nicht abgeschlossen ist. Die Teams beginnen, zusammenzuarbeiten, haben aber die Umstellung vermutlich noch nicht ganz verkraftet. Gleichzeitig entsteht im Hintergrund etwas, das nicht sofort bemerkt wird. Es gibt auf einmal mehrere Product Owner für ein Produkt, die zwar nach den Skalierungsmethoden berücksichtigt wurden und daher synchronisiert sein sollten, in der Praxis erweist sich dies jedoch als schwierig. Der Product Owner repräsentiert den Kunden. Wie stimmen sich nun zum Beispiel 20 Product Owner ab, die ein gemeinsames Produkt und einen gemeinsamen Kunden vertreten? Wie können deren Anforderungen so übersetzt werden, dass jedes Scrum Team ein klares Produkt- und Sprintziel erhält, das einen Mehrwert für den einen gemeinsamen Kunden liefert? Scrum liefert dafür keine Antworten. Es besteht das Risiko, dass sich die Wahrnehmung des Kunden verändert und dieser nicht mehr wirklich der Kunde ist, sondern nur noch zum Verständnis des Marktes für die Produktausrichtung dient. Daher müssen sich die Product Owner in geeigneten Methoden üben, die es ermöglichen, eine gemeinsame Produktvision und Strategie auszuarbeiten und diese regelmäßig zu prüfen. Es muss den Product Ownern ebenfalls klar werden, dass jeder mehr Aufgaben in großen Vorhaben hat und es zusätzliche Zeit kostet. Erfolgt keine entsprechende Abstimmung zwischen den Product Ownern, führt dieses zu unterschiedlichen Produktzweigen, die möglicherweise nicht mehr auf eine Produkt‐ vision hinarbeiten und im schlechtesten Fall eine Entwicklung fördern, die nicht am Markt ausgerichtet ist. Daher ist jetzt besonders auf den Business Value zu achten. Wie kann dieser auch teamübergreifend ermittelt, bewertet und erreicht werden? Es ist zu beachten, ob die Strategie kostendeckend und als Langzeitvorhaben umgesetzt werden kann. Auch die Frage nach der Finanzierung der verschiedenen Teams wird sich zu einem entscheidenden Faktor entwickeln. Sobald zusätzlich externe Lieferanten eingebunden sind, kostet jeder Sprint eine Menge Geld. Dass jeder Sprint einen Wert generieren soll, ist selbstverständlich - das wird auch mit zehn Teams geschehen. Deckt es dabei die Kosten, wenn zum Beispiel insgesamt 50 externe Teammitglieder an einem Produkt arbeiten? Es stellt sich dann die Frage, wie der Wert eines Sprints zu bewerten ist. Daher sind traditionelle Vertragsmodelle für Auftraggeber und Dienstleister in Projekten oft nicht mehr geeignet. 7.4.5 Herausforderung „Reorganisation“ Dieser letzte Teil der Herausforderungen ist häufig mit oder nach dem vorherigen Cluster zu beobachten. Es gab so viele Veränderungen, dass langsam erkannt wird, dass die bisherigen Strukturen und Organisationen nicht zu der neuen Kultur der agilen Arbeitsweisen passen. Eine neue Aufstellung der Organisation anhand von Wertschöpfungsketten mit einer hohen Agilität wird erforderlich. Durch die neue Aufstellung kommt es zu einer Zeit der Verunsicherung hinsichtlich der Veränderun‐ 158 7 Status-Reporting und Metriken - Risiken und Probleme managen gen. Diese Veränderungen führen aber zu Verunsicherungen. Viele Phasen werden erneut durchlaufen und verzögern für eine gewisse Zeit den Fortschritt in nahezu allen Vorhaben. Da das Thema zu vielschichtig ist, als dass es hier ausreichend Würdigung erhalten würde, belassen wir es bei dem Hinweis darauf, dass es nicht nur Risiken, sondern echte Chancen in der Reorganisation gibt, die einen großen Schritt in Richtung einer transparenten, offenen Kultur bedeuten kann, in der Innovation und Agilität einen festen Platz einnehmen können. 159 7.4 Herausforderungen, Widerstände und Lösungsansätze 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation Erkunden wir im nächsten Reiseabschnitt die Möglichkeiten auf dem Basar der Skalierung. Wundersame Methoden erweitern hier Ihren Horizont und führen Sie auf die nächste Ebene der agilen Welten. Erleben Sie diese quirlige Vielfalt und verweilen danach in tiefer agiler Meditation. Es wird Ihnen bei Ihren weiterführenden Reisen in größeren Organisationen helfen. 8.1 Wenn mehr als ein agiles Team benötigt wird Im Idealfall reicht ein kleines Team, um die Produktziele zu erreichen und die dahinter liegenden Erfolgsfaktoren erfüllen zu können. Was passiert jedoch, wenn der primäre Erfolgsfaktor die Zeit ist. Sämtliche Tätigkeiten sind dann an diesem Faktor auszureich‐ ten. In den meisten Fällen wird entschieden, dass mehr Entwicklungskapazität benötigt wird, um das Ziel noch erreichen zu können. In der Folge werden neue Entwickler eingebunden, bis das Team eine kritische Masse erreicht hat, ab der eine Koordination nicht nur im Rahmen der Scrum-Routinen sehr schwer wird. Dieser Punkt ist in der Praxis bei einer Teamgröße von sieben bis zehn Entwicklern erreicht. Das spätestens ab diesem Punkt gleichzeitig die Performance sinkt, versteht sich beinahe von selbst. Eine Aufteilung in mehrere Teams ist unausweichlich. Bei großen Teams könnten zudem Gruppen entstehen, die sich unabhängig vom restlichen Team um ein Thema kümmern (Silos). Es bilden sich Hierarchien heraus, weil in großen Gruppen nicht jeder, wie in kleinen Teams, offen redet oder beachtet wird. Wie selbstverständlich werden bisher unbekannte Formalitäten eingeführt. Also genau die drei Punkte, dessen Abbau der agile Ansatz als Ziel haben sollte: ■ Vermeidung von Silos ■ Reduzierung von Hierarchien ■ Minimierung von formalen Prozessen und Formalitäten Kleine Teams hingegen, in denen es keine Hierarchien gibt, vermeiden zudem den sogenannten HiPPO-Effekt. Hiermit wird die Tendenz beschrieben, dass niederrangige Mitarbeiter sich häufig der „Highest Paid Persons Opinion“ anschließen, anstatt selbst‐ ständig Entscheidungen zu treffen. Der wohl wichtigste Aspekt ist die richtige Aufteilung von Teams, wenn man mehrere Scrum Teams gemeinsam an einem Produkt arbeiten lässt. Hier wird schnell deutlich, dass agile Arbeitsweisen eher sehr schwer skalierbar sind. In der Theorie wird zum Beispiel einfach davon ausgegangen, dass ein Team an seine Kapazitätsgrenzen stößt und daher für die notwendige Arbeit zu lange benötigt. Durch die Aufteilung in zum Beispiel zwei Teams soll dann die Dauer, aufgrund der doppelten Kapazität, um die Hälfte verkürzt werden (siehe Abbildung 76). Sprint 1 Sprint 2 Sprint 3 Sprint 4 12 Wochen Sprint 1-A Sprint 1-B Sprint 2-A Sprint 2-B Produktentwicklung mit einem Scrum Team 6 Wochen Produktentwicklung mit zwei Scrum Teams PI 1 PI 2 PI 3 PI 4 PI 1 PI 2 PO E E E SM PO E E E SM PO E E E SM Figure 76: Verkürzung der Produktentwicklungszeit durch den Einsatz mehrerer Scrum-Teams Abbildung 76: Verkürzung der Produktentwicklungszeit durch den Einsatz mehrerer Scrum Teams Abgesehen davon, dass bereits die Annahme, dass zwei Teams die Arbeit an ein- und demselben Produkt in der Hälfte der Zeit erledigen, gewagt ist, so wird meist völlig außer Acht gelassen, dass auch zwei Teams sich abstimmen müssen. Dazu aber später mehr. Bereits bei der ersten Auseinandersetzung mit dem Thema „mehr als ein agiles Team für ein Produkt“ ergeben sich neue Herausforderungen. Anhand welcher Kriterien teilt man die Teams auf ? Kann ein einzelner Product Owner die steigende Anzahl an Anforderungen spezifizieren und priorisieren? Wie kann der Scrum Master zwei oder mehr Teams koordinieren oder wird sogar ein zweiter Scrum Master benötigt. Wie werden die Product Backlog Items gehalten und an die verschiedenen Teams verteilt? Wie werden Hindernisse (Impediments) beseitigt, die mehrere Teams betreffen? Wie kommunizieren die Teams miteinander? Wie synchronisieren die Teams ihre Arbeit und wie werden Abhängigkeiten, die es zwischen den Teams gibt, am besten koordi‐ niert? Diese und viele weitere Probleme sind umso dringlicher, je mehr Teams an einem gemeinsamen Produkt arbeiten, da sich die Abhängigkeiten zwischen den Teams erhöhen und viele Tätigkeiten mehrfach durchgeführt werden. Feature Teams skalieren besser als Komponenten-Teams: Vorab ist festzuhalten, dass Feature Teams meist keine Features im Sinne von Features zu einem Roadmap-Ziel entwickeln (vgl. Abschnitt 5.1.4). Das würde bedeuten, dass die Teams sich bei jedem Sprint oder sogar im Sprint ständig neu zusammenstellen 162 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation müssten. Ebenso ist ein Komponenten-Team nicht nur mit einer Komponente im Sinne eines einzelnen Moduls beschäftigt. Es geht vielmehr um einen Begriff, der sich an dem Zuständigkeitsbereich des Teams orientiert. Daher werden Feature- und Komponenten-Teams unterschieden. Entwickeln zum Beispiel zwei Scrum Teams ein gemeinsames Produkt, muss geklärt werden, wie die anstehenden Aufgaben verteilt werden. Bei Software-Produkten gibt es dann beispielsweise Komponenten-Teams für die Betreuung und Weiterentwicklung der Benutzerschnittstellen, der Anwendungs‐ logik und der Datenbank (horizontaler Schnitt, weil die Ebenen übereinander liegen - siehe Abbildung 79). Jeder der zuvor genannten Zuständigkeitsbereiche „Benutzer‐ schnittstellen“, „Anwendungslogik“ und „Datenbank“ werden als Services bezeichnet. Jedes Team könnte dann ein oder mehrere Services in seiner Zuständigkeit haben. Wird das Produkt in dieser Form auf die Teams verteilt, hat das zur Folge, dass die User Stories im Product Backlog meist mehr technisch beschrieben werden und die von Scrum geforderte Kundenzentrierung verloren geht. Jedes Team ist für eine spezielle (technische) Komponente verantwortlich. Problematisch daran ist auch, dass viele Abhängigkeiten zwischen den Teams entstehen. So hat dieses Modell häufiger zu Folge, dass am Ende eines Sprints kein lauffähiges Inkrement an den Kunden ausgeliefert werden kann. Die Ursache ist das „aufeinander aufbauen“ der Komponenten. Um ein Inkrement erzeugen zu können, wird meist eine Änderung an der Benutzerschnitt‐ stelle, der Anwendungslogik und der Datenbank benötigt. Das sind eventuell drei unterschiedliche Teams. Wenn das Benutzerschnittstellen-Team Änderungen an der Oberfläche vornimmt, um neue Daten aus der Datenbank anzuzeigen, so wird meist zuvor eine gewisse Anwenderlogik benötigt, die wiederrum zuvor die Informationen aus der Datenbank braucht. Die Folge ist häufiger, dass das Datenbank-Team im ersten Sprint seinen Teil erledigt, im zweiten Sprint folgt das Team mit der Anwenderlogik und im dritten Sprint das Team zur Anpassung der Oberfläche. Drei Sprints, um ein vollständig lauffähiges Inkrement zu erzeugen, kann jedoch nicht die Lösung sein. Da hilft es auch nicht, die Definition of Done und WoW anzupassen und jedes Stück Software einfach als Inkrement zu bezeichnen - unabhängig davon, ob es einen Wert liefert, indem es den Kunden zur Verfügung steht. Es wäre jedoch ein Fehler anzunehmen, dass Komponenten-Teams der falsche Weg sind. Insbesondere bei Produkten, welche die Hauptziele erreicht haben und mehr in den operativen Modus übergehen, sind die Komponenten-Teams sogar viel häufiger anzutreffen als die Feature Teams. Im Fokus stehen dann mehr technische Verbesserungen und weniger neue Funktionen. Zudem werden meist weniger Teams benötigt als bei einer Aufteilung nach klar abtrennbaren, funktionalen Bereichen des Produkts, für die viel mehr die Feature Teams zum Einsatz kommen. Bei einer Neuentwicklung beziehungsweise einem Produkt, dass noch eine längere Entwicklungszeit vor sich hat, ist die Etablierung von Feature Teams der am meisten gewünschte Standard. Diese Teams müssen dabei so organisiert werden, dass sie mit ihrem Wissen einen vertikalen Schnitt durch alle Komponenten repräsentieren, wodurch eine Ende-zu-Ende-Verantwortung für ein Teil des Produkts (Service) entsteht (siehe Abbildung 78). 163 8.1 Wenn mehr als ein agiles Team benötigt wird Das Product Backlog ist dann deutlich stärker auf fachliche Anforderungen fokus‐ siert und die Teams entwickeln ein breites Wissen über alle technischen Komponenten ihres Produktbereichs (Service). Es gibt weniger Abhängigkeiten zwischen den Teams. Dadurch verringert sich auch die Bearbeitungszeit der Anforderungen, da die Teams nicht gegenseitig auf sich warten müssen. Die Teammitglieder identifizieren sich mehr mit den erstellten Produktteil (siehe Abbildung 77). Product Backlog Benutzerschnittstelle (Komponente 1) Benutzerschnittstelle (Komponente 2) Benutzerschnittstelle (Komponente 3) Benutzerschnittstelle (Komponente 1) Benutzerschnittstelle (Komponente 2) Benutzerschnittstelle (Komponente 3) Feature- Teams Komponenten- Teams Team A PO E E E SM Team B PO E E E SM Team C PO E E E SM Team A PO E E E SM Team A PO E E E SM Team A PO E E E SM Figure 77: Feature-Teams versus Komponenten-Teams Abbildung 77: Feature Teams versus Komponenten-Teams Vollständig unabhängig sind die Teams jedoch trotzdem nicht, denn sie müssen sich am Produkt orientieren. Daher werden die horizontalen oder vertikalen Schnitte durch die Ebenen, wie zuvor beschrieben, als Services (siehe Abbildungen 78 und 79) bezeichnet. Backend Backend Datenbank Datenbank Frontend Frontend M i c r o s e r v i c e A M i c r o s e r v i c e A M i c r o s e r v i c e B M i c r o s e r v i c e B M i c r o s e r v i c e C M i c r o s e r v i c e C …… M i c r o s e r v i c e Y M i c r o s e r v i c e Y M i c r o s e r v i c e Z M i c r o s e r v i c e Z V e r t i k a l e r S c h n i t t Figure 78: Microservices Abbildung 78: Micro-Services 164 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation Macroservice C Macroservice C Macroservice B Macroservice B Macroservice A Macroservice A Backend Backend Datenbank Datenbank Frontend Frontend Horizontaler Schnitt Figure 79: Macroservices Abbildung 79: Macro-Services Diese Services tauschen in der Regel Daten und Informationen untereinander aus. Es ist also nicht so, dass durch Feature Teams keine Produkte mit eigener Roadmap entstehen, sondern das alle Teams weiterhin auf die gemeinsamen Produktziele hinarbeiten. Dabei sollte jedoch jedes Team so autonom wie nur möglich sein. Wichtige Grundregeln sind dabei immer, dass ein Service nur einem Team zugewiesen wird. Jedoch kann jedes Team mehrere Services betreuen. Es soll an dieser Stelle nicht verschwiegen werden, dass es in der Praxis durchaus hybride Ansätze aus beiden Varianten gibt, die sehr sinnvoll sein können. Der häufigste Fall (siehe Abbildung 80) ist ein Macro-Service, der eine Datenintegration zwischen Micro-Services sicherstellt; dies unter Umständen mit weiteren Funktionen zur Service-Integration, wie zum Beispiel das Benutzermanage‐ ment, Netzwerkintegration oder Sicherheitsfunktionen. Auch die Bereitstellung einer einheitlichen Benutzeroberfläche als Macro-Service, in der die Benutzeroberflächen der jeweiligen Micro-Services eingebunden werden, ist ein häufig gewählter Ansatz. Backend Backend Datenbank Datenbank Frontend Frontend M i c r o s e r v i c e A M i c r o s e r v i c e A M i c r o s e r v i c e B M i c r o s e r v i c e B M i c r o s e r v i c e C M i c r o s e r v i c e C …… M i c r o s e r v i c e Y M i c r o s e r v i c e Y Figure 80: Hybrid aus Mikro- und Makroservices Macroservice Z Macroservice Z Integration Integration V e r t i k a l e r S c h n i t t Horizontaler Schnitt Abbildung 80: Hybrid aus Micro- und Macro-Services 165 8.1 Wenn mehr als ein agiles Team benötigt wird Insbesondere bei größeren agilen Projekten hat es sich in der Praxis bewährt, primär auf Feature Teams zu setzen und nicht einen reinen Komponenten-Team Ansatz zu etablieren. Wie zuvor beschrieben, gibt es viele gute Gründe einen hybriden Ansatz zu wählen. Dabei ist es nicht auszuschließen, dass ein Team sowohl für einen Microals auch gleichzeitig für einen Macro-Service Verantwortung übernimmt. Das hängt vom Umfang und den Schnitt der Services ab. In diesem Fall wäre ein Feature Team gleichzeitig ein Komponenten-Team. Zu empfehlen ist es allerdings nicht, weil ein Komponenten-Team im Hybrid-Modell seinen Fokus darauf zu legen hat, alle Micro-Services zu unterstützen, die vom Macro-Service abhängig sind. Wenn ein Komponenten-Team gleichzeitig zum Beispiel zwei Micro-Services betreut, so kommt es immer wieder vor, dass das Team alles in die Wege leitet, um die eigenen Ziele bestmöglich zu unterstützen. Andere Feature Teams könnten in eine Art Warteschlage gestellt werden, was am Ende die gemeinsamen Produktziele gefährden könnte. Zudem ist eine Skalierung innerhalb der Services bei Micro-Services mit einem Feature Team einfacher als bei einem Hybrid-Modell, bei dem ein Team einen Micro- und einen Macro-Service verantwortet. Bei dem Hybrid-Team stellt sich dann die Frage, was skaliert werden soll: der Macro-Service, der Micro-Service, oder beide zusammen. Je nach Ergebnis gibt es danach ein neues Komponenten-Team (bei Macro-Service Skalierung), ein neues Feature Team (bei Micro-Service Skalierung) oder ein bis zwei neue Teams, wenn beide Services skaliert werden. Besser ist eine klare Skalierung von Teams anhand einzelner Services. Microservice A Microservice B Microservice C Microservice X Microservice Y Macroservice X Service C.1 Service C.2 Service C.3 Service C.4 Macroservice X Macroservice X Team D Team C Team C Team E Team X Macroservice X Team X Team Z Team Y Skalierung Figure 81: Skalierung von Micro- und Macroservices Skalierung Abbildung 81: Skalierung von Micro- und Macro-Services Dabei sind Teams klar in Feature- und Komponenten-Teams getrennt und haben daher keine Interessenkonflikte hinsichtlich der Verantwortung zu den Services. Aus einem Macro-Service wird im Rahmen der Skalierung sicher kein Micro-Service und das 166 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation gleiche gilt vice versa. Wenn also ein Micro-Service aufgeteilt wird, dann wird es neue Services geben, die im Grunde den Umfang des ursprünglichen Services abdecken, jedoch von mehreren Teams bearbeitet werden (siehe Abbildung 81). Dabei kann es sein, dass das bestehende Team ein oder mehrere der neuen Services verantwortet und die restlichen neuen Services von einem oder mehreren neuen Teams übernommen werden. In der Praxis hat sich bewährt, das bestehende Team aufzutrennen und auf die neuen Teams zu verteilen. Damit ist ein sukzessives Anwachsen der Projektmitarbeiter gut abbildbar. Das Team, welches später aufgeteilt werden soll, wird auch Tigerteam genannt. Tigerteam E E E E E E Feature Team 1 E E Feature Team 2 E Feature Team 3 E E E Figure 82: Übergang von Tigerteams zu Feature-Teams Abbildung 82: Übergang von Tigerteams zu Feature Teams Wird die Entwicklung eines strategisch wichtigen Projekts mit einem Pilotprojekt ge‐ startet, ist der Einsatz eines Tigerteams ratsam. Das agile Team, das mit der Umsetzung des Pilotprojekts betraut wird, sollten mit sehr erfahrenen Leuten bestückt werden. Dieses Team entwickelt die Kernarchitektur des Produkts. Wenn der Arbeitsaufwand zu groß wird, löst man das Tigerteam auf und bildet stattdessen im besten Fall mehrere Feature Teams. Die Mitglieder des initialen Tigerteams teilen sich dann auf 167 8.1 Wenn mehr als ein agiles Team benötigt wird und idealerweise hat jedes Feature Team mindestens einen „ehemaligen Tiger“. Diese sind dann für den Wissenstransfer zu den neuen Teammitgliedern verantwortlich (siehe Abbildung 82). Mit dieser Teilung des Tigerteams und dem Hinzufügen neuer Mitglieder ist es auch einfacher, die bereits etablierten agilen Praktiken und Prinzipien auf die neuen Teams zu übertragen. Es darf dabei auch nicht vergessen werden, dass eine Trennung eines Teams nicht automatisch zu zwei neuen, voll arbeitsfähigen und performanten Teams führt. Die Gruppen- und Teambildungsprozesse beginnen erneut mit allen Auswirkungen auf die anstehenden Aufgaben. In den allermeisten Fällen wird es zu einem Abfall der Leistung führen - dieses Risiko sollte immer beachtet werden. Etablierung selbstorganisierter Community of Practices (CoP): Wenn funktionsübergreifende Feature Teams möglichst unabhängig voneinander User Stories umsetzen, erschwert das den Expertenaustausch, in manchen Fällen kommt er sogar ganz zum Erliegen. In den Unternehmen entstehen dann Insellösungen und das Wissen wird kaum über Teams hinweg verteilt. Wenngleich auch alle Teams unabhängig voneinander ihre Technologien auswählen dürfen, so besteht die Gefahr, dass ein Architektur-Wildwuchs entsteht und das erstellte Produkt später schwierig erweiterbar und wartbar ist. Versucht man diesem Problem zu begegnen, indem man spezialisierte Architekturteams gründet, die beispielsweise sicherstellen, dass alle den gleichen Architekturstandards folgen oder einheitliche Entwicklungsplattformen verwenden, widerspricht das der Kundenzentrierung und es entstehen wieder neue Abhängigkeiten zwischen den Teams. Eine Lösung für diesen Zielkonflikt ist die Etablierung selbstorganisierter CoPs. Eine CoP ist eine Gruppierung von Personen, die ähnliche Themengebiete bearbeiten. Sie ermöglichen den Wissensaustausch und das gemeinsame Lernen. Eine CoP erzeugt Ergebnisse innerhalb ihres Themenge‐ biets (Domain), die die tägliche Arbeit (Practice) der Beteiligten verbessern. Diese Abgrenzung ist wichtig, damit sich die Community nicht zu einer unstrukturierten Diskussionsrunde entwickelt. Ergebnisse können beispielsweise die Festlegung auf bestimmte Entwicklungsframeworks oder Werkzeuge sein. Es können auch Leitfäden, Anleitungen oder Best Practice-Dokumente erstellt werden. Die Verantwortung für die Anwendung des erworbenen Wissens liegt dann jedoch bei den Feature Teams. In der Praxis ist dabei eine Herausforderung, dass die CoP nicht zu einem Team oder Silo werden. Es kann bei fehlender Begleitung sogar dazu führen, dass sich Teile oder ganze Feature Teams möglicherweise wieder in Richtung Komponenten-Teams entwickeln. Das Gefühl der Zusammengehörigkeit in einer CoP wird durch die gemeinsamen Themen gestärkt. Das ist wichtig, sollte jedoch nicht so weit führen, dass sich die CoP als eigenes Team ansieht und gemeinsam Aufgaben aus den Sprints übernimmt. Die Umsetzung ist und bleibt den Feature Teams vorbehalten. Von zentraler Bedeutung ist vor allem der Start der CoP als offenes Forum. Insbe‐ sondere, wenn Tigerteams aufgetrennt werden, besteht zwischen den ehemaligen Teammitgliedern eine hohe Verbundenheit. Das ist positiv für den Austausch. Jedoch ist darauf zu achten, dass sich nicht nur die ehemaligen Teammitglieder treffen, sondern 168 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation die CoP so eingestellt wird, dass sich alle einbringen können. Hier kann der Scrum Master eine gute Unterstützung beim Start sein, wobei er nicht der Moderator der Treffen sein sollte. Die CoP muss sich selbst managen. Der Scrum Master kann jedoch aufgrund seiner Erfahrung Hilfestellung bei gruppendynamischen Prozessen geben und einen wertvollen Beitrag leisten, damit die CoPs erfolgreich sind. Potential Coalescing Maturing Stewardship Transformation Shutting Down Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6 Zeit Figure 83: CoP-Lebensphasen Abbildung 83: CoP-Lebensphasen CoPs durchlaufen typischerweise die in Abbildung 83 gezeigten fünf Lebensphasen. Am Anfang finden sich einzelne Personen zu einem gemeinsamen Thema zusammen (Phase 1: Potential). Anschließend entwickeln sich erste Strukturen, die Domain wird genauer festgelegt und Community-Rollen verteilt (Phase 2: Coalescing). Die CoP wird größer, die Rollen werden gelebt und es werden ausgereifte Kommunikations‐ werkzeuge verwendet (Phase 3: Maturing). In Phase 4 (Stewardship) hat das kollektive Wissen der CoPs ein hohes Niveau erreicht und immer mehr Mitglieder haben kein Bedürfnis mehr, sich in der Community aktiv einzubringen. Die CoP verliert dann sukzessive an Bedeutung und die Mitglieder wenden sich anderen Gruppen zu (Phase 5: Transformation) bis die Community schließlich geschlossen wird (Phase 6: Shutting Down). Gemeinsames Product Backlog und teamindividuelle Sprint Backlogs: Entwickeln mehrere agile Teams gemeinsam ein Produkt, sollte vermieden werden, dass es mehrere Backlogs gibt. Teamindividuelle Backlogs führen dazu, dass sich die agilen Teams in unterschiedliche Richtungen bewegen und eine integrierte Sicht auf das Produkt verloren geht. Das Product Backlog muss alle Anforderungen an das Produkt enthalten - ohne Zuordnung zu bestimmten Teams. Erst im Rahmen des Sprint Plannings übernehmen die Teams die Product Backlog Items in die teamindividuellen Sprint Backlogs und fokussieren sich in ihrem Sprint auf die Umsetzung dieser Items. 169 8.1 Wenn mehr als ein agiles Team benötigt wird Aufgabenbereich des Product Owners: Mit jedem zusätzlichen Team wächst der Arbeitsaufwand des Product Owners und irgendwann ist der Punkt erreicht, an dem er nicht mehr alle User Stories entwickeln und das Product Backlog priorisieren kann. Verteilt man aber die Aufgaben des Product Owners auf mehrere, kann dies zu Konflikten bei der Priorisierung und Product Backlog Items führen. Es ist daher besser, wenn der Product Owner einzelne Aufgaben in die Teams delegiert. Er könnte beispielsweise die Anforderungen nur skizzieren und Team‐ mitglieder formulieren die User Stories und die korrespondierenden Akzeptanzkriterien. Anschließend prüft der Product Owner die User Stories und priorisiert das Product Backlog. Er bliebe also die zentrale Entscheidungsinstanz. Ist das zu erstellende Produkt so groß, dass auch das nicht mehr umsetzbar ist, sollte man die Verantwortung für Produktbereiche an Area-Product Owner übertragen. Ein solcher Bereich kann mehreren Epics oder sogar übergeordneten Strukturelementen entsprechen. Die Area-Product Owner erstellen selbstständig User Stories für ihren Bereich und erfassen diese im zentralen Product Backlog. Den Area-Product Ownern ist ein Chef-Product Owner übergeordnet, der nur noch zum Beispiel Epics erstellt und bei etwaigen Konflikten zwischen den Area-Product Ownern entscheidet, wie zu verfahren ist. Zusätzliche Dailys für die Identifizierung von Abhängigkeiten: Bei der agilen Produktentwicklung mit mehreren Teams müssen sich die Beteiligten während des Sprints regelmäßig austauschen. Hierfür sollten formelle Events, zum Beispiel teamübergreifende Dailys, etabliert werden. So können sich Teamvertreter zweibis dreimal pro Woche zu einem zusätzlichen Daily treffen, über die Fortschritte in deren Teams berichten und Hindernisse, die sich insbesondere aufgrund der anderen Teams ergeben, diskutieren. Wichtig hierbei ist, dass dieses übergeordnete Abstimmmeeting nicht zu einer Statusreport-Besprechung verkommt. Auch auf dieser Ebene gilt es, die Scrum-Prinzipien Inspect und Adapt zu leben und Hindernisse zu beseitigen, die den Teams bei der Erreichung des Sprintziels im Weg stehen. Die in der Besprechung identifizierten Hindernisse können über ein zentrales Impediment-Board transparent gemacht werden. Abbildung 84 zeigt ein solches Board, bei dem die Abhängigkeiten zwischen den Product Backlog Items unterschiedlicher Teams mit Pfeilen visualisiert werden. … 1 4 9 5 6 8 7 Aktueller Sprint Sprint +1 Sprint +2 Team 1 Team 2 Team 3 Figure 84: Impediment-Board Abbildung 84: Impediment-Board 170 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation Sprint Review in Form eines Basars: Das Sprint Review sollte bei mehreren Scrum Teams nicht in der gleichen Form durch‐ geführt werden wie in einem einzelnen Team. Ansonsten würde der Review viel Zeit in Anspruch nehmen. Möglicherweise entsteht Langeweile bei den Teammitgliedern und den Stakeholdern, die nur an einzelnen Themenstellungen interessiert sind. Besser eignet sich beispielsweise ein Marktplatz- oder Basar-Review mit einzelnen Stationen, an denen die Teams die umgesetzten User Stories vorstellen. Die Stakeholder können dann die einzelnen Stationen ablaufen und sich mit den Teams austauschen. In der heutigen Welt mit verteilten Teams und virtueller Zusammenarbeit ist das nicht so leicht möglich. Daher empfiehlt es sich bei einem virtuellen Zusammentreffen mit einem Überblick zu starten, welche Themen auf dem Basar angeboten werden. In dieser kurzen Zeit kann jedes Team in zum Beispiel fünf Minuten seine Punkte bewerben. Es sollte geprüft werden, welche Stakeholder in welchen Gruppen zwingend erforderlich sind. Danach werden die Teams in getrennte, virtuelle Gruppen aufgeteilt. Es gibt bereits gute Softwarelösungen, virtuelle Gruppen im selben Call in Untergruppen aufzuteilen. Die Herausforderung besteht in der Teilnahme der dringend benötigten Personen, wenn viele Teams Bedarf anmelden. Teamübergreifende Retrospektiven: Neben den Retrospektiven auf Einzelteamebene muss eine Möglichkeit geschaffen werden, damit sich die teamübergreifenden Prozesse ebenfalls verbessern können. Im Prinzip gibt es zwei verschiedene Möglichkeiten, diese zusätzlichen Retrospektiven durchzuführen: ■ Retrospektive mit Teamvertretern: Am Ende eines jeden Sprints diskutieren der Scrum Master, der Product Owner und ein Vertreter aus jedem Team Optionen, die teamübergreifende Zusammenarbeit zu verbessern. ■ Retrospektive mit allen Teammitgliedern: Die Mitglieder aller Teams nehmen an einer großen Retrospektive teil. Hier wird mithilfe von Story Telling- und Open Space-Techniken der zurückliegende Sprint reflektiert, Verbesserungsmög‐ lichkeiten werden priorisiert und konkrete Maßnahmen abgeleitet. Ein häufig zu beobachtendes Phänomen ist bei großen Gruppen, dass nur sehr wenige sich am Austausch beteiligen. Verstärkt wird dieses in virtuellen Zusammentreffen - insbesondere ohne Kameras. Daher ist eine Retrospektive mit sehr vielen Teammitgliedern eine echte Herausforderung, die eine gründliche Vorbereitung benötigt. 8.2 Beispiel: Autonome Zwei-Pizzen-Teams bei Amazon Bei Amazon haben die berühmten Zwei-Pizzen-Teams nicht mehr als zehn Mitarbeiter. Man benötigt nämlich zwei Pizzen, damit zehn Leute satt werden. Bei dem Konzept geht 171 8.2 Beispiel: Autonome Zwei-Pizzen-Teams bei Amazon es weniger um die Größe des Teams als vielmehr um deren eigenständige Arbeitsweise im Konzern und die Etablierung unternehmerischen Denkens auf Teamebene. Nicht alle Teams sind Zwei-Pizzen-Teams, aber es gibt einige hundert von ihnen in der Organisation. Amazon verfolgt hiermit die Strategie, die verschiedenen Unterneh‐ mensbereiche auf klar definierte und aufgabenorientierte Teams herunterzubrechen. Diese Teams werden nicht für zeitlich begrenzte Projekte, sondern um Amazons Kompetenzen und Services herum etabliert. So möchte man erreichen, dass die Teams sich mindestens zwei Jahre umfassendes Know-how in ihrem Verantwortungsbereich aneignen und diesen kontinuierlich verbessern. Ein solcher Bereich ist beispielsweise eine technische Funktion, eine Produktkomponente oder ein Prozess. Hierfür erstellt jedes Team einen eigenen Businessplan, was ein gutes Verständnis für die Wertschöp‐ fung, die man erreichen möchte, schafft. Aufgrund der beschränkten Teamgröße ist der Kommunikationsaufwand innerhalb der Teams nicht so hoch. Da die Teams weitestgehend unabhängig voneinander arbeiten, erreicht man zudem, dass der Kommunikationsbedarf zwischen den Teams gering ist (Abstimmungsmeetings, Planungen, Freigabeprozesse etc.). Die autonom agierenden Einheiten erzeugen schneller Ergebnisse. Auch die IT-Systeme werden möglichst in Eigenverantwortung betrieben. So entstehen lose gekoppelte Systeme, die unabhängig voneinander weiterentwickelt werden können. Wenn technische Schnittstellen vorhanden sind, werden diese genau spezifiziert und dokumentiert. Bei dieser Arbeitsweise erreicht man, dass in kürzeren Zeitabständen Lösungen entwickelt werden, für die schneller Kundenfeedbacks eingeholt werden können. Die komplexe Struktur vieler kleiner und unabhängiger Teams hat allerdings auch Nachteile. Es kann beispielsweise zu Kommunikationsschwierigkeiten zwischen den Teams kommen und die Integration der Services, die die Teams verantworten, ist schwieriger. Aber die Vorteile, die kleine agile Teams mit sich bringen, überwiegen diese Nachteile. Letztlich ist nur so eine fast unbegrenzte Skalierung der Unternehmensstruktur möglich, ohne dass ein großer Verwaltungsoverhead entsteht. 8.3 Welchen Zweck erfüllen Skalierungsframeworks? Werden die Teams größer, lohnt es sich bereits vorhandene Skalierungsframeworks auf einen möglichen Einsatz hin zu untersuchen. Diese Frameworks können in größeren Teams, Abteilungen oder ganzen Organisationen eingesetzt werden. Alle Frameworks basieren auf der Vorstellung, dass crossfunktionale Feature Teams selbstorganisiert an der Produktentwicklung zusammenarbeiten. Sie verwenden in der Regel die zuvor beschriebenen Konzepte. Die Teams teilen sich ein gemeinsames Product Backlog, die Planung wird teamübergreifend erstellt und auf Teamebene gelten die agilen Grundprinzipien. Damit das funktioniert, wird das Scrum-Regelwerk um zusätzliche, agile Rollen, Artefakte und Ereignisse erweitert. 172 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation Skalierungsframework Version Entwickler Organisation Large Scale Scrum (LeSS) Dezember 2020 Craig Larman, Bas Vode Less Works Nexus Januar 2021 Ken Schwaber Scrum.Org Spotify Model 2012 Henrik Kniberg, Anders Ivarsson Spotify Scaled Agile Framework (SAFe) 5.0 Februar 2020 Dean Leffingwell Scaled Agile K o m p l e x i t ä t Figure 85: Ausgewählte Skalierungsframeworks Abbildung 85: Ausgewählte Skalierungsframeworks In den nachfolgenden Kapiteln werden die am weitesten verbreiteten Skalierungsfra‐ meworks Large Scale Scrum (LeSS), Nexus, Spotify Model, Scrum@Scale und Scaled Agile Framework (SAFe) vorgestellt und deren Einsatzmöglichkeiten diskutiert (siehe Abbildung 85). Scrum@Scale und Nexus wurden von den Scrum-Erfindern Jeff Suther‐ land und Ken Schwaber entwickelt. Beide Skalierungsansätze orientieren sich sehr stark am Scrum Guide und erweitern das Regelwerk an verschiedenen Stellen, um die Zusammenarbeit mehrerer Scrum Teams zu ermöglichen. Das Gleiche gilt für das LeSS-Framework. Auch hier haben sich die Entwickler Craig Larman und Bas Vode sehr stark an Scrum orientiert. Beim Spotify Model von Henrik Kniberg und Anders Ivarsson ist das weniger der Fall. Hier geht es vielmehr darum, die agile Arbeitsweise in einer wachsenden Organisation am Beispiel von Spotify zu beschreiben. SAFe postuliert auch nicht die Anwendung von Scrum. Dieses Framework ist insbesondere für große Organisationen oder für den Einsatz in Großprojekten, wenn zahlreiche agile Teams an komplexen Produkten arbeiten, interessant. 8.4 Scrum skalieren mit LeSS und LeSS Huge LeSS (Large Scale Scrum) wurde von Craig Larman und Bas Vodde entwickelt und erstmals in der Finanz- und Telekommunikationsbranche eingesetzt. Larmann und Vodde postulieren, dass man Skalierungsframeworks wann immer möglich vermeiden soll. Die Grundidee, die sich auch im Namen ausdrückt, besteht im Prinzip darin, an dem Scrum Framework möglichst wenig Erweiterungen vorzunehmen, um eine Skalierung zu ermöglichen. Abbildung 86 zeigt die Rollen, Artefakte und Ereignisse, die bei LeSS verwendet werden. Wie bei Scrum gibt es nur einen Product Owner, der für die Pflege des teamübergreifenden Product Backlogs verantwortlich ist. Es gibt funktionsübergreifende Feature Teams, die in parallel stattfindenden Sprints Produk‐ tinkremente erstellen. Diese Feature Teams sollen nicht nach dem Ende eines Projekts aufgelöst werden, sondern ganz im Sinne von Scrum langfristig bei unterschiedlichen Produktentwicklungen unterstützen. 173 8.4 Scrum skalieren mit LeSS und LeSS Huge LeSS Rollen LeSS Artefakte LeSS Ereignisse Ein Product Owner Ein Product Backlog Sprint Planning 1 Scrum Master Sprint Backlogs Sprint Planning 2 Feature Teams Eine Definition of Done Product Backlog Refinement Ein Produktinkrement Daily Scrums Sprint Review Retrospective Overall Retrospective Figure 86: LeSS Rollen, Artefakte und Ereignisse Abbildung 86: LeSS Rollen, Artefakte und Ereignisse In jedem Sprint wird ein potenziell auslieferbares Produktinkrement erstellt, das auf einer gemeinsamen Definition of Done basiert. Zu Beginn eines Sprints gibt es ein Sprint Planning, das in zwei Teile gesplittet wird. Am Sprint Planning 1 nehmen Stellvertreter aller Teams teil. In dieser Sitzung wird entschieden, welche Product Backlog Items von welchen Teams im aktuellen Sprint bearbeitet werden. Im anschließenden Sprint Planning 2 findet eine Feinplanung auf Teamebene statt. Die Teams beschließen in einer internen Sitzung, wie die Product Backlog Items umgesetzt werden und erstellen ihr teamindividuelles Sprint Backlog. Das Daily Scrum wird eigenständig von jedem Team durchgeführt. Es können jedoch Mitglieder anderer Teams als Beobachter teilnehmen, um den Wissensaustausch zwischen den Teams zu gewährleisten. Auch das wird selbstorga‐ nisiert durch die Teams koordiniert. In der Mitte eines Sprints gibt es ein Product Backlog Refinement, an dem der Product Owner und ein Stellvertreter jedes Teams teilnehmen. Hauptzweck dieses Meetings ist es, zu entscheiden, welche Product Backlog-Elemente von welchem Team im nächsten Sprint bearbeitet werden. Ein LeSS-Sprint endet mit einem Sprint Review und einer zweigeteilten Retrospektive. Im ersten Teil macht jedes Team eine individuelle Retrospektive. In der anschließend stattfindenden zweiten Retrospektive (Overall Retrospective) treffen sich Repräsentanten aus jedem Team, um Probleme zu identifizieren, die nicht von einem einzelnen Team gelöst werden können. In dieser Runde sollen auch die teamübergreifenden Regeln und Prozesse verbes‐ sert werden. Im Sprint Review inspizieren neben dem Product Owner und den Teammitgliedern, relevante Kunden, Anwender und sonstige Stakeholder das erstellte Produktinkrement. Aufgrund der großen Teilnehmerzahl sollte die Veranstaltung in einem großen Raum mit unterschiedlichen Stationen durchgeführten werden. An jeder Station stellen die Mitglieder eines Teams die von ihnen erstellten Product Backlog-Elemente vor. Auf die Herausforderungen in einem verteilten und virtuellen Team sind wir vorher bereits eingegangen (vgl. Sprint Review in Form eines Basars). In der abschließenden teamübergreifenden Retrospektive möchte man die gesamte LeSS-Vorgehensweise verbessern. An dem Ereignis nehmen der Product Owner, der Scrum Master und wechselnde Repräsentanten der Teams teil (siehe Abbildung 87). 174 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation Figure 87: LeSS Framework Quelle: https: / / less.works/ img/ framework/ less-framework.pdf Abbildung 87: LeSS Framework Quelle: https: / / less.works/ img/ framework/ less-framework.pdf 175 8.4 Scrum skalieren mit LeSS und LeSS Huge Der Psychologe Robin Dunbar hat untersucht, wann die kognitive Grenze der Anzahl an Menschen erreicht ist, und kam zu dem Ergebnis, dass ein Mensch maximal 150 soziale Beziehungen unterhalten kann. Diese Dunbar-Zahl wird auch als Begrenzung für größere Arbeitsgruppen gesehen. Bis zu dieser Größenordnung lassen sich agile Ereignisse wie Sprint Planning oder Sprint Retrospektive noch durchführen. Bei noch größeren Teams ist das nicht mehr machbar. In der Praxis ist bereits eine 50-köpfige Gruppe eine schwere Kost. Insbesondere bis eine derartig große Gruppe übergreifend zusammenarbeitet vergeht viel Zeit. Nicht nur jede einzelne kleine Gruppe muss erstmal zum Team werden, auch Tools, Organisation, Kunden und die Finanzierung sind in Einklang zu bringen. Ein weiterer Grund, warum LeSS nicht beliebig skalierbar ist, liegt in der Limitierung auf einen Product Owner. Die Erfinder Larman und Vodde empfehlen, dass in der Basisvariante von LeSS maximal acht Feature Teams mit einem Product Owner an der Entwicklung neuer Produkte arbeiten. Für die Zusammenarbeit von mehr Teams bieten sie LeSS Huge. Hiermit können mehr als acht agile Teams skaliert werden. Dieses zweite Skalierungsframework ergänzt LeSS um eine zusätzliche Rolle und weitere agile Regeln für die Zusammenarbeit von vielen Feature Teams. Bei diesem Framework werden Produktanforderungen, die aus Kundensicht starke Gemeinsamkeiten aufweisen, zu Anforderungsbereichen gruppiert. Jedem Anforde‐ rungsbereich werden vier bis acht Feature Teams und ein Area Product Owner (APO) zugeordnet. Üblicherweise spezialisieren sich die Teams eines Anforderungsbereichs und arbeiten längerfristig in diesem Bereich zusammen. Es gibt weiterhin einen (übergeordneten) Product Owner, der die Zuordnung der Feature Teams zu den Anforderungsbereichen verantwortet und eng mit den APOs zusammenarbeitet. In einem zentralen Product Backlog befinden sich alle Product Backlog Items mit der Angabe, zu welchen Anforderungsbereichen diese Items gehören. Auch bei LeSS Huge starten die Sprints aller Feature Teams zum gleichen Zeitpunkt und haben die gleiche Länge, da alle an einem integrierten Produktinkrement arbeiten. Der Product Owner und die APOs stellen durch die Priorisierung der Product Backlog Items sicher und dass die Teams an den Items arbeiten, die höchsten Wert haben. Die APOs verantworten dann die ihnen zugeordneten Product Backlog Items in Area Backlogs (siehe Abbildung 88). 176 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation Quelle: https: / / less.works/ img/ less-huge/ less-huge-framework.png Abbildung 88: LeSS Huge Framework Quelle: https: / / less.works/ img/ less-huge/ less-huge-framework.png 177 8.4 Scrum skalieren mit LeSS und LeSS Huge Im Gegensatz zu anderen Skalierungsframeworks ist LeSS ein sehr offenes Konzept. Es gibt nicht viele neue Regeln, Rollen und Artefakte. Wenn man mit Scrum bereits vertraut ist, kommt man mit LeSS schnell zurecht, da die Unterschiede zu Scrum nicht groß sind. Das Framework kann daher schnell eingeführt werden, wenn ein‐ zelne Teams bereits Scrum-basiert arbeiten. Die Leichtgewichtigkeit des Frameworks ist aber zugleich auch deren Nachteil. Das gilt insbesondere für LeSS Huge. Hier gibt es keine zusätzlichen Koordinationsprozesse und keine Ereignisse, die mehrere Anforderungsbereiche umfassen, zusammengearbeitet wird nur innerhalb eines An‐ forderungsbereichs. Das erschwert die Erstellung komplexer Produkte und auch die Ausrichtung der Entwicklertätigkeiten an der Unternehmensstrategie. Der Fokus des Frameworks liegt eindeutig auf der Umsetzung eines (komplexen) Produkts, dessen Anforderungen in einem großen Product Backlog verwaltet werden können. Das Stellvertreterprinzip beim Sprint Planning 1 und bei der teamübergreifenden Retrospektive steht im Widerspruch zu dem agilen Gedanken, dass die Teams gemein‐ sam Entscheidungen treffen und es vollständige Transparenz gibt. Die zweistufige Retrospektive kann auch aus einem anderen Grund zum Problem werden: Die Teams können unbequeme Themen in das übergeordnete Meeting abgeben, anstatt sich selbst damit auseinanderzusetzen und eine gemeinsame Lösung zu finden. Zudem ist die Rolle des Scrum Masters nicht zu unterschätzen - allein von der Anzahl der Events kann ein Scrum Master meist nur zwei bis drei Teams haben. 8.5 Scrum skalieren mit Nexus Bei Nexus handelt es sich um ein sehr junges Scrum-konformes Skalierungsframework. Mit diesem Rahmenwerk können maximal neun Scrum Teams gemeinsam ein Produkt entwickeln. Wie bei LeSS arbeiten die Teams auf Basis eines Product Backlogs in gleichzeitig stattfindenden Sprints an integrierten Produktinkrementen. Um die Inte‐ gration sicherzustellen, wird Scrum um eine neue Rolle, ein weiteres Artefakt und fünf zusätzliche Ereignisse erweitert (siehe Abbildung 89). Nexus Rollen Nexus Artefakte Nexus Ereignisse Ein Product Owner Ein Product Backlog Sprint Planning Scrum Master Sprint Backlogs Daily Scrum Entwicklungsteam Eine Definition of Done Nexus Sprint Planning Nexus Integration Team Integriertes Produktinkrement Nexus Daily Nexus Sprint Backlog Nexus Sprint Review Backlog Refinement Figure 89: Nexus Rollen, Artefakte und Ereignisse Abbildung 89: Nexus Rollen, Artefakte und Ereignisse 178 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation Das Framework wurde von Ken Schwaber und dessen Kollegen bei Scrum.org entwi‐ ckelt. Beschrieben wird das Scaling Framework im Nexus Guide, der kostenlos über die Webseite von Scrum.org bezogen werden kann. Nexus verfolgt zwei Hauptziele: Zum einen sollen Abhängigkeiten, die bei der Zusammenarbeit verschiedener Teams auftreten können, rechtzeitig erkannt und beherrschbar gemacht werden. Zum anderen sollen Integrationsprobleme, die bei der Zusammenführung der einzelnen Teilergeb‐ nisse, die die Scrum Teams erstellen, reduziert werden. Bei Nexus arbeiten drei bis neun Teams an einem gemeinsamen Product Backlog und erstellen in jeder Iteration ein neues, integriertes Produktinkrement. Wichtig ist, dass es möglichst wenige Schnittstellen zwischen diese Teams gibt, damit ein unabhängiges Arbeiten ermöglicht wird. Als zusätzliche Nexus-Rolle kommt das Nexus Integration Team hinzu (siehe Abbildung 90). Dieses Team ist dafür verantwortlich, dass in jedem gemeinsamen Sprint ein integriertes Inkrement erzeugt wird. Es soll insbesondere technische Integrationsprobleme antizipieren und diese lösen. Des Weiteren soll es dafür sorgen, dass ein Bewusstsein für die Abhängigkeiten zwischen den Teams ge‐ schaffen wird. Das Integration Team besteht aus dem Product Owner, dem Scrum Mas‐ ter und den Entwicklern. Die Entwickler des Nexus Integration Teams kümmern sich primär um Integrations- und Automatisierungsthemen. Falls sie noch freie Kapazitäten haben, können sie die dezentralen Entwicklungsteams bei der Umsetzung der Produk‐ tanforderungen unterstützen. Wie bei Scrum ist der Product Owner für die Produkt‐ vision und das zentrale Product Backlog verantwortlich. Der Scrum Master im Nexus Integration Team sorgt dafür, dass alle Teammitglieder das Nexus Framework verste‐ hen und sich an dessen Regelwerk halten. Wenn die Entwicklungsteams mit dem Scrum-Regelwerk noch nicht hinreichend gut vertraut sind, können sie auf Wunsch einen eigenen Scrum Master für ihr Team anfordern. Dieser Scrum Master übernimmt dann auf der Team-Ebene die gleichen Aufgaben wie bei Scrum. Bei Nexus gibt es ein gemeinsames Product Backlog, das so zerlegt sein sollte, dass es möglichst wenig Abhängigkeiten zwischen den Produktanforderungen gibt. Jedes Entwicklungsteam hat sein eigenes Sprint Backlog, welches die Anforderungen enthält, die das Team im aktuellen Sprint abarbeitet. Zusätzlich gibt es noch ein teamübergrei‐ fendes Nexus Sprint Backlog, welches die Items aller Entwicklungsteams enthält und deren Abhängigkeiten zeigt. Dieses übergeordnete Backlog sollte mindestens einmal täglich aktualisiert werden, damit es für die Überwachung des Sprintverlaufs eingesetzt werden kann. Die Arbeiten aller Entwicklungsteams münden in ein integriertes Pro‐ duktinkrement. Wie bei Scrum muss dieses Produktinkrement nach jedem Sprint voll funktionsfähig und potenziell releasefähig sein. Da das Nexus Framework auf Scrum aufbaut, werden auch hier einbis vierwöchige Sprints vorgeschrieben, die dann für alle Teams gemeinsam beginnen und enden. Im Gegensatz zu Scrum ist bei Nexus das Backlog Refinement obligatorisch. Ziel dieser Veranstaltung ist es, aus noch unkonkreten Ideen des Product Backlogs präzise An‐ forderungen zu entwickeln, die dann in den kommenden Sprints umgesetzt werden können. Wie bei Scrum gibt es auch bei Nexus ein Sprint Planning-Ereignis, das zum 179 8.5 Scrum skalieren mit Nexus Abbildung 90: Nexus Framework Quelle: https: / / scrumorg-website-prod.s3.amazo naws.com/ drupal/ 2021-01/ Scrumorg-Nexus-Frame work-tabloid%20%281%29.pdf Ziel hat, die relevanten Product Back‐ log-Anforderungen für den nächsten Ite‐ rationslauf zu identifizieren. Da das ge‐ samte Nexus Team aus bis zu 100 Projektmitgliedern bestehen kann, ist ein Sprint Planning mit allen Teammit‐ gliedern eine Herausforderung. Daher empfiehlt Nexus, dieses Ereignis in zwei Teile zu zerlegen: Am ersten Nexus Sprint Planning nehmen alle Entwick‐ lungsteams teil. In dieser Veranstaltung sollen die Anforderungen für die einzel‐ nen Sprint Backlogs bestimmt und die Abhängigkeiten zwischen den team‐ übergreifenden Anforderungen identifi‐ ziert werden. Im Anschluss plant dann jedes Entwicklungsteam im sogenann‐ ten Team Planning seinen individuellen Sprint. Mit dieser Zweiteilung ist sicher‐ gestellt, dass die einzelnen Sprintziele mit dem Nexus-Ziel über-einstimmen, dass jedes Team ein eigenes Sprint Back‐ log erhält und dass die notwendigen In‐ formationen für die Erstellung des über‐ geordneten Nexus Sprint Backlogs vorhanden sind. Wie bei Scrum hält jedes Entwick‐ lungsteam ein tägliches Daily Scrum ab. Ergänzend gibt es noch jeden Tag ein Nexus Daily Scrum. An diesem Treffen nehmen die Mitglieder des Nexus Inte‐ gration Teams und Repräsentanten der einzelnen Entwicklungsteams teil. Ziel des Events ist es, während der Sprint‐ verläufe den aktuellen Stand der Inte‐ gration zu prüfen und das gemeinsame Nexus Sprint Backlog zu aktualisieren. Am Ende der parallel durchgeführten Sprints treffen sich alle Scrum Teams mit den Projekt-Stakeholdern zum Nexus Sprint Review. In dieser Besprechung wird das integrierte Produktinkrement vorgestellt, das Feedback der Stakeholder eingeholt und der Product Owner überarbeitet anschließend gegebenenfalls das Product Backlog. Bevor die nächsten Sprints wieder mit dem Back‐ 180 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation log Refinement vorbereitet werden, findet noch die Nexus Sprint Retrospektive statt. Wie beim Nexus Sprint Planning wird diese Veranstaltung in mehrere Teile zerlegt. Im ersten Meeting treffen sich Repräsentanten der einzelnen Teams und identifizieren gemeinsam Verbesserungsmöglichkeiten des übergeordneten Nexus-Prozesses. An‐ schließend werden teamindividuelle Retrospektiven durchgeführt, die genauso ablau‐ fen wie bei Scrum. Abschließend treffen sich nochmals die gleichen Vertreter wie im ersten Meeting und beschließen Verbesserungsmaßnahmen für die Zusammenarbeit in den zukünftigen Sprints. Wie bei LeSS versteht man das bewusst einfach gehaltene Nexus Framework schnell, wenn man bereits mit Scrum vertraut ist. Positiv hervorzuheben ist, dass der Schwerpunkt auf der Behebung von Integrationsproblemen und auf der Sicherstellung der teamübergreifenden Zusammenarbeit liegt. Diese beiden Themen werden bei Nexus weitaus besser berücksichtigt als bei LeSS. Gibt es bei der Produktentwick‐ lung aber wenig inhaltliche Überlappungen zwischen den Teams, erzeugen die zu diesem Zweck definierten Nexus-Ereignisse unnötigen Administrationsaufwand. Ein weiteres Problem des Nexus Frameworks ist die Beschränkung auf maximal neun Entwicklerteams, die daher rührt, dass nur ein Product Owner vorgesehen ist, der das gemeinsame Product Backlog verantwortet. Eine Erweiterung des Frameworks, wie sie bei LeSS mit LeSS Huge vorgesehen ist, gibt es bei Nexus nicht. Problematisch an Nexus ist auch, dass es keine Hinweise darauf gibt, wie ein Nexus Team in die Unternehmensorganisation integriert werden kann. 8.6 Neuaufstellung der Organisation mit dem Spotify-Ansatz Henrik Kniberg und Anders Ivarsson skizzieren erstmals in einem 2012 erschienen Blog das Spotify-Fallbeispiel. Die beiden sind in der agilen Community bekannt und tragen regelmäßig auf Veranstaltungen vor. Streng genommen handelt es sich beim Spotify-Modell nicht um ein Skalierungsframework, sondern um eine Beschreibung der agilen Arbeitsweise Audio-Streaming-Unternehmen Spotify S. A., das 2006 gegründet wurde. Die Spotify-Mitarbeiter haben von Beginn an in agilen Iterationen die Unter‐ nehmensprodukte entwickelt und ihre Arbeitsweise in den darauffolgenden Jahren kontinuierlich weiterentwickelt. Die Unternehmensberatung McKinsey & Company hat basierend auf dem Blogeintrag von Kniberg und Ivarsson ein agiles Organisations‐ modell erstellt, das von vielen Unternehmen übernommen wurde. 181 8.6 Neuaufstellung der Organisation mit dem Spotify-Ansatz PO PO PO PO Tribe S q u a d PO PO PO PO Tribe Chapter Chapter Chapter Chapter S q u a d S q u a d S q u a d S q u a d S q u a d S q u a d S q u a d GUILD TL TL AC AC Figure 91: Spotify Modell Abbildung 91: Spotify-Modell Zentrales Element im Spotify-Modell sind Squads. Diese selbstorganisierten, funkti‐ onsübergreifenden Gruppen von bis zu acht Personen sind am ehesten mit Scrum Teams vergleichbar. Sie haben keinen Teamleiter, sondern nur einen Product Owner, der die Aufgaben des Teams priorisiert. Squads, die an einem gemeinsamen Produkt oder fachlich ähnlichen Themen arbeiten, werden bei dem Spotify-Modell zu einem Tribe zusammengefasst. Ein solcher Tribe sollte maximal 125 Personen umfassen. Auch bei diesem Ansatz wird ein Bezug zur Dunbar-Zahl hergestellt. Jeder Tribe hat einen Tribe Leader und einen agilen Coach. Der Tribe Leader ist für die Produktentwicklung seines Tribes verantwortlich. Er soll sich unter anderem mit anderen Tribe Leadern abstimmen und Abhängigkeiten zwischen den Produkten der verschiedenen Tribes identifizieren. Inhaltliche Abhängigkeiten zwischen den Tribes sollten aber auf ein Minimum reduziert werden. Der agile Coach eines Tribes ist mit einem Scrum Master eines Scrum Teams vergleichbar. Er organisiert die agilen Events, beseitigt mögliche Hindernisse und unterstützt bei der Etablierung agiler Werte und der stetigen Verbesse‐ rung der agilen Arbeitsweise in den Squads. Der Informationsaustausch zwischen den Squads eines Tribes erfolgt über themenbezogene Chapter. In dem Chapter eines Tribes werden beispielsweise alle Datenbankexperten oder Entwickler von Web-Oberflächen zusammengefasst. Auf Chapter-Ebene finden auch themenspezifische Schulungen statt und es können Gastredner zu Chapter-Treffen eingeladen werden. Koordiniert werden die Chapter von Chapter Leads, die gleichzeitig die Disziplinar‐ vorgesetzten der Mitarbeiter eines Tribes sind und die Chapter-Mitglieder bei ihrer individuellen Weiterentwicklung begleiten. Grundsätzlich sollte der Chapter Lead operative Tätigkeiten in seinem Tribe übernehmen. Ist das Chapter aber sehr groß, gibt es die Notwendigkeit strategische Themen auszuarbeiten oder müssen verschiedene 182 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation Standards festgelegt werden, sollte davon Abstand genommen werden. Diese Struktur ermöglicht es den Mitarbeitern, problemlos zwischen Squads innerhalb eines Tribes zu wechseln, der Vorgesetzte ändert sich dadurch nicht. Ein Squad-Mitglied bewegt sich daher immer in einem Spannungsfeld zwischen „Was muss ich tun? “ (Vorgaben durch den Product Owner) und dem „Wie muss ich es tun? “ (Vorgaben durch den Chapter Lead). Diese Organisationsstruktur folgt dem „professor and enterpreneur“-Ansatz von Mary und Tom Poppendieck, bei dem eine fruchtbare Auseinandersetzung zwischen dem Chapter Lead, der den Professor repräsentiert, und dem Product Owner, der die Rolle des Unternehmers übernimmt, entstehen soll. Ziel ist es, dass ein Tribe ein am Kundenbedarf ausgerichtetes Produkt auf hohem technischem Niveau erstellt. Für den Tribe-übergreifenden Informationsaustausch gibt es Gilden (Guilds), die vergleichbar mit Communities of Interest sind. Jede Gilde wird von einem Guild Leader geführt. Dieser freiwillige Zusammenschluss von Experten dient dazu, grundsätzliche Themen, die mehrere Tribes in der Unternehmensorganisation betreffen, voranzutrei‐ ben. An einer Gilde kann jeder teilnehmen, der über eine entsprechende Expertise verfügt und bei der Lösung von fachspezifischen Themen unterstützen möchte. Hier wird beispielsweise besprochen, wie Software-Tests automatisiert werden können oder welche Richtlinien bei der Erstellung von Benutzerschnittstellen gelten. Neben den Softwareentwicklern können sich auch die agilen Coaches der Unternehmensorganisa‐ tion zu einer Gilde zusammenfinden, um sich zu agilen Fragestellungen auszutauschen. Eine Gilde kann auch jederzeit wieder verlassen werden. Der Guild Leader hat dafür zu sorgen, dass sich die Mitglieder einer Gilde in regelmäßigen Abständen zu einem Fachaustausch treffen (siehe Abbildung 91). Die Mitarbeiter eines Squads entscheiden eigenverantwortlich, wie sie ihre Arbeit organisieren und die aufkommenden Probleme lösen. Sie wählen insbesondere selbst, welche agilen Methoden und Werkzeuge verwendet werden. Die Arbeitsweise der Squads ist also nicht standardisiert. Hat ein Squad eine passende Methodik gefunden, können andere Squads diese übernehmen. So befruchten sich die Squads gegenseitig. Bezeichnend für die Arbeitsweise bei Spotify ist auch die Fehleroffenheit. Daniel Ek, CEO von Spotify, hat von Beginn an ein fehlerfreundliches Arbeitsumfeld eta‐ bliert. Diese offene Fehlerkultur regt die Mitarbeiter dazu an, verschiedene Dinge auszuprobieren. Spotify-Mitarbeiter können 10 % ihrer Arbeitszeit ohne Vorgaben experimentieren (Hack Time). Da alle eigenständig arbeiten, können die hierbei entstehenden Fehler auch wieder schnell behoben werden. Kniberg und Ivarsson weisen in ihrem Blog darauf hin, dass die beschriebene Un‐ ternehmensorganisation nur eine Momentaufnahme sei. Ganz im Sinne der agilen Prinzipien Inspect und Adapt wird die Organisationsstruktur kontinuierlich weiter‐ entwickelt. Inzwischen ist die Mitarbeiterzahl von Spotify auf über 4.000 angewachsen. Daher musste das Organisationsmodell entsprechend erweitert werden. Squads, die zu Tribes zusammengefasst werden, konnten diese Organisation nicht mehr adäquat ab‐ bilden. Zwei wesentliche Änderungen werden im Folgenden genauer beschrieben. Um 183 8.6 Neuaufstellung der Organisation mit dem Spotify-Ansatz Squad Squad Squad Squad PO PO PO PO Tribe TL PL DL Squad Squad Squad Squad PO PO PO PO Tribe TL PL DL Squad Squad Squad Squad PO PO PO PO Tribe TL PL DL TH PH DH Alliance Alliance Leadership Tribe Leadership Tribe Leadership Tribe Leadership Figure 92: Alliances im Spotify Modell Abbildung 92: Alliances im Spotify-Modell den Austausch zwischen Tribes, die eine ähnliche Kundenausrichtung haben, zu er‐ leichtern, werden Tribes zu Alliances gruppiert. So wird eine vertikale Abstimmung in der Organisationsstruktur ermöglicht. Bei einer Versicherung würde man beispiels‐ weise Tribes zusammenfassen, die unterschiedliche Versicherungsprodukte für das gleiche Kundensegment entwickeln. Die zweite Änderung betrifft die Führung der Tribes und der Alliances. Da ein Tribe aus relativ vielen Squads bestehen kann, gibt es ein Tribe Leadership, das für die Führung des Tribes verantwortlich ist. Dieses Füh‐ rungstrio besetzt drei wesentliche Kompetenzen bei der agilen Software-Entwicklung: Es besteht aus einem Tech Lead, einem Product Lead und einem Design Lead. Diese drei verantworten auch die Chapter ihres Tribes. Die gleiche Leadership-Struktur exis‐ tiert auf Alliance-Ebene. Dort gibt es einen Tech Head, einen Product Head und einen Design Head (siehe Abbildung 92). Ein Vorteil des Spotify-Modells ist sicherlich die Offenheit, der Freiraum für eigene Gestaltungsmöglichkeiten bietet. Positiv hervorzuheben sind auch der Fokus auf die Selbstorganisation der Mitarbeiter und die gelebte Fehlerkultur. Das Leadership auf Tribe- und Alliance-Ebene bildet zudem mit der Produktausrichtung, der Technologie und dem Design die wesentlichen Kompetenzbereiche die Softwareentwicklung ab. Die Freiräume des Modells werden von klassischen Organisatoren gerne mit nicht-agilen Elementen besetzt. Sie sind daher nicht so gut geeignet für Organisationen, die bisher wenig bis keine Berührungspunkte mit agilen Konzepten hatten. Zwei wesentliche 184 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation Anforderungen sind beispielsweise, dass der Chapter Lead der disziplinarische Vorge‐ setzte der Mitarbeiter ist und die fachlichen Anforderungen vom Product Owner im Squad kommen. Um diesen Konflikt aufzulösen, wird klar gesagt, dass ein Chapter keine Lieferverantwortung hat. Ein weiterer Nachteil ist auch, dass es keine Zertifizierungen (wie bei SAFe oder LeSS) als Kompetenznachweis gibt. Es gibt auch keine Transition Roadmap. Es wird nur beschrieben, wie eine solche Organisation aufgebaut ist, aber nicht wie man da hinkommt. Da es sich beim Spotify-Modell nicht um ein Framework handelt, das von einer Organisation weiterentwickelt wird, gibt es im Gegensatz zu SAFe und LeSS keine offiziellen Dokumentationen. Inhaltliche Schwächen hat das Spotify-Modell bei der Portfoliosteuerung und bei der Unterstützung vieler Projekte, die parallel stattfinden und größere Abhängigkeiten aufweisen. Eine Herausforderung in der Praxis ist auch die Gruppierung der Squads zu Tribes, da Unternehmen dazu neigen, große Tribes zu bilden, um deren Anzahl möglichst gering zu halten. Aber selbst, wenn man sich an die Empfehlung von Spotify hält, dass ein Tribe maximal 100 Mitglieder enthalten sollte, kann die Größe problematisch werden. Ein Tribe dieser Größenordnung hat zwischen zwölf und 16 Squads mit eigenen Product Ownern, circa vier bis sieben Business Chapter mit eigenen Chapter Leads und ungefähr drei Business Experten pro Squad. Damit ergibt sich für die Tribe Leads eine Leitungsspanne von über 20, was zu einer Überforderung der Führungskräfte führen kann. Bei sehr großen Tribes übernehmen die Product Owner daher häufig einen Großteil der Verantwortung und der strategischen Aufgaben. Aufgrund der wenigen Tribes ist es jedoch schwierig, zu einem Tribe Lead aufzusteigen. Eine Lösung für dieses Problem wäre beispielsweise, eine Orientierung am LeSS Framework: Product Owner sind für mehrere Squads verantwortlich und die Teams arbeiten eigenverantwortlicher. 8.7 Agile Skalierung für große Organisationen mit SAFe Das Scaled Agile Framework (SAFe) ist das am weitesten verbreitete Framework, um die agile Produktentwicklung zu skalieren. Laut dem 14th Annual State of Agile Report vom Mai 2020 setzen 35 % der befragten Organisation, die ein agiles Skalierungsfra‐ mework verwenden, auf SAFe. 2019 waren es 30 % und im Jahr davor 29 %. Die Tendenz ist daher steigend. Das Rahmenwerk wurde erstmals 2011 von Dean Leffingwell und Drew Jemilo vorgestellt und wird seitdem kontinuierlich weiterentwickelt. Die aktuelle Version 5.0 wurde im Januar 2020 publiziert. Ziel von SAFe ist es, ein umfassendes Framework mit konkreten Vorgaben und Praktiken anzubieten. Das Framework beschreibt nicht nur, wie die agile Produktentwicklung skaliert werden kann, sondern auch den dazu passenden Budgetprozess und die Portfolio-Planung auf strategischer Ebene. Bei SAFe kommen unterschiedliche agile Techniken wie beispielsweise Scrum, Extreme Programming, Kanban, Lean oder DevOps zum Einsatz. 185 8.7 Agile Skalierung für große Organisationen mit SAFe Bei SAFe werden vordefinierte Praktiken und eine Implementierungs-Roadmap angeboten. Ziel ist es, Unternehmen dabei zu unterstützen, agile Prinzipien und Methoden über die gesamte Organisation zu skalieren. Hierbei spielt der Lean-Gedanke eine große Rolle. Alle Aktivitäten der Wertschöpfungskette sollen optimal aufeinander abgestimmt sein und jedwede Verschwendung muss vermieden werden. Auf operativer Ebene arbeiten Teams, die den agilen Prinzipien folgen und agile Methoden einsetzen, während bei der Koordination auf der übergeordneten Ebene das prozessorientierte Lean Management und der Wertstrom, den Produkte durchlaufen, im Mittelpunkt stehen. Es geht also nicht nur um die reine (Software-)Entwicklung, sondern auch die vor- und nachgelagerten Prozessschritte und Abteilungen wie Produktentwicklung, Marketing und Vertrieb. Auch das Management ist von diesen Veränderungen betrof‐ fen, da agile Produkt- und Produktentwicklungsteams eine andere Erwartungshaltung gegenüber ihrer Führungsspitze haben. Mit den Essentials SAFe, Large Solution SAFe, Portfolio SAFe und FullSAFe gibt es vier SAFe-Konfigurationen für unterschiedliche Skalierungsebenen (siehe Abbildung 93). Für jede Konfiguration gibt es die jeweils passenden Rollen, Artefakte und Events. Eine Organisation muss aber nicht alle vier Ebenen einführen. Die oberen Ebenen sind im Prinzip nur für sehr große Unternehmen relevant. Es sind auch mehrere parallele SAFe-Implementierungen denkbar. Das SAFe Essential, das am ehesten mit LeSS vergleichbar ist, wird immer benötigt. Bei dieser Ausbaustufe entwickeln agile Teams, die aus fünf bis elf Personen bestehen, in zweiwöchigen Iterationen werthaltige Funktionalitäten, die vorzugsweise in Form von User Stories beschrieben sind. Die Teams sollten als Feature Teams organisiert sein, um möglichst selbständig neue Funktionalitäten liefern zu können. Hierbei wird zwi‐ schen Business und Technology Teams unterschieden und für beide Team-Typen wer‐ den entsprechende Anleitungen bereitgestellt. Bei der Umsetzung der Anforderungen können agile Methoden wie Scrum oder Kanban verwendet werden. In einem agilen Team gibt es die Scrum-Rollen Product Owner und Scrum Master. Diese sind hier leicht abgewandelt. Der Product Owner unterstützt das Team bei der Produktentwicklung, indem er die Kundenperspektive einnimmt. Wie beim Scrum Framework demonstriert das Team am Ende einer Iteration in einem Iteration Review, was es entwickelt hat. In der Iteration Retrospektive wird die Arbeitsweise reflektiert (siehe Abbildung 94). Der Scrum Master ist der Teamcoach, der dem Team dabei hilft, besser zu werden und die unterschiedlichen Events durchzuführen. Zusätzlich soll er die Synchronisation seines Teams mit der übergeordneten Programmebene sicherstellen. In größeren Organisationen arbeiten häufig mehrere agile Teams gemeinsam daran, einen Wert zu erzeugen. Fünf bis zehn Teams werden bei SAFe zu einem Agile Release Train (ART) zusammengefasst. Ein solcher ART besteht daher aus 50 bis 125 Personen und erreicht in seiner größten Ausbaustufe fast die Dunbar-Zahl. Er ist ein dauerhafter Zusammenschluss agiler Teams, Stakeholder und anderer Beteiligter, der in Form von Programminkrementen einen Wert liefert. Der funktionsübergreifende ART vereint alle relevanten Fähigkeiten, um einen permanenten Wertefluss zu gewährleisten. Auf 186 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation Large Solution SAFe Portfolio SAFe Agile Release Train SAFe Essential Sprint eines SAFe-Teams Agile Release Train Agile Release Train Agile Release Train Figure 93: Ausbaustufen bei SAFe Abbildung 93: Ausbaustufen bei SAFe SM PO Woche 1 Woche 2 R e t r o s p e k t i v e P l a n e n & C o m m i t Realisieren Sprint Figure 94: SAFe-Team Abbildung 94: SAFe Team dieser Ebene kommen weitere Rol‐ len hinzu. Der Release Train Engi‐ neer (RTE) fungiert als agiler Coach und entspricht einem Scrum Master auf Teamebene. Der Produktmana‐ ger fungiert als Product Owner für den Release Train. Systemarchitek‐ ten geben die architektonischen Richtlinien vor. Sie sollen sicherstel‐ len, dass die Entwicklung neuer Funktionalitäten konsistent vonstattengeht und ein‐ heitliche Architekturprinzipien verfolgt werden. 187 8.7 Agile Skalierung für große Organisationen mit SAFe Die Teams eines ARTs arbeiten mit synchronisierten Sprintlängen und schaffen in einem Supersprint, alle acht bis zwölf Wochen, ein neues Produktinkrement. Mit dieser festen Taktung wird auch auf Programmebene die Wertschöpfung plan- und messbar. Teams, die in einem gemeinsamen ART arbeiten, stimmen sich anhand der Produk‐ tinkremente aufeinander ab. Hierfür gibt es ähnliche Events wie auf Team-Ebene. Zu Beginn einer ART-Iteration treffen sich alle Teams zum PI-Planning Event, das vom Release Train Engineer ausgerichtet wird. In diesem Meeting planen alle gemein‐ sam in einem Face-To-Face-Gruppenformat, welche Funktionalitäten im aktuellen Programminkrement erstellt werden sollen. Für dieses Event gibt SAFe eine „time box“ von ein bis zwei Tagen vor. Das Product Management liefert die Produktvision und das Backlog. Mithilfe eines Program Boards werden die Abhängigkeiten zwischen den Teams visualisiert. Die Sprint Backlog Items der einzelnen SAFe Teams werden in die Kategorien Fehlerbehebung, PI-Planning Items und ungeplante zusätzliche Items gruppiert. Die höchste Priorität hat die erste Kategorie. SAFe empfiehlt, die Sprints nur zu 30 bis 70 % mit Items zu füllen, damit genügend Kapazitäten für die Fehlerbehebung und für ungeplante Items vorhanden sind. Die Teams synchronisieren ihre Inhalte alle zwei Wochen bei einer integrierten Produktpräsentation. Am Ende eines Supersprints gibt es ein gemeinsames Review Meeting und in einem Inspect-and-Adapt-Workshop werden Verbesserungsmöglichkeiten identifiziert. Alle Teams prüfen gemeinsam, wie gut die Arbeit im letzten PI funktioniert hat und wie sie verbessert werden kann. Diese Events ersetzen aber nicht die Meetings der Teams, sie haben vielmehr zum Ziel, den Fortschritt des ARTs zu inspizieren (siehe Abbildung 95). P l a n e n & S c h ä t z e n D e m o I n s p e c t & A d a p t Programminkrement 10 Wochen Figure 95: Agile Release Train Abbildung 95: Agile Release Train Die Bezeichnung ART ist leicht irreführend, neue Funktionalitäten können jederzeit geliefert werden. Diese müssen nicht am Ende eines Supersprints zu einem Release zusammengefasst werden. Es gilt die Regel, dass im Takt entwickelt und nach Bedarf 188 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation geliefert wird. Das Product Management verwendet Customer Centricity und Design Thinking, um Lösungen zu identifizieren, die desirable, viable und feasable sind. Large Solution SAFe: Bei der Entwicklung sehr großer und komplexer Produkte werden mehrere ARTs zu einem Solution Train, beziehungsweise zu einem Wertstrom, zusammengefasst. Es wird eine Enterprise Solution Delivery benötigt, bei der ein Solution Train dann mehrere ARTs und Suppliers koordiniert. Für die Kontrolle und Koordination des auf dieser Ebene entwickelten Wertstroms wird ein Solution Backlog benötigt. Das Solution Management verantwortet den Inhalt der Solution, der Solution Architect verantwortet die Architektur über alle ARTs hinweg und der Solution Train Engineer unterstützt bei der Durchführung der Solution Train Events. Portfolio SAFe Ziel des Lean Portfolio Managements ist es, auf oberster Ebene die Unternehmensvorhaben zu prüfen, zu priorisieren und sie an die unterschiedlichen Wertströme zu übergeben. Mithilfe einer Portfoliovision wird ein übergeordnetes Ziel vorgegeben und die hieraus abgeleitete Strategie soll dann auf Ebene der Wertströme umgesetzt werden. Diese Vorhaben auf Wertstromebene werden in Form von Epics formuliert, dann in der Wertstromebene delegiert und dort in Features aufgeteilt. Aus Sicht des klassischen Managements kann man also große Arbeitspakete schnüren und budgetieren, die dann über ARTs ausgeliefert werden. Bei den Epics wird zwischen kundenorientierten Business Epics und technischen Enabler Epics unterschieden. Die Epics werden wiederum aus einem übergeordneten Investment abgeleitet. Ein Investment hat einen Planungshorizont von sechs bis zwölf Monaten. Mithilfe eines Portfolio-Kanbans sollen die aktiven Vorhaben visualisiert und der Work In Progress auf strategischer Ebene limitiert werden. Abgearbeitet werden die Epics über ein Portfolio Backlog. Abbildung 96 zeigt das vollständige SAFe-Diagramm, in dem alle Skalierungsebenen enthalten sind. 189 8.7 Agile Skalierung für große Organisationen mit SAFe Figure 96: SAFe-Framework Abbildung 96: SAFe Framework Quelle: www.scaledagileframework.com/ wp-content/ uploads/ delightful-downloads/ 2021/ 01/ Scaled-A gile-Framework_Full_8.5x11-1.pdf 190 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation Interessant an SAFe ist, dass der Fokus dieses Frameworks nicht auf einzelne agile Teams liegt, sondern auf der Koordination vieler Teams und der Abstimmung zwischen diesen. Im Mittelpunkt von SAFe stehen ARTs, die einen kontinuierlichen Wertstrom für die Kunden erzeugen sollen. Im Gegensatz zu den anderen Frameworks wird sehr genau beschrieben, wie mithilfe eines Lean Portfolio Managements auf oberster Unternehmensebene die Budgetierung in einem agilen Umfeld umgesetzt werden kann. Ein wesentlicher Vorteil von SAFe besteht darin, dass es zahlreiche Hilfestellungen gibt, wie das Framework eingeführt werden kann. Es ist ein sehr detailliertes Rahmen‐ werk, das alle Ebenen großer Organisation berücksichtigt und für jede SAFe-Konfigu‐ ration Rollen, Artefakte und Events beschreibt. Neben dieser Schritt-für-Schritt-An‐ leitungen für die Skalierung gibt es auch eine Implementierungs-Roadmap für die Ersteinführung. Unternehmen, die noch keine bzw. wenig Erfahrung mit agilen Methoden gesammelt haben, wird dadurch der Wechsel in die agile Welt erheblich erleichtert. SAFe spricht daher insbesondere Führungskräfte an, die mit (klassischen) komplexen Projektmanagementsystemen vertraut sind und nun agile Methoden und Organisationsstrukturen etablieren möchten. Insbesondere die vorgegebenen Rollen, die für die unterschiedlichen Ausbaustufen angeboten werden, machen es klassischen Unternehmen einfach, die bisher verwendeten Stellen in das Framework zu transfor‐ mieren. Der notwendige Anpassungsbedarf erscheint dadurch gering. Das ist sicherlich auch der Grund dafür, dass SAFe bei großen Konzernen wie der Deutschen Bahn sehr populär ist. Gleichzeitig ist das aber auch ein Nachteil dieses Frameworks. Aufgrund der großen Anzahl an Ebenen, Rollen und Events wirkt SAFe sehr komplex und erfordert einen hohen Einarbeitungsaufwand. Sobald sich Unternehmen umfassend eingearbeitet haben, orientieren sie sich häufig zu stark an den SAFe-Vorgaben. Sie interpretieren das Framework als eine fest vorgegebene Blaupause, die exakt so in der eigenen Organisation implementiert werden muss. Dadurch entsteht eine Scheinagili‐ tät und die Autonomie der Teams wird eingeschränkt. Teams, die zu einem hohen Grad selbstorganisiert sind, fühlen sich durch das Framework häufig eingeschränkt. Letztlich ist SAFe ein Kompromiss zwischen agiler und klassischer Vorgehensweise. Es ist daher interessant für Großkonzerne und wird gleichzeitig von der agilen Community sehr kritisch gesehen, da die agilen Teams vorab definierte Themen umsetzen, eine Selbstorganisation ist dann nicht wirklich erforderlich. SAFe-Verfechter argumentieren hingegen, dass selbstorganisierte Einheiten in großen Organisationen dazu neigen, „siloartig“ zu arbeiten und sich von der restlichen Organisation entfernen. 191 8.7 Agile Skalierung für große Organisationen mit SAFe 8.8 Wahl des richtigen Skalierungsframeworks Wenn man vor der Herausforderung steht, agil skalieren zu müssen, kann man auf ein bestehendes Framework zurückgreifen oder sich eine unternehmensindividu‐ elle Lösung überlegen. Eine dogmatische Befolgung der Vorgaben eines einzelnen Skalierungsframeworks widerspricht dem agilen Grundverständnis. Ein sinnvoller Implementierungsansatz kann so aussehen, dass man ein bereits existierendes Skalie‐ rungsframework als Startbasis verwendet und dieses Modell dann im Zeitverlauf an die individuellen Unternehmensanforderungen anpasst. Abbildung 97 zeigt, welches Ska‐ lierungsframework sich am besten für welchen Anwendungsbereich eignet. Anhand der Abbildung wird auch ersichtlich, wie komplex das jeweilige Skalierungsframework und wie groß der administrative Overhead ist, der sich bei der Verwendung des jeweiligen Frameworks ergibt. Projekt Produkt Programm Portfolio Organisation g e r i n g h o c h K o m p l e x i t ä t Anwendungsbereiche Scrum LeSS Nexus LeSS Huge SAFe Spotify Modell Figure 97: Anwendungsbereiche der Skalierungsframeworks Abbildung 97: Anwendungsbereiche der Skalierungsframeworks Hierbei kann man sich beispielsweise am dreistufigen Lernmodell Shu-Ha-Ri orientie‐ ren. Die unterste Stufe „Shu“ steht für „Gehorchen“. In diesem Anfängerstadium lernt man, indem ein vorgegebenes Regelwerk akribisch befolgt wird. Die zweite Stufe „Ha“ kann mit „Abschweifen“ übersetzt werden. Nachdem das Gelernte verinnerlicht wurde, kann es an die eigenen Bedürfnisse angepasst werden. „Ri“, als höchste Stufe bedeutet „Verlassen“. Wenn dieses Lernstadium erreicht wurde, können vollständig neue Lösun‐ gen entwickelt werden. Übertragen auf agile Skalierungsframeworks bedeutet das, dass man anfangs dem Regelwerk einem bereits existierenden Skalierungsframework folgt. In den späteren Ha- und Ri-Phasen kann das Modell dann an einzelnen Stellen korrigiert und letztlich vollständig an die unternehmensindividuellen Anforderungen 192 8 Agile Skalierung - Auf dem Weg zur lernenden Organisation angepasst werden. Anpassungen am Skalierungsframework können beispielsweise in der Retrospektive am Ende eines Sprints diskutiert werden. Denkbar ist auch, über einen Hybrid-Ansatz nachzudenken. Hierbei werden die verschiedenen Skalierungsframeworks lediglich als Inspirationsquelle genutzt und Ele‐ mente unterschiedlicher Frameworks so kombiniert, dass sich ein optimales Ergebnis für die eigene Organisation ergibt. Bei diesem „Best-of-Breed-Ansatz“ geht es also nicht darum, ein Skalierungsframework von der Stange stur zu implementieren, sondern die gewählten Rollen müssen von den Beteiligten sinnvoll interpretiert und Sinn und Zweck der etablierten agilen Praktiken von allen verstanden werden. Typische Heraus‐ forderungen bei der agilen Skalierung sind die Etablierung einer teamübergreifenden Produktvision, die Synchronisation der Teams, die Komplexitätsbeherrschung und die Kommunikation zwischen den Teams. Für diese Themen findet man in den behandelten Frameworks Lösungsansätze, die miteinander kombiniert werden können. 193 8.8 Wahl des richtigen Skalierungsframeworks 9 Epilog von Dr. Christopher Jud (Kaufland Digital) Die Digitalisierung und eine zunehmend (technologisch-)komplexe Welt stellen in‐ zwischen hohe Anforderungen an das Projektmanagement eines Unternehmens. Die Innovationsgeschwindigkeiten beschleunigen massiv, Lebenszyklen von digitalen Produkten werden kürzer und wechselnde, häufig divergierende Anforderungen ver‐ schiedener Akteure müssen in Projekten berücksichtigt werden. Dies erfordert es, schnell und flexibel auf die veränderten Bedingungen reagieren zu können. Mit agilen Projektmanagementmethoden haben Unternehmen die Möglichkeit, die entstehende Komplexität methodisch zu adressieren. In agilen Methoden wird in kleinen Iterationen gearbeitet. Durch dieses Vorgehen kann schnell auf geänderte Rahmenbedingungen reagiert und die Ausrichtung eines Projekts angepasst werden. Aus diesem Grund wurden agile Methoden in den letzten Jahren in immer mehr Unternehmen eingeführt. In vielen Bereichen ist eine agile Ausrichtung von Organi‐ sationen bereits jetzt nicht mehr wegzudenken (und dies gilt nicht nur für Start-ups)! Die Umstellung auf eine agile Arbeitsweise stellt für die Unternehmen jedoch eine große Herausforderung dar. Denn es erfordert von allen Beteiligten die Bereitschaft, gewohnte und etablierte Herangehensweisen zu hinterfragen und sich auf einen neuen „Modus operandi“ einzulassen. Vor diesem Hintergrund muss der Umstellungs‐ prozess auch als ein Change-Prozess gesehen werden, der begleitet werden will. Alle Akteure müssen auf diesen Weg mitgenommen werden. Die Implementierung der neuen Methode muss in bestehende Hierarchien, Rollen und Aufgabenverständnisse eingebunden werden. Nur so kann eine „Abstoßreaktion“ innerhalb der Organisation vermieden werden. Das „Buy-in“ von Führungskräften und dem Management ist hierfür eine häufig unterschätzte, aber vitale Komponente! In den meisten Fällen ist für die agile Arbeitsweise Scrum das Mittel der Wahl. Bereits seit den 1990er Jahren gibt es das Scrum-Framework. Heute ist es die verbreitetste der agilen Methode, um u. a. Projekte agil zu managen. Entsprechend hoch sind die Erwartungshaltungen bei der Einführung von Scrum in Organisationen. Der frei verfügbare Scrum-Guide führt in die Grundstrukturen von Scrum ein und beschreibt abstrakt das Zusammenspiel der verschiedenen Komponenten des Scrum-Frameworks. Bisweilen wird versucht, den Scrum-Guide 1: 1 im Unternehmen abzubilden. Manch‐ mal werden nur Teile des Scrum-Frameworks eingeführt - sei es um die gesetzten Ziele schnell(er) zu erreichen oder große organisatorische Adaptionen zu vermeiden. Häufig wird dabei das ganze Potenzial von Scrum nicht voll ausgeschöpft. Denn der Scrum-Guide stellt kein allgemeingültiges Kochrezept für die erfolgreiche Implemen‐ tierung von Scrum dar! Die Einführung einer solchen Methodik muss organisations‐ spezifisch stattfinden. Dies setzt jedoch ein grundlegendes Verständnis von Scrum und einer agilen Arbeitsweise voraus. Genau hier setzt der „Reiseführer“ von Jörg Brüggenkamp, Peter Preuss und Tobias Renk an. Er erklärt das grundlegende Verständnis von Scrum und hilft anhand von konkreten Beispielen aus der Unternehmenspraxis, die einzelnen Kompetenten und Rollenbilder von Scrum zu verstehen. Dies erleichtert die organisationsspezifi‐ sche Implementierung von Scrum und hilft, potenzielle Problemfelder frühzeitig zu identifizieren. So können Sie Ihre Organisation optimal auf die Reise in die agile Arbeitsmethode begleiten. Dr. Christopher Jud Head of Business Technology & Agile Management Kaufland Digital 196 9 Epilog von Dr. Christopher Jud (Kaufland Digital) Register Abstraction Sheet 130 Agile Release Train 186 Agile Skalierung 161 Alliance 184 Area Product Owner 176 Backlog Estimation 71 Backlog-Gesundheit 132 Backlog Grooming 71 Burnup-Chart 120 Business Value 83 Chapter 182 Chapter Leads 182 Commitment 16 Community of Practices 168 Continuous Integration/ Continuous Deployment 90 Cumulative Flow Diagram 119 Cycle Time 127 Cynefin Modell 150 Daily Scrum 97 Definition of Done 17, 69 Design Thinking 152 Dunbar-Zahl 176 Dysfunktionen von Teams 32 Empirische Prozesssteuerung 13 Epic 55 Feature 55 Feature Roadmap 47 Feature Team 162 Gilde 183 Goal-Question-Metric-Modell 129 Hindernis 170 HiPPO-Effekt 161 Initiative 55 Key Performance-Indikator 114 Komponenten-Team 163 Large Scale Scrum (LeSS) 173 Large Scale Scrum Huge (LeSS Huge) 176 Large Solution SAFe 189 Lead Time 124 Macro-Service 165 Magisches Dreieck 42 Metrik 113 Micro-Service 165 Mission 35 MoSCoW-Priorisierungsschema 65 Nexus 178 Nexus Guide 179 Portfolio SAFe 189 Product Backlog 54 Product-Backlog-Aufbau 59 Product-Backlog-Priorisierung 59 Product Backlog Refinement 71 Product-Backlog-Sortierung 62 Product Owner 26 Product Roadmap 45 Produktidee 37 Produktinkrement 67 Produktstrategie 38 Produktvision 37 Produktziel 16, 45 Program Board 188 Release Train Engineer 187 SAFe Essential 186 Scaled Agile Framework (SAFe) 185 Scrum Artefakte 35 Scrum Events 87 Scrum Master 24 Scrum Rollen 19 Servant Leader 24 Silo 161 Skalierungsframework 172 Spike 81 Spotify Modell 181 Sprint 87 Sprint Backlog 65 Sprint-Burndown-Diagramm 121 Sprint Performance 146 Sprint Planning 92 Sprint Retrospektive 104 Sprint Review 100 Sprint Status Chart 144 Sprintziel 16 Squad 182 Stacey Matrix 150 Stakeholder-Matrix 115 Story Point 79, 139 Task 55 Team-Building-Phasen 28 Team-Kapazität 138 Teufelsquadrat 42 Theme 55 Tigerteam 167 Tribe 182 Tribe Leader 182 T-Shaped Professional 22 User Story 55, 76 Velocity-Chart 117 Velocity-Chart mit Zielkorridor 118 Verzögerungskosten 65 Wertstrom 191 Work in Progress 99 Zielgruppen-Mapping 116 Zielorientierte Roadmap 47 Zwei-Pizzen-Teams 171 198 Register Abbildungsverzeichnis Abbildung 1: Säulen und Werte von Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Abbildung 2: Beziehungen innerhalb eines Teams . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Abbildung 3: Scrum Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Abbildung 4: Rollen in einem Scrum Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Abbildung 5: Performance - Teamgröße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Abbildung 6: T-Shaped Professionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Abbildung 7: Team-Building-Phasen nach Tuckman . . . . . . . . . . . . . . . . . . . . . . . . 29 Abbildung 8: Fünf Dysfunktionen von Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Abbildung 9: Zuordnung von Vereinbarungen zu Artefakten . . . . . . . . . . . . . . . . . 35 Abbildung 10: Mission und Produktvision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Abbildung 11: Produktstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Abbildung 12: Inhalte Produktstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Abbildung 13: Magisches Dreieck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Abbildung 14: Teufelsquadrat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Abbildung 15: Produktziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Abbildung 16: Einordnung der Product Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Abbildung 17: Feature Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Abbildung 18: Zielorientierte Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Abbildung 19: Produkttaktik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Abbildung 20: Überprüfungsintervalle von der Taktik bis zur Vision . . . . . . . . . . . 52 Abbildung 21: Schritte von der Produktidee zu den Sprintzielen . . . . . . . . . . . . . . . 53 Abbildung 22: Von den Sprintergebnissen zur Anpassung der Produktausrichtung 54 Abbildung 23: Beispiel einer Struktur-Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Abbildung 24: Zuordnung der Strukturelemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Abbildung 25: Backlog Strukturelemente mit zeitlichem Umfang . . . . . . . . . . . . . . 58 Abbildung 26: Abweichung von Plan- und Ist-Werten zwischen Strukturelementen 59 Abbildung 27: Planung mit höchstem Wert und Risiko zuerst . . . . . . . . . . . . . . . . . 61 Abbildung 28: Planung mit höchstem Business Value zuerst . . . . . . . . . . . . . . . . . . 62 Abbildung 29: Planung mit höchstem Risiko zuerst . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Abbildung 30: Planung mit höchster Komplexität zuerst . . . . . . . . . . . . . . . . . . . . . . 64 Abbildung 31: Priorisierung unter Berücksichtigung von Risiko und Business Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Abbildung 32: Sprint Backlog als Ergebnis des Sprint Plannings . . . . . . . . . . . . . . . 66 Abbildung 33: Potenziell auslieferbare Produktinkremente . . . . . . . . . . . . . . . . . . . . 68 Abbildung 34: Exemplarische Kriterien einer organisationsweiten Definition of Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Abbildung 35: Exemplarische Kriterien einer teamübergreifenden Definition of Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Abbildung 36: Exemplarische Kriterien einer teaminternen Definition of Done . . 70 Abbildung 37: Exemplarische Kriterien einer Definition of Done für ein Produktinkrement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Abbildung 38: Epics, Features und User Stories im Product Backlog . . . . . . . . . . . . 73 Abbildung 39: Backlog Refinement mit dreistufigem Detaillierungsprozess . . . . . . 74 Abbildung 40: User Stories und Tasks im Sprint Backlog . . . . . . . . . . . . . . . . . . . . . 76 Abbildung 41: Typische Vorlage für User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Abbildung 42: Regulärer Sprint versus Spike . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Abbildung 43: Beispiel Business Value Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Abbildung 44: Fünf Herausforderungen der inkrementellen Produktentwicklung 88 Abbildung 45: CI/ CD-Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Abbildung 46: Beispielhafte Agenda eines Sprint Reviews . . . . . . . . . . . . . . . . . . . . 103 Abbildung 47: 5-Phasen-Schema einer Sprint Retrospektive . . . . . . . . . . . . . . . . . . . 105 Abbildung 48: Daten sammeln während der Sprint Retrospektive . . . . . . . . . . . . . . 106 Abbildung 49: Stakeholder Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Abbildung 50: Zielgruppen Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Abbildung 51: Velocity Chart mit Anzahl User Stories . . . . . . . . . . . . . . . . . . . . . . . . 118 Abbildung 52: Velocity Chart mit Zielkorridor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Abbildung 53: Cumulative Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Abbildung 54: Burnup Chart mit User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Abbildung 55: Burndown Chart auf Basis von Aufwand und Kapazität . . . . . . . . . 123 Abbildung 56: Burnup Chart / Projektion Abschlusszeit . . . . . . . . . . . . . . . . . . . . . . 124 Abbildung 57: Lead Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Abbildung 58: Einfaches Lead / Cycle Time Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Abbildung 59: Cycle Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Abbildung 60: GQM Abstraction Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Abbildung 61: Burnup Chart zur richtigen Skalierung der Backlog-Elemente . . . . 135 Abbildung 62: Detailliertes Backlog Status Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Abbildung 63: Einfaches Backlog Status Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Abbildung 64: Story Points und Aufwand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Abbildung 65: Einfaches Kapazitätsstatus-Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Abbildung 66: Detaillierter Kapazitätsstatus auf Komponenten-Basis . . . . . . . . . . . 143 Abbildung 67: Einfaches Sprint Status Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Abbildung 68: Cycle Time je Story Point-Gruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Abbildung 69: Einfacher Chart zur Sprint Performance . . . . . . . . . . . . . . . . . . . . . . . 147 Abbildung 70: Detaillierter Chart zur Sprint Performance . . . . . . . . . . . . . . . . . . . . 148 Abbildung 71: Beispiel von Phasen unterschiedlicher Herausforderungen . . . . . . . 149 Abbildung 72: Stacey Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Abbildung 73: Auswahl agiler Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Abbildung 74: Chart Cycle Time je Risikolevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Abbildung 75: Bewertung Cycle Time/ Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 200 Abbildungsverzeichnis Abbildung 76: Verkürzung der Produktentwicklungszeit durch den Einsatz mehrerer Scrum Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Abbildung 77: Feature Teams versus Komponenten-Teams . . . . . . . . . . . . . . . . . . . 164 Abbildung 78: Micro-Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Abbildung 79: Macro-Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Abbildung 80: Hybrid aus Micro- und Macro-Services . . . . . . . . . . . . . . . . . . . . . . . 165 Abbildung 81: Skalierung von Micro- und Macro-Services . . . . . . . . . . . . . . . . . . . . 166 Abbildung 82: Übergang von Tigerteams zu Feature Teams . . . . . . . . . . . . . . . . . . . 167 Abbildung 83: CoP-Lebensphasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Abbildung 84: Impediment-Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Abbildung 85: Ausgewählte Skalierungsframeworks . . . . . . . . . . . . . . . . . . . . . . . . . 173 Abbildung 86: LeSS Rollen, Artefakte und Ereignisse . . . . . . . . . . . . . . . . . . . . . . . . 174 Abbildung 87: LeSS Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Abbildung 88: LeSS Huge Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Abbildung 89: Nexus Rollen, Artefakte und Ereignisse . . . . . . . . . . . . . . . . . . . . . . . 178 Abbildung 90: Nexus Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Abbildung 91: Spotify-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Abbildung 92: Alliances im Spotify-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Abbildung 93: Ausbaustufen bei SAFe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Abbildung 94: SAFe Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Abbildung 95: Agile Release Train . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Abbildung 96: SAFe Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Abbildung 97: Anwendungsbereiche der Skalierungsframeworks . . . . . . . . . . . . . . 192 201 Abbildungsverzeichnis EIN BAND AUS DER GPM-REIHE PROJEKTMANAGEMENT NEU DENKEN GPM TREND Layout Layout ISBN 978-3-7398-3117-6 Dipl. Inf. Jörg Brüggenkamp ist geschäftsführender Gesellschafter der PMC - ProjektManagement- und Controlling GmbH in der Schweiz. Prof. Dr. Peter Preuss lehrt Wirtschaftsinformatik an der FOM Hochschule für Oekonomie & Management in Stuttgart. Er ist zertifizierter Project Management Professional (PMP) nach PMI und Professional Scrum Master. Dr. Tobias Renk ist Global Service Owner für den Bereich B2C Pricing der BP Europa SE. Er ist als Experte und Keynote Speaker zu den Themen Innovation, kultureller Wandel und digitale Transformation unterwegs. Agile Projektmanagement-Methoden, die vor allem in Startups zu finden sind, werden im Zuge der digitalen Transformation auch für größere Organisationen immer interessanter und wichtiger. In diesem Buch wird untersucht, welche konkreten Herausforderungen es bei der Einführung der Projektmanagement-Methode Scrum gibt und wie man diese bewältigen kann. Folgende Fragen werden mit dem Buch beantwortet: Was genau ist bei der Einführung der Scrum-Prozesse zu beachten? Wie ist das Scrum-Rollenverständnis und wie etabliert man diese Rollen in bestehenden Organisationen? Wie erreicht man, dass die Scrum- Events erfolgreich durchgeführt werden? Welche Metriken eignen sich besonders gut, um den Fortschritt agiler Projekte zu messen? Wie können Projektrisiken minimiert und Probleme frühzeitig erkannt werden? Welche Skalierungsframeworks gibt es, um Scrum auch für größere Projektteams und Organisationen nutzen zu können? Brüggenkamp, Preuss, Renk Der Scrum-Reiseführer Jörg Brüggenkamp, Peter Preuss, Tobias Renk Der Scrum- Reiseführer Herausforderungen in der Praxis meistern