Читать книгу: «Der Scrum-Reiseführer»

Name: Der Scrum-Reiseführer
ISBN: 9783739801421

Tobias Renk, Jörg Brüggenkamp, Peter Preuss

Шрифт:

Jörg Brüggenkamp / Peter Preuss / Tobias Renk

Der Scrum-Reiseführer

Herausforderungen in der Praxis meistern

Umschlagmotiv: © iStockphoto pixdeluxe

– 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 Urheberrechtsgesetztes 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

ISSN 2748-4629

ISBN 978-3-7398-3117-6 (Print)

ISBN 978-3-7398-0142-1 (ePub)

Inhalt

1 Geleitworte1.1 Hanna Hennig (Siemens AG)1.2 Dr. Silvia Rummel (Festo SE & Co. KG)

2 Prolog – Agilität als Kernkompetenz für moderne Unternehmen

3 Scrum Framework – Eine kurze Einführung 3.1 Das Fundament 3.2 Scrum Rollen 3.3 Scrum Artefakte 3.4 Scrum Events

4 Scrum Rollen – Die Idealbesetzung eines Scrum Teams 4.1 Passende Rollenbesetzung als Erfolgsschlüssel 4.2 Entwickler als T-Shaped Professionals 4.3 Scrum Master als Servant Leader 4.4 Product Owner als Wertmaximierer 4.5 Führung und Teambildung in agilen Teams

5 Scrum Artefakte – Die Übersicht behalten5.1 Von der Vision zum Product Backlog5.1.1 Von der Produktidee zur Produktvision5.1.2 Von der Produktvision zur Produktstrategie5.1.3 Von der Produktstrategie zu den Produktzielen5.1.4 Von den Produktzielen zu den Sprintzielen und zurück zur Vision5.2 Product Backlog Grundlagen5.3 Aufbau, Priorisierung und Sortierung des Product Backlogs5.4 Sprint Backlog –ToDo-Liste für den laufenden Sprint5.5 Produktinkrement – Herausforderung in der Umsetzung5.6 Das Product Backlog und die Backlog Refinement-Aktivitäten5.6.1 Die drei Stufen der Detailierung5.6.2 User Stories, Tasks und deren Schätzung5.6.3 Das Orakel und die Story Points5.6.4 Die Analyse als Allheilmittel vor der Planung5.6.5 Business Value im Backlog Refinement5.6.6 Das Business Value-Trilemma

6 Scrum Events – Effektive und effiziente Scrum Meetings 6.1 Inkrementelle Produktentwicklung in Sprints 6.2 Sprint Planning – Was wird wie im Sprint gemacht? 6.3 Daily Scrum – Synchronisation des Entwicklerteams 6.4 Sprint Review als zentrale Feedbackschleife 6.5 Kontinuierlich besser werden mit der Sprint Retrospektive

7 Status-Reporting und Metriken – Risiken und Probleme managen7.1 Zielgruppen und Informationsbedarf7.1.1 Grundlagen zu Kennzahlen im agilen Umfeld7.1.2 Metriken und Zielgruppen7.1.3 Zielgruppenbestimmung7.2 Kennzahlen im agilen Umfeld verstehen und festlegen7.2.1 Standard Metriken7.2.2 Ermittlung von Metriken7.3 Metriken als Präventionsmaßnahme gegen Fehlentwicklungen7.3.1 Backlog-Gesundheit7.3.2 Kapazität und Auslastung7.3.3 Fortschrittsstatus7.3.4 Sprint Performance7.4 Herausforderungen, Widerstände und Lösungsansätze7.4.1 Herausforderung „agile Methoden“7.4.2 Herausforderung „Team“ und „Werkzeuge“7.4.3 Herausforderung „Ausrichtung/Skalierung“ und „Führung“7.4.4 Herausforderung „Produktnutzen“ und „Produktfinanzierung“7.4.5 Herausforderung „Reorganisation“

8 Agile Skalierung – Auf dem Weg zur lernenden Organisation 8.1 Wenn mehr als ein agiles Team benötigt wird 8.2 Beispiel: Autonome Zwei-Pizzen-Teams bei Amazon 8.3 Welchen Zweck erfüllen Skalierungsframeworks? 8.4 Scrum skalieren mit LeSS und LeSS Huge 8.5 Scrum skalieren mit Nexus 8.6 Neuaufstellung der Organisation mit dem Spotify-Ansatz 8.7 Agile Skalierung für große Organisationen mit SAFe 8.8 Wahl des richtigen Skalierungsframeworks

9 Epilog von Dr. Christopher Jud (Kaufland Digital)

Register

1 Geleitworte
1.1 Hanna Hennig (Siemens AG)

Unsere VUCA-Welt verlangt Unternehmen einiges ab: Sie sollen mit zunehmend komplexen 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 Projektmanagement 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 atemberaubendem 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 Konsumentenverhaltens 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 Projektmanagement-Methoden hier schnell an ihre Grenzen. Um dennoch den vorgegebenen Zielkorridor (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 Projektleiter in Organisationen, welche sich dem Thema digitale Transformation bereits angenommen haben oder sich gerade auf dem Weg dahin befinden, einen Praxisleitfaden 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ändlichkeit 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-Methoden 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

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änden – 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 Ambiguity (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 konkretes 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 entwickeln 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.

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 ProzesssteuerungEmpirische 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 identifiziert und angegangen werden. Die empirische Prozessteuerung spiegelt sich in drei Säulen, auf denen Scrum basiert, wider: Transparenz, Überprüfung und Anpassung.

Abbildung 1:

Säulen und Werte von Scrum

Scrum wurde ursprünglich für das Softwareumfeld entwickelt. Mittlerweile bewegt sich dieses Vorgehensmodell jedoch nicht mehr nur in seinem originären Bereich, sondern kann allgemein im Bereich Produktentwicklung eingesetzt werden. Dem Entwicklungsprozess 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 zentrale Elemente. Sämtliche Prozessschritte sind dann für alle Beteiligten ersichtlich. Das sind Grundvoraussetzungen, 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 Vordergrund rückt, ist die Dauer bis zu einer Prüfung. Diese ist deutlich kürzer als bei traditionellen 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 verpflichten sich gemeinsam, die Ziele zu erreichen und schaffen dadurch eine kollektive Selbstverpflichtung. Durch Mut sollen komplexe Aufgabenstellungen mithilfe kreativer 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. Dieser 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.

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 Verantwortungen (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 Produktinkrement 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.

Das Scrum Team ist selbstverwaltend (self managing) und nicht mehr selbstorganisierend (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 Produktinkrement. 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-Anforderungen 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 ProduktzielProduktziel (Product Goal) als zusätzliche Begrifflichkeit 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 (CommitmentCommitment) zuzuweisen: Das Produktziel gehört zum Product Backlog, das SprintzielSprintziel zum Sprint Backlog und die Definition of Done zum Produktinkrement. Diese drei Commitments sollen die Transparenz erhöhen und den Entwicklungsfortschritt 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 DoneDefinition 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 ein- bis 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?

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 genutzt, 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 werden 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 Fragestellungen: 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.

Abbildung 3:

Scrum Framework

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 Herausforderungen 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 RollenScrum 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).

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 umgesetzt 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 Arbeitsmethoden 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 Zusammenarbeit 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 Scrum Team könnte aus einem Product Owner, einem Scrum Master und Entwicklern bestehen, die folgende Fähigkeiten bereithalten: UX/UI-Design, Frontend- und Backendentwickler, 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 produktiver 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).

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 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 Produktes 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 Entscheidungen 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 Vorgehensmodell 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. Crossfunktional 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 ProfessionalsT-Shaped Professional (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.

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 Erledigung 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 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 MastersScrum Master 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 LeaderServant 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 strukturierte 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.

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. 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 OwnersProduct Owner ist – im Vergleich zu den beiden anderen Rollen – innerhalb eines Scrum Teams diejenige, die durchaus unterschätzt wird. Außerdem stehen Fachbereiche vor personellen Herausforderungen, wenn sie einen ihrer Fachexperten für eine andere Tätigkeit abstellen müssen. Folgende zwei Kernaspekte entwickeln sich aus diesen Reibungspunkten:

1 Der Product Owner ist eine Rolle innerhalb der Organisation, die gegebenenfalls neu geschaffen werden muss! Optimal ist es, wenn sich der Product Owner vollständig auf die Tätigkeiten im Scrum Team fokussieren kann und keine zusätzlichen, anderweitigen Aufgaben erhält.
2 Der Product Owner ist eine (!) Person, keine Gruppe oder Komitee. Gleichzeitig kann er die Interessen mehrerer Personen vertreten. Die finale, produktbezogene Entscheidung obliegt jedoch immer dem Product Owner.

Welche Entscheidungen sind gemeint und was sind nun die konkreten Aufgaben eines Product Owners? Der Grundgedanke ist einfach: Der Product Owner trägt die Verantwortung dafür, den Wert zu maximieren, den das Produkt für das Unternehmen erzeugt. So generisch dies klingen mag, so vielfältig sind auch die Methoden, die ein Product Owner dabei anwenden kann.

Ein effektives Management des Product Backlogs bildet dabei das Herzstück, um den maximalen Wert aus dem Produkt zu kitzeln. Dazu gehören insbesondere das Herausarbeiten und Kommunizieren eines Produktziels. Hier kann es zu den ersten Differenzen kommen, die den Erfolg des Scrum Teams negativ beeinflussen. Das Team möchte schnelle sichtbare Ergebnisse erzielen. Das kann dazu führen, dass der strategische Part stiefmütterlich behandelt und aus den Augen verloren wird. Hier ist also besondere Aufmerksamkeit erforderlich: Stellen Sie im Laufe Ihres Projektes eine ungewünschte Veränderung der Ergebnisse fest, werfen Sie doch nochmal einen Blick auf die Ausarbeitungen und die Kommunikation des Produktziels. Nehmen Sie sich dafür Zeit, sie wird sich rentieren! User Stories zu erzeugen und zu kommunizieren ist ein weiterer Aufgabenbereich des Product Owners. Er bringt diese in eine sinnvolle Reihenfolge, was in der Praxis eine Herausforderung sein kann. Besonders in diesem Teilschritt treten veraltete, hierarchisch geprägte Denkweise ans Tageslicht, die dem agilen Grundgedanken widersprechen. Nehmen wir zur Illustration ein beispielhaftes Projekt, das sich mit dem Erstellen von Berichten beschäftigt. Es liegt nahe, zunächst einmal User Stories anzulegen, die sich lediglich mit dem Sammeln und Anbinden von Datenquellen beschäftigen, um dann, in einem zweiten Schritt, mit der Erstellung der Berichte zu beginnen. Das jedoch ist genau die traditionelle Wasserfall-Denkweise, die ein sequenzielles und kein inkrementelles Vorgehen vorsieht. Geht ein Product Owner so vor, würde er der Maxime Wertgenerierung entgegenarbeiten. Denn eines ist klar: Wert wird erst dann geschaffen, wenn mindestens ein Bericht von der Fachabteilung im operativen Betrieb genutzt werden kann. Deshalb wäre es ein – im Sinne eines Product Owners – geschickteres Vorgehen, zunächst einen wichtigen, wertgenerierenden Bericht auf Basis weniger Datenquellen zu erzeugen, um anschließend darauf aufbauend die Daten- und Berichtslandschaft zu erweitern Eine weitere, grundlegende Funktion des Product Owners ist, ein für alle Teammitglieder nachvollziehbares und transparentes Product Backlog sicherzustellen.

Diese Fülle an Aufgaben macht deutlich, weshalb die Rolle eines Product Owners nicht einfach mal so nebenbei erledigt werden kann. Ein Product Owner kann zusätzlich bei den oben beschriebenen Aufgaben von anderen unterstützt werden. Die Prämisse dafür ist, dass allen zu jeder Zeit bewusst ist, dass am Ende der Product Owner die Verantwortung für diese Tätigkeiten trägt.

Einen erfolgreichen Product Owner zeichnet aus, dass seine Entscheidungen innerhalb der Organisation respektiert und akzeptiert werden. Daher ist es notwendig, dass ein Product Owner ein Entscheidungsmandat erhält. Ist dies nicht gewährleistet, kann es zu Situationen kommen, in denen die Entscheidungen infrage gestellt werden, was die Produktivität des Scrum Teams negativ beeinflusst.

4.5 Führung und Teambildung in agilen Teams

Das Entstehen eines Spitzenteams durchläuft vorab verschiedene Phasen, genauso wie bei der Buchung eines langersehnten Traumurlaubs. Zunächst wird ein passender Zeitraum und das zur Verfügung stehende Budget festgelegt. Anschließend werden Urlaubsziele miteinander verglichen und das bestmögliche ausgesucht. Ein Hotelzimmer oder eine Pension wird reserviert. Reisen Sie per Flugzeug, kaufen Sie Flugtickets und je näher das Abreisedatum rückt, umso tiefer stecken Sie in den letzten Vorbereitungszügen. Die Wanderstiefel werden geputzt oder der Bikini noch einmal kritisch auf seinen Sitz beäugt. Der Nachbar ist bereits im Besitz des Hausschlüssels und hat sich freundlicherweise dazu bereit erklärt, zweimal die Woche die Pflanzen zu gießen. Das Taxi wird vorbestellt und auch der Mietwagen am Zielflughafen ist bereits organisiert. Jetzt kann der Urlaub richtig losgehen!

Ähnlich verhält es sich auch mit agilen Teams (beziehungsweise mit Teams im Allgemeinen, agil macht hier keinen Unterschied). Bringt man Personen aus unterschiedlichen Bereichen zusammen, um gemeinsam an einem Projekt zu arbeiten, durchläuft die Gruppe zwangsläufig gewisse Schritte, bevor sie zu einem Höchstleistungsteam wird. Der US-amerikanische Psychologe Bruce Tuckman hat die Dynamiken von Teams auf dem Weg hin zu Hochleistungsteams untersucht. Er entwickelte in den 1960er Jahren ein vierphasiges ModellTeam-Building-Phasen, welches er 1977 um eine weitere, fünfte Phase ergänzte. Die fünf von Tuckman festgelegten Phasen lauten Forming, Stroming, Norming, Performing und Adjourning (Mourning). Sie sind in Abbildung 7 dargestellt und werden nachfolgend näher erläutert.

In jeder Phase finden bestimmt Teambildungsentwicklungen statt. Die Phasen sind je nach Team unterschiedlich lang. Allgemeingültige Aussagen über die Entwicklungsdauer können also nicht getroffen werden und wären allenfalls unzuverlässig. Dabei spielt es keine Rolle, ob die Gruppe neu zusammengewürfelt wird oder ob eine bereits bestehende Gruppe mit nur einer weiteren Person ergänzt oder ausgetauscht wird. Der Phasenzyklus beginnt immer von vorne, allerdings nicht jedes Mal im gleichen Ausmaß. Bereits die Kenntnis dieser Phasen innerhalb eines Teams hilft, mit Schwierigkeiten konstruktiver umzugehen. Konflikte, Streitigkeiten und kontroverse Diskussion werden dann nicht mehr als ein Zerfall des Teams angesehen, sondern als etwas Normales und Notwendiges, als ein Teil der gemeinsamen Reise.

Abbildung 7:

Team-Building-Phasen nach Tuckman

Forming

Viele Teammitglieder sind in dieser Phase voller Vorfreude auf die neue Aufgabe. Gleichzeitig ist diese positive Aufregung gepaart mit Unsicherheit, da man sich und seinen Platz im Team noch nicht einschätzen kann. Es gibt viele unbeantwortete Fragen in Bezug auf das Miteinander und den Umgang untereinander. Verantwortlichkeiten und Prozesse sind noch nicht bekannt. Manchmal weiß das Team zu diesem Zeitpunkt noch nicht einmal, dass es bestimmte Prozesse überhaupt benötigt. Das Gebot der Stunde heißt Beobachten und Verstehen. Konflikte werden (noch) nicht offen angesprochen, da eine Unsicherheit darüber besteht, wie das Team mit Bedenken und Konfliktsituationen umgeht. Oft benötigt es ein paar couragierte Vorstöße einzelner, bevor auch andere Teammitglieder sich trauen, offen Kritik zu äußern.

Storming

Nach einiger Zeit wird den Teammitgliedern bewusst, dass nicht alle Erwartungen an das Team zu erfüllen sind; zumindest nicht, wenn sich nichts ändert. Einige Teammitglieder werden jetzt die Gunst der Stunde ergreifen und ihre Unzufriedenheit offen ansprechen. Andere werden sich eher in sich zurückziehen und Abstand vom Team nehmen. Gründe für Unzufriedenheit gibt es viele und sind von Team zu Team verschieden. Einige Teammitglieder können genervt darauf reagieren, dass ihre Arbeitsergebnisse und deren Fortschritt als Teil des Sprint Backlogs transparent gemacht werden. Sie erkennen darin nichts anderes als ein Kontrollinstrument des „Managements“. Einige werden mit dem Gesamtfortschritt unzufrieden sein und nicht selten nach Gründen außerhalb ihres Einflussbereichs suchen, um sich selbst vor anderen – aber auch vor sich selbst – abzusichern und rechtfertigen zu können. In solchen Situationen meinen Teammitglieder zu lernen, dass sie sich nicht auf andere im Team verlassen können. Vorwürfe werden laut und die Verantwortung wird von sich selbst weggestoßen. Themen werden vermehrt „in kleiner Runde“ diskutiert, womit unweigerlich Allianzen innerhalb des Teams gebildet werden. Dem entgegen wirkt, den Fokus der einzelnen Teammitglieder weg von den individuellen Leistungen hinzu einer intensiven Zusammenarbeit zu lenken. Erkennt jeder im Team an, dass die Kollegen besondere Vorzüge und individuelle Schwächen mitbringen, von denen das Team in seiner Gesamtheit profitiert, hilft dies allen, die Situation besser zu verstehen und damit konstruktiv umzugehen.

Norming

Durch viele Diskussionen und Konflikte lernen sich die Teammitglieder besser kennen. Sie erkennen und verstehen die Wertegerüste der anderen Teammitglieder und lernen, wie das Team über die formellen Rollen hinaus funktioniert. Die Teammitglieder bilden nur Taktiken aus, um die Zusammenarbeit zu stärken, Gemeinsamkeiten zu fördern und Stärke der einzelnen Teammitglieder besser zu integrieren. Ein überraschendes Ergebnis, das durchaus nachdenklich stimmen kann, wurde von Google im Rahmen des Projektes Aristotle veröffentlicht. Demnach kommt es bei einem Hochleistungsteam nicht darauf an, ob es sich an allgemein anerkannten guten Werten und Prinzipien orientiert, wie beispielsweise Teammitglieder ausreden lassen und ihnen nicht ins Wort fallen, sondern dass alle im Team die gleichen Werte und Prinzipien teilen! Von außen betrachtet ist es also für jemanden sehr schwer, auf Grund des Umgangs miteinander im Team direkt auf die Leistungsfähigkeit des Teams zu schließen. Ein Team, in dem sich die Mitglieder gegenseitig anschreien, kann durchaus Höchstleistungen erbringen, solange alle im Team diesen Umgang als den für das Team richtigen erachten.

Performing

Nach ausgetragenen Konflikten, die viel Kraft und Energie gekostet haben, steigt die Stimmung im Team. Die Teammitglieder beginnen, sich weniger mit sich selbst und den anderen zu beschäftigen, sondern konzentrieren sich mehr auf Inhalte. Das grundsätzliche Gerüst der Zusammenarbeit steht, der Fokus liegt jetzt darauf, wie gemeinsame Ziele nach und nach immer besser und schneller erreicht werden können. Das Team hat dazu Rituale etabliert, die ebenfalls dabei helfen, neu auftretende Konflikte lösungsorientiert anzugehen. Es entsteht ein „inner circle“, der es für Außenstehende schwer macht, Teil des Teams zu werden.

Adjourning

Wird das Teamgefüge nun substanziell verändert, zum Beispiel dadurch, dass das Team in kleinere Teams aufgeteilt wird oder dass neue Teammitglieder auf Schlüsselrollen hinzukommen, entstehen bei vielen Teammitgliedern Sorgen und Bedenken. Vor allem mögliche – und bis dato unbekannte – Veränderungen der eigenen Rolle sorgen für Unsicherheiten einzelner Teammitglieder.

Teambildung benötigt Zeit. Obwohl das von Tuckman definierte Phasenmodell bis heute nichts von seiner Gültigkeit verloren hat, ist der Druck auf Teams, in immer kürzeren Zyklen mehr Ergebnisse zu liefern, gestiegen. Haben Unternehmen heute also noch Zeit für Teambildung? Kann das Thema Teambildung beschleunigt werden? Ein Begriff, der in diesem Zusammenhang immer häufiger gebraucht wird, ist der des Empowerments. Führungskräfte geben dabei einen Teil ihrer Entscheidungshoheit auf und übertragen diesen auf ihre Mitarbeitenden. Dadurch, dass Teams bestimmte Entscheidungen innerhalb der Gruppe treffen dürfen, wird die Motivation gesteigert, was sich positiv auf die Lieferung von Ergebnissen auswirkt und gleichzeitig die Dauer des Teambildungsprozesses verkürzen kann. Dieser zuerst einfach anmutende Weg birgt jedoch Konfliktpotenzial. Mal abgesehen davon, dass viele Führungskräfte diesem Prinzip misstrauen, weil sie dadurch selbst weniger „mächtig“ sind und befürchten, Kontrolle zu verlieren, müssen Mitarbeitende erst lernen und wollen, Entscheidungen zu treffen. Um dies zu erreichen, sind zunächst noch weitere Schritte notwendig.

General Stanley McChrystal beschreibt in seinem Buch Team of Teams ein einfaches Konzept, das den Zusammenhang zwischen Komplexität und Anpassungsfähigkeit verdeutlicht. Diese zwei Aspekte sind es, die agile Entwicklungsmethoden wie Scrum so beliebt gemacht haben. Obwohl dem Buch ein militärischer Hintergrund zugrunde liegt, sind die Erkenntnisse durchaus auf Scrum Teams anwendbar. Komplexität wird in diesem Modell maßgeblich durch die Komponenten Geschwindigkeit, also die sich rasend schnell ändernden Umweltbedingungen, und gegenseitigen Abhängigkeiten derselben bestimmt. Um auf diese komplexen Probleme reagieren zu können, braucht es ein anpassungsfähiges Team. Dieses wird wiederum durch ein gemeinsames Bewusstsein innerhalb des Teams sowie durch Empowerment der Teammitglieder erreicht. Entscheidend ist dabei, dass eine gewisse Reihenfolge berücksichtigt wird. Zunächst sollte ein gemeinsames Bewusstsein geschaffen werden. Erst mit dieser einheitlichen Basis kann innerhalb eines Teams Empowerment stattfinden. McChrystal geht in seinem Buch sogar noch weiter, wenn er schreibt, dass Empowerment ohne ein gemeinsames Bewusstsein gefährlich sei. Er führt als Beispiel die Finanzkrise 2008 an, die zu einem großen Teil von jungen, unerfahrenen Bankern ins Rollen gebracht worden war, die zu viel Entscheidungsspielraum und zu wenig Anleitung bekommen hatten. Empowerment funktioniert demnach nicht, wenn innerhalb einer Organisation oder eines Teams die Verantwortung einfach „nach unten“ geschoben wird. Es ist sogar in hohem Maße gefährlich. Vielmehr müssen die Teammitglieder bereit und willens sein, Verantwortung zu übernehmen. L. David Marquet beschreibt diesbezüglich eine Episode in seinem Buch Turn the Ship Around!, in der sich Abteilungsleiter beim Executive Officer abmelden und fragen, ob es für sie noch etwas zu tun gäbe. Die Verantwortung für die Arbeiten der Abteilungsleiter bleibt damit laut Maquet beim Executive Officer. Vielmehr sollten Abteilungsleiter erklären, was sie bereits geschafft haben und was sie planen, als nächstes zu tun. Marquet bezeichnet das als „Leadership at all levels“ oder Intent-based Leadership, womit wir erneut beim Thema Selbstorganisation wären. Die beiden wichtigsten Zutaten, die den Kern des Konzepts von McChrystal bilden, fehlen jedoch noch. Diese sind ein gemeinsames, sinnhaftes Ziel und Vertrauen. Nur wenn alle Teammitglieder das gemeinsame Ziel kennen und teilen und den Sinn darin verstehen, können sie die einzelnen Stärken zielgerichtet einbringen und auf Aktionen anderer entsprechend reagieren. Dies erfordert ein gewisses Maß an Vertrauen innerhalb des Teams.

Wie wichtig Vertrauen unter Teammitgliedern ist, um Höchstleistungen erzielen zu können, ist auch daran erkennbar, dass Vertrauen die grundlegende Funktion im Modell von Patrick Lencioni ist. Es beschreibt fünf Funktionen und Dysfunktionen von TeamsDysfunktionen von Teams, die in Abbildung 8 dargestellt sind. Dieses Modell dient der Standortanalyse im Rahmen von Teamentwicklungsprozessen. Dabei gilt es Funktionen sicherzustellen und Dysfunktionen zu beenden, denn in dem Maße, wie sich Funktionen positiv auf die Leistungsfähigkeit von Teams auswirken, können Dysfunktionen den nachteiligen Effekt haben.

Abbildung 8:

Fünf Dysfunktionen von Teams

Vertrauen

Amy Edmundson, Professorin für Leadership an der Harvard Business School, hat den Begriff „psychologische Sicherheit“ geprägt. Damit beschreibt sie ein Umfeld des Vertrauens, in dem sich Teammitglieder sicher fühlen. Ihre Forschung hat ergeben, dass in solchen Teams vermeintlich mehr Fehler gemacht werden als in Teams, in denen kein gegenseitiges Vertrauen vorherrscht. Das ist allerdings ein Trugschluss. In Wahrheit hat das Umfeld der psychologischen Sicherheit zu einem anderen Umgang mit Fehlern geführt. Diese wurden offener angesprochen und das Team hat als Ganzes daraus gelernt. Es entstand eine offene Fehlerkultur, die am Ende zu hochperformanten Teams führen kann. Im Gegensatz dazu werden in Teams, in denen diese Kultur fehlt, Fehler und Missstände eher verheimlicht und vertuscht, was sich am Ende nachteilig auf das gesamte Team auswirkt.

Konfliktbereitschaft

Konflikte sind per Definition nichts Schlechtes. Ganz im Gegenteil, sie sind notwendig, um Neues entstehen zu lassen und Innovation voranzutreiben. Dieses Bewusstsein zu schärfen, ist ein wichtiger Bestandteil von Hochleistungsteams.

Selbstverpflichtung

Selbstverpflichtung bedeutet, sich als Teammitglied zur gemeinsamen Sache zu bekennen. Es beinhaltet auch, Verantwortung für das Team und das gemeinsame Ziel zu übernehmen. In Hochleistungsteams halten sich Teammitglieder keine Hintertüren offen. Das gemeinsame Ziel ist wichtiger als individuelle Ziele. Es gilt demnach, den Gemeinschaftssinn zu stärken.

Gegenseitige Verantwortlichkeit

Darf man sich in die Angelegenheiten anderer Teammitglieder einmischen? Im Sinne des gemeinsamen Ziels ist dies sogar erwünscht, sollten Beiträge einzelner nicht zielführend sein. Das gemeinsame Lernen und Erreichen des Ziels stehen im Vordergrund. Natürlich entwickelt sich dadurch eine gewisse Gruppendynamik, die zunächst irritieren mag, vor allem, wenn man als einzelner nicht daran gewöhnt ist. Da sich Anforderungen in heutiger Zeit rasend schnell ändern können, ist es notwendig, mit diesen zu wachsen, und zwar zusammen, da die Komplexität vieler Anforderungen die Zusammenarbeit vieler benötigt.

Zielorientierung

Klare und eindeutige Zieldefinitionen vermeiden, dass Status und Ego einzelner zu sehr wuchern. Vermehrt hört man heutzutage, dass auf Grund von Agilität klare und eindeutige Zielformulierungen nicht möglich sind. Das ist schlichtweg nicht richtig. Natürlich ist es nicht einfach, aber ein wesentlicher Teil von Führung – und das beschränkt sich nicht auf einen rein agilen Kontext – bedeutet auch, dem Team Sinn und Orientierung in der Arbeit zu vermitteln. Das kann in der Praxis beispielsweise durch eine klare und offene Kommunikation geschehen, wobei natürlich inhaltlicher Kontext genauso wichtig ist.

5 Scrum Artefakte – Die Übersicht behalten

Die Scrum ArtefakteScrum Artefakte gibt es inzwischen seit 25 Jahren und sie haben bis heute nicht an Bedeutung verloren. Wie in Kapitel 3.3 beschrieben, werden im aktuellen Scrum Guide die Artefakte Product Backlog, Sprint Backlog und Produktinkrement unterschieden. Mit dem Scrum Guide 2020 gibt es nun eine klare Zuordnung von Vereinbarungen („Commitment“) zu diesen drei Artefakten (siehe Abbildung 9).

Abbildung 9:

Zuordnung von Vereinbarungen zu Artefakten

Das Produktziel (Product Goal) wird als neue Begrifflichkeit eingeführt. Mit diesem Ziel soll beschrieben werden, was der Sinn des zu erstellenden Produkts ist. Zudem wird sichergestellt, dass das Product Backlog nicht zu einem Sammelsurium beliebiger User Stories, Tasks und Defects verkommt. Nun steht also das Produktziel als Leitbild über dem Product Backlog und mit jedem Sprint soll das Produkt näher an dieses Produktziel herangebracht werden. Wie wird aber das Produktziel festgelegt? Lassen Sie uns dazu einen kurzen Abstecher in die Historie des Projektmanagements machen, in eine Welt voller Visionen und Ziele.

5.1 Von der Vision zum Product Backlog

Früher wurden Visionen, Strategien und Taktiken formuliert, um ein Projekt vollständig zu beschreiben. Übergeordnet war die MissionMission, mit der festgelegt wurde, worauf das ganze Handeln ausgerichtet ist. Eine Mission bezieht sich daher nicht auf ein einzelnes Projekt oder Produkt. Im Gegensatz dazu beschreibt die Produkt- beziehungsweise Projektvision ein in der Zukunft liegendes, relativ konkretes Bild dessen, was mit dem jeweiligen Produkt oder Projekt angestrebt wird. Hiermit sollen die Unternehmensmission und die Unternehmensvision realisiert werden. Abbildung 10 verdeutlich den Zusammenhang zwischen der übergeordneten Unternehmensmission und der Produktvision.

Abbildung 10:

Mission und Produktvision

In der Vergangenheit wurde bei der Anwendung agiler Methoden die Formulierung einer Produktvision oder einer Produktstrategie gelegentlich vernachlässigt, obwohl diese von entscheidender Bedeutung ist. Insbesondere bei Scrum liegt der Schwerpunkt auf der taktischen Planungsebene. Mit der Etablierung des Produktziels wird nun endlich der Planungshorizont erweitert. In der Theorie klingt das einfach. Im alltäglichen Projektleben ist es jedoch nicht so trivial, ein Produktziel zu formulieren und an alle gleichermaßen zu vermitteln, da die Stakeholder häufig unterschiedliche Vorstellungen davon haben, was mit dem Projekt erreicht werden soll. In der Welt der Entwickler ist das Produktziel eine Ansammlung funktionaler und nichtfunktionaler Anforderungen, die von ihnen umgesetzt werden müssen. Aus Kundensicht wird ein Produkt in der Regel mit dem Ziel entwickelt, den Bedarf einer bestimmten Zielgruppe zu befriedigen und letztlich den Unternehmensgewinn zu steigern. Erschwerend kommt hinzu, dass die Formulierung eines Produktziels an der Produktvision ausgerichtet werden muss. Starten wir daher mit einer kurzen Abhandlung zur Produktvision, Produktstrategie und Taktik. Hierbei gehen wir insbesondere darauf ein, wie diese Themen zusammenhängen. Eine tiefergehende Begriffsdiskussion erfolgt nicht.

5.1.1 Von der Produktidee zur Produktvision

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

Abbildung 11:

Produktstrategie

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 Anwenderherausforderung 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.

Abbildung 12:

Inhalte Produktstrategie

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 Regel 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 umgesetzt werden

Standard- bzw. Basisfunktion: Diese Anforderungen entsprechen dem Industriestandard 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).

Abbildung 13:

Magisches Dreieck

Als Erweiterung zum magischen DreieckMagisches Dreieck gibt es auch noch das TeufelsquadratTeufelsquadrat (siehe Abbildung 14). Bei diesem Quadrat wird die Leistungsdimension in die zwei Dimensionen Inhalt und Qualität aufgespalten. Werden alle Dimensionen des magischen Dreiecks oder des Teufelsquadrats (weitestgehend) erfüllt, spricht man von einem erfolgreichen Projekt.

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 notwendigen Erfahrungen einkauft werden, das Produkt in kürzester Zeit mit minimalem Funktionsumfang so einfach wie möglich umsetzen.

Abbildung 15:

Produktziele

Für der Produktentwicklung sollte also nicht ein einziges Produktziel verwendet werden, sondern mehrere. Im Scrum Guide steht, dass das ProduktzielProduktziel 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 Verkaufsauswertungen“ 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 erreichen 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 RoadmapProduct Roadmap erstellt werden. Der Begriff Roadmap lässt einen Wasserfall-Ansatz vermuten. Sie ist jedoch eine Strukturierungshilfe für die Produktziele. Für einen überschaubaren Zeithorizont wird der Weg zum nächsten Produktziel aufgezeigt.

Abbildung 16:

Einordnung der Product Roadmap

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 RoadmapFeature 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 Features werden nicht ausreichend berücksichtigt. In solchen Konstellationen hat sich die zielorientierte RoadmapZielorientierte 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.

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 Anforderungen 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 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 hinzuarbeiten, 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.

Abbildung 19:

Produkttaktik

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ängige Praxis ist auch, einen Grenzbereich (Beispiel: 15- bis 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?

Abbildung 20:

Überprüfungsintervalle von der Taktik bis zur Vision

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 Roadmap-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).

Abbildung 21:

Schritte von der Produktidee zu den Sprintzielen

In Abbildung 21 sind nochmal die wesentlichen Schritte auf dem Weg von der Produktidee zu den Sprintzielen zusammengefasst. Abbildung 22 zeigt die Rückkopplung, ausgehend von Sprintergebnissen bis hin zur Anpassung der Produktausrichtung.

Abbildung 22: