Scrum in der Praxis - Robert Wiechmann - E-Book

Scrum in der Praxis E-Book

Robert Wiechmann

0,0

Beschreibung

Know-how und Must-have für die Scrum-Praxis

  • eingeführtes Scrum-Standardwerk in Neuauflage
  • ein Buch aus der Praxis für die Praxis
  • mit vielen weiteren Praxistipps und einem neuen Kapitel zur Remote-Arbeit mit Scrum

Scrum ist die in Unternehmen am häufigsten verwendete agile Methode. Allerdings bietet Scrum zunächst lediglich ein Rahmenwerk, das durch eigene Ideen und Kreativität ausgefüllt und gestaltet werden muss. Um Scrum effizient anzuwenden, sind umfassende praktische Erfahrungen und ein grundlegendes Verständnis des agilen Wertesystems unabdingbar.
Hier hilft dieses Buch: Anhand zahlreicher Praxisbeispiele wird dargestellt, wie Scrum aufgesetzt und durchgeführt werden kann, welche typischen Herausforderungen dabei auftreten und wie diesen entgegnet werden kann. Vorgestellt werden Handlungsalternativen, die dabei helfen, ein Projekt zielgerichtet und schnell auf die Erfolgsspur zu bringen. Auf Basis eines beispielhaften Projekts werden die Schlüsselstellen und konkrete anwendbare Empfehlungen zur Ausgestaltung gegeben.
Die 3. Auflage enthält viele weitere Praxistipps und ein neues Kapitel zur Remote-Arbeit mit Scrum. Weiter werden die neuesten Anpassungen des Scrum Guide berücksichtigt.

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern
Kindle™-E-Readern
(für ausgewählte Pakete)

Seitenzahl: 600

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android
iOS
Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



Robert Wiechmann unterstützt seit 2008 mit Herzblut Organisationen bei ihrer agilen Transition. Seine Motivation als selbstständiger Berater und Coach ist es seit jeher, die Menschen von einer wert-, menschen- und kundenzentrierten Zusammenarbeit zu begeistern. Wertschätzung und Vertrauen bilden die Basis seiner Arbeit. Neben seiner beratenden und coachenden Tätigkeit ist er u. a. als Trainer und Moderator tätig. Als Autor und Mitbegründer der agilen Community »Agile by Nature« leistet er zudem seinen Beitrag, die Idee eines neuen Miteinanders in der Arbeitswelt zu verbreiten.

Sven Röpstorff ist Gesellschafter der kommitment GmbH & Co. KG in Hamburg, wo er als Agile Coach, Trainer und Interim Manager tätig ist. Sein Ziel ist die nachhaltige Entwicklung von Organisationen, wobei für ihn immer der Mensch im Mittelpunkt steht. Sven ist stets auf der Suche nach Verbesserungen und neuen Wegen, um Agilität einem immer größer werdenden Publikum auf interessante und spielerische Weise nahezubringen. Seiner Meinung nach kann man agile Vorgehensweisen am besten dadurch veranschaulichen, dass man sie für die Menschen sichtbar, fühlbar und erlebbar macht. Seine Erfahrungen aus vielen Jahren in unterschiedlichen Rollen und Projekten teilt er als Autor, Konferenzsprecher und Blogger und ist Mitbegründer der »Agile by Nature«-Community.

Copyright und Urheberrechte:

Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Robert Wiechmann · Sven Röpstorff

Scrum in der Praxis

Erfahrungen, Problemfelder und Erfolgsfaktoren

Mit einem Geleitwort von Ralf Kruse

3., aktualisierte und überarbeitete Auflage

Robert Wiechmann

[email protected]

Sven Röpstorff

[email protected]

www.scrum-in-der-praxis.de

Lektorat: Christa Preisendanz

Lektoratsassistenz: Julia Griebel

Copy-Editing: Ursula Zimpfer, Herrenberg

Illustrationen, Coverbild: Christian Pursch, www.teml-designs.de

Layout & Satz: Birgit Bäuerlein

Herstellung: Stefanie Weidner

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-86490-880-4

PDF

978-3-96910-800-0

ePub

978-3-96910-801-7

mobi

978-3-96910-802-4

3., aktualisierte und überarbeitete Auflage 2022

Copyright © 2022 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Stimmen zum Buch

Björn Jensen, Agile Coach

»Ich kann dieses Buch nur jedem empfehlen, der sich mit Scrum besonders in der Einführung näher beschäftigen möchte. Von Praktikern für Praktiker – großartig!«

Holger Koschek, Agile Coach

»Sie sind Scrum Master? Dieser Titel suggeriert Erfahrung, gepaart mit Wissbegierde, umfangreichen Kenntnissen und handwerklichem Geschick. Der Weg zum meisterlichen Umgang mit Scrum führt über das eigene Handeln und das Lernen. ›Scrum in der Praxis‹ animiert zu beidem: zum Lernen aus den niedergeschriebenen Erfahrungen zweier Scrum-Meister und zum Experimentieren mit den vorgestellten Werkzeugen und Praktiken.«

Michael Leber, Agile Coach

»Es gibt am Markt zahlreiche Bücher über Scrum, die viel über die Theorie, aber oft wenig über die Praxis zu berichten wissen. Das Buch von Sven und Robert geht hier einen anderen und erfrischenden Weg und wird damit seinem Titel voll gerecht – ein Buch für alle, die Scrum in der Praxis umsetzen wollen. Mit diesem Buch zeigen die Autoren, dass sie mit Scrum nicht auf der Marketingwelle surfen, sondern dass sie es aus ihrem eigenen Alltag wie ihre Westentasche kennen und Agile zu leben verstehen.«

Susanne Reppin, Agile Coach

»Dieses Buch ist ein professioneller Wegbereiter für alle, die mit Scrum unterwegs sind. Es ist spannend zu lesen, umfassend und es inspiriert selbst Erfahrene, Neues auszuprobieren. Es dient als erfrischendes Nachschlagewerk und bietet jede Menge praktischer Einblicke.«

Stefan Roock, Certified Scrum Trainer

»Das Buch vermittelt fortgeschrittene Methoden für den Scrum-Alltag. Als Besonderheit flechten die Autoren in die Beschreibung von Scrum immer wieder erzählerische Episoden ein, die plastisch darlegen, wie Scrum in der Praxis aussehen kann.«

Ralf Wirdemann, Software-entwickler und Agile Coach

»Endlich liegt mit ›Scrum in der Praxis‹ eine konsequente Fortsetzung des Scrum-Buchs von Roman Pichler vor. Robert und Sven ergänzen die gängige Scrum-Literatur um 300 Seiten geballtes Praxiswissen. Absolut lesenswert, auch für erfahrene Scrum-Experten.«

Henning Wolf, Certified Scrum Trainer

»Dieses Buch ist anschaulich, gut verständlich und voller Praxistipps. Es stellt eine prima Grundlage dar für die weitere Beschäftigung mit Scrum in der eigenen Praxis.«

Geleitwort

Seit über 10 Jahren helfe ich Organisationen dabei, ihre verschiedenen Herausforderungen durch mehr Agilität zu meistern. Meiner Erfahrung nach liegen die Hürden nicht im Verständnis – denn im Grunde ist Scrum recht einfach zu verstehen. Die Krux liegt in der konkreten Anwendung im jeweiligen Kontext.

Viele erhoffen sich, durch die Einführung von Scrum signifikant bessere Ergebnisse zu erhalten. Dabei wird oft vergessen, dass wir, wenn wir eine Chance auf signifikant bessere Ergebnisse haben wollen, auch eine signifikant andere Arbeitsweise benötigen. Die bestehende Arbeitsweise nur in einem neuen, angesagten Jargon umzuformulieren, bringt uns unserem Ziel, effektiver zu agieren, kein Stück näher. In der Regel schafft das nur noch mehr Probleme, da sich die alte und die neue Welt nun vermengen.

Die eigene Arbeitsweise komplett zu ändern, ist jedoch leichter gesagt als getan. Deshalb wäre es eine überschätzte Erwartung, dass mit der Einführung von Scrum sofort alles besser wird. Um Scrum sinnvoll und effektiv für die eigenen Zwecke nutzen zu können, ist es meiner Meinung nach wichtig, sich die typischen Fallstricke bewusst zu machen und zentraler Enabler zu sein. Nur so können »agile Absurditäten« vermieden werden.

Es gibt zahlreiche Gründe, warum die Umsetzung von Scrum in Unternehmen scheitert. In der Praxis konnte ich folgende Problematiken besonders häufig beobachten:

Alte Arbeitsweisen werden lediglich in Scrum umbenannt. Die Arbeit wird wie gewohnt, allerdings in einem unpassenden Rahmen, fortgesetzt.

Agilität wird als Ziel ausgerufen und lässt Scrum damit zum Selbstzweck verkommen.

Das direkte Umfeld wird als nicht agil »beschimpft«, anstatt sich mit Scrum richtig aufzustellen und zu versuchen, das Umfeld dafür zu gewinnen.

Teams sind es nicht gewohnt, gemeinsam Verantwortung zu übernehmen. Product Owner, Lead-Entwickler und/oder Scrum Master übernehmen fälschlicherweise die Aufgabe, das eigentlich selbstmanagende Team zu organisieren. Sie nehmen Scrum damit die Dynamik, die absolut notwendig ist, um zu besseren Ergebnissen zu kommen.

Anstatt alle Kompetenzen im Sprint zu bündeln und ein gemeinsames Lernen zu ermöglichen, erinnert die Vor- und Nachbereitung eines Sprints an ein klassisches Wasserfallprojekt mit einem Kringel in der Mitte. Das Hervorbringen von effektiven Ergebnissen in übergreifender Zusammenarbeit wird dadurch unmöglich.

Die Chance, im ersten Sprint zu lernen, wird oft nicht genutzt. Häufig fehlt der Mut, erste Ergebnisse ehrlich anzuerkennen. Mögliche Hindernisse werden ausgeblendet. Das Ergebnis ist das zu späte Erkennen von Problemen und ein Projektverlauf, der einen schmerzlich an den Bau des Berliner Flughafens erinnert.

Es beeindruckt mich immer wieder, wie sich die genannten Beispiele in der Praxis stets wiederholen. Dabei sind diese Herausforderungen häufig vermeidbar. Es wird leider nur allzu oft vergessen, dass Scrum in seinem Kern nicht ausschließlich dazu da ist, Ergebnisse zu liefern. Es gibt vielmehr den Rahmen, um aus Ergebnissen zu lernen – gemeinsam, als Team. Nicht umsonst sprechen wir in Scrum davon, im Scrum-Team alle notwendigen Kompetenzen zu bündeln, um aus leichtgewichtigen Ideen einsetzbare Lösungen zu entwickeln. Nur durch Reflexion können wir sukzessive unser Produkt und unsere Arbeitsweise ausgestalten. Scrum gibt uns dabei die Möglichkeit, transparent und schnell auf Veränderungen zu reagieren, indem wir unsere Arbeitsweise systematisch reflektieren und anpassen.

Worauf es in Scrum wirklich ankommt, lässt sich meiner Erfahrung nach an den folgenden Punkten festmachen:

Seid euch bewusst, warum ihr eine neue Arbeitsweise braucht. Nutzt dies als Motivation, um Scrum als minimalen Rahmen passend zu euren Bedürfnissen auszugestalten.

Helft allen Beteiligten durch Simulationen in einer sicheren Umgebung, ein Gefühl für das neue Arbeiten zu bekommen, und stellt heraus, worauf es im Kern bei Scrum ankommt.

Positioniert Scrum aktiv als Lernrahmen, indem ihr bewusst zügig in den ersten Sprint startet. Auch wenn dieser wahrscheinlich imperfekt sein wird, werden dennoch alle Beteiligten den Bedarf erkennen, das Produkt und die Arbeitsweise zu reflektieren und zu optimieren.

Gestaltet die Zusammenstellung des Scrum-Teams anhand des gewünschten Ergebnisses. Verschafft euch dafür eine Orientierung, welches Produkt ihr verwirklichen wollt.

Richtet euer Handeln als Scrum Master darauf aus, eine effektive Umgebung zu schaffen, um Ergebnisse zu liefern und gemeinsam zu lernen.

Es braucht keine abgefahrenen Modelle und Konzepte, um Scrum sinnvoll zu etablieren. Alles, worauf es meiner Meinung nach ankommt, ist die Bereitschaft, gemeinsam aus Ergebnissen lernen zu wollen und sich als Team zusammenzuraufen, um etwas Großes zu schaffen.

In meinen Trainings sowie in meinem Podcast »Scrum meistern« ist es mein Anspruch, mich inhaltlich nicht nur auf Scrum-Grundwissen zu beschränken. Mindestens genauso wichtig erscheint es mir, Fallstricke und »Agile Absurditäten« zu reflektieren und die Zuhörenden zu »enablen«, Scrum effektiv einzusetzen. Nutzen Sie das Buch mit all seinen spannenden Beispielen aus der Praxis als Inspiration und Grundlage, Scrum für Ihre Zwecke zu gestalten.

Ralf Kruseenablechange.deHamburg, Mai 2022

Vorwort

Wir freuen uns sehr, dass Sie dieses Buch in den Händen halten. Es handelt sich um einen praxisnahen Leitfaden, der Sie anhand von vielen praktischen Erfahrungen durch alle Stationen eines Scrum-Projekts führt. Sicherlich, es gibt eine Reihe guter Literatur zu Scrum, auf die wir in diesem Buch verweisen werden. Ursprünglich hat uns die steigende Anzahl von zertifizierten Scrum Mastern, Product Ownern und Entwicklern, die sich ihr Know-how mühsam in vielen Projekten erarbeiten müssen, zu diesem Buch bewegt.

Wir haben in diesem Buch unsere gemeinsame Erfahrung aus vielen Jahren als Scrum Master und Agile Coaches gesammelt. Wir möchten dieses Wissen mit Ihnen teilen und geben Ihnen für viele unterschiedliche Situationen in Scrum-Projekten praxisnahe Tipps und Methoden an die Hand.

Agilität oder genauer Scrum wird allzu oft als Allheilmittel und Garant für den Projekterfolg verstanden. Fast jeder Konferenzvortrag zu diesem Thema verweist auf die Vorteile, von denen am besten auch die eigene Firma profitieren sollte. Es wird aber häufig nicht das behandelt, was wirklich zählt, nämlich der Wandel, den man als Person und auch als Unternehmen vollziehen muss.

Ein Trugschluss, der sich hartnäckig hält, ist der, dass der Einsatz von agilen Methoden wie Scrum dazu führt, dass Produkte schneller entwickelt oder Projekte früher beendet werden. Das Ziel ist dabei aber gar nicht die schnellere Auslieferung, sondern der Wandel zum Wesentlichen – der ständige Prozess des Lernens, der kontinuierlichen Verbesserung, die Übergabe von Verantwortung und der laufende Austausch untereinander. Kürzere Entwicklungszeiten helfen dabei, Probleme frühzeitig aufzudecken. Das bessere Verständnis darüber, was im Wege steht und welche Dinge ein Scrum-Team erfolgreich machen, sind die Schlüsselkomponenten, die den Unterschied ausmachen. Dies kann jedoch nicht über Nacht erlangt werden, sondern ist mit schmerzlichen Erfahrungen und viel Herzblut aller Beteiligten verbunden.

Wer dieses Buch lesen sollte

Sie haben angefangen, erste Schritte mit Scrum zu machen und sind auf der Suche nach hilfreichen Tipps, mit denen Sie Ihre Herausforderungen gezielt angehen können? Auch Sie möchten vom Einsatz agiler Methoden wie Scrum profitieren und Ihre Organisation so aufstellen, dass sie für die Zukunft gewappnet ist? Sie haben sich bereits den Scrum Guide oder andere Fachliteratur zu Gemüte geführt, vermissen aber die Antworten auf Ihre praktischen Fragen? Gut, dann halten Sie mit diesem Buch Ihren zukünftigen treuen Wegbegleiter in der Hand. Dies ist keine Hochglanzbroschüre, die Scrum als Mittel beschreibt, um Ihre Wunden zu heilen. Mithilfe dieses Buches lernen Sie, Situationen frühzeitig einzuschätzen und gezielt darauf zu reagieren.

Als Scrum Master wird Ihnen das Buch ein guter Wegbegleiter für die Durchführung von Scrum-Projekten sein. Wenn Sie dieses Buch lesen, erhalten Sie wertvolle Einblicke in die Arbeitsweise mit Scrum.

In diesem Buch geht es um hilfreiche Tipps, Werkzeuge und Erfahrungswerte, die uns bei der Aufstellung schlagkräftiger Scrum-Teams geholfen haben. Diese Mittel sind in unsere tägliche Arbeit übergegangen.

Dieses Buch deckt nur einen kleinen Teil der Erfahrungen ab, die wir auf unserer Reise durch Unternehmen und Projekte gemacht haben. Wir hoffen jedoch, dass Sie damit einen ständigen Begleiter für Ihre Projekte gefunden haben und Ihnen die praktischen Tipps und unsere Erfahrungen helfen, Ihren eigenen Weg oder den Weg Ihrer Organisation aus agiler Sicht zu meistern.

Wem wir zu Dank verpflichtet sind

Ein Buch wie dieses entsteht nicht über Nacht und verlangt eine Reihe an Unterstützung, für die wir uns bei vielen Menschen ganz herzlich bedanken.

Unser spezieller Dank gilt dem dpunkt.verlag, der das Wagnis mit uns eingegangen und unseren Ideen und Vorstellungen gefolgt ist. Besonders danken wir Christa Preisendanz, die uns als Ansprechpartnerin und Lektorin immer für unsere Fragen mit Rat und Tat zur Seite stand.

Unserem Illustrator Christian Pursch sind wir sehr verbunden und dankbar für seine Mühe und Kreativität. Durch seine Hilfe hat diese Auflage einen neuen Anstrich erhalten. Alle Illustrationen wurden komplett überarbeitet und machen diese Neuauflage zu etwas ganz Besonderem.

Nicht weniger danken wir den vielen Menschen, die sich mit dem Manuskript kritisch auseinandergesetzt haben.

Zum Abschluss bedanken wir uns ganz herzlich bei unseren Familien für das Verständnis und die moralische Unterstützung während dieser erneut turbulenten Zeit.

Über Ihr Feedback, Ihre Anregungen oder praktischen Erfahrungen freuen wir uns via E-Mail an

[email protected].

Besuchen Sie die Internetseite zum Buch mit allen wichtigen Informationen, Arbeitsmaterialien, Illustrationen und Blogbeiträgen unter

scrum-in-der-praxis.de.

Wir freuen uns, wenn dieses Buch Sie stetig begleitet, und wünschen Ihnen viel Erfolg auf Ihrer persönlichen agilen Reise.

Hinweise zur dritten Auflage

Seit Erscheinen der ersten Auflage sind zehn Jahre vergangen. Wir haben in dieser Zeit sehr viel positives Feedback zu unserem Buch erhalten. Besonders hat es uns gefreut, wenn Menschen unsere Praxistipps ausprobiert haben und wesentliche Verbesserungen herbeiführen konnten.

Im vergangenen Jahrzehnt hat sich Scrum noch weiter verbreitet und weiterentwickelt. Das, was wir in den ersten beiden Auflagen verfasst hatten, wurde im Laufe der Zeit durch viele andere wiederholt, abgewandelt oder ergänzt. Daher war es nun an der Zeit, die Inhalte des Buches erneut auf den Prüfstand zu stellen. Sind die Beschreibungen noch zeitgemäß? Benutzen wir die dargestellten Techniken selbst noch oder stehen wir noch dazu?

Auch wir haben weitere Erfahrungen gesammelt, sind vielleicht in dem einen oder anderen Punkt nicht mehr ganz so streng mit unseren Scrum-Teams oder haben gelernt, dass wir in bestimmten Situationen noch konsequenter im Umgang mit der Organisation sein sollten, um nachhaltig Veränderungen anzustoßen und Wert zu schaffen.

All diese Überlegungen sind in diese komplett überarbeitete und aktualisierte Auflage eingeflossen. Wir haben viele Abschnitte verfeinert, Kapitel umgestaltet und hinzugefügt sowie eine Vielzahl an Praxistipps ergänzt und die aktuellen Änderungen aus dem Scrum Guide vom November 2020 (scrumguides.org) übernommen. Zur Abrundung haben wir alle Illustrationen im Buch erneuert. Wir hoffen damit, dass dieses Buch noch mehr dazu beiträgt, Ihren agilen Alltag zu gestalten und Scrum-Teams zum Erfolg zu führen.

Wichtig ist uns, dass Sie sich angesprochen fühlen. Wir haben uns beim Schreiben Mühe gegeben, geschlechtergerechte Formulierungen zu verwenden. Gleichzeitig haben wir uns gegen eine Verwendung des Gender:Doppelpunkts entschieden. Wir versuchen zu umschreiben, die Geschlechter zu variieren und nutzen die englischen Begriffe des Scrum Guide für die Verantwortlichkeiten.

Robert Wiechmann, Sven RöpstorffHamburg, Mai 2022

Inhaltsübersicht

1Einleitung

2Werte und Prinzipien

3Das Scrum-Team

4Die Arbeit im Scrum-Team

5Die Scrum-Events

6Remote Scrum

Anhang

ALiteraturverzeichnis

BGlossar

Index

Inhaltsverzeichnis

1Einleitung

2Werte und Prinzipien

2.1Agile Werte

2.2Agile Prinzipien

2.3Häufige Herausforderungen

3Das Scrum-Team

3.1Scrum-Team

3.1.1Verantwortlichkeiten

3.1.2Charakteristika

3.1.3Häufige Herausforderungen

3.2Entwickler

3.2.1Verantwortlichkeiten

3.2.2Charakteristika

3.2.3Häufige Herausforderungen

3.3Scrum Master

3.3.1Verantwortlichkeiten

3.3.2Charakteristika

3.3.3Häufige Herausforderungen

3.4Product Owner

3.4.1Verantwortlichkeiten

3.4.2Charakteristika

3.4.3Häufige Herausforderungen

4Die Arbeit im Scrum-Team

4.1Vor dem Start

4.1.1Kick-off

4.1.2Definition of Ready/Definition of Done

4.1.3Umgang mit Fehlern

4.1.4Letzte Vorkehrungen

4.1.5Häufige Herausforderungen

4.2Product Backlog

4.2.1Inhalt und Struktur

4.2.2Anforderungsworkshops

4.2.3User Stories

4.2.4User Story Mapping

4.2.5Zerlegung von User Stories

4.2.6Häufige Herausforderungen

4.3Schätzung von Komplexität

4.3.1Schätzungen

4.3.2Schätzeinheiten

4.3.3Initiale Schätzung

4.3.4Things-that-matter-Matrix

4.3.5Häufige Herausforderungen

4.4Backlog Refinement

4.4.1Ziele

4.4.2Ablauf

4.4.3Häufige Herausforderungen

4.5Releaseplanung

4.5.1Releaseplan

4.5.2Release-Burndown-Chart

4.5.3Release-Sprint

4.5.4Häufige Herausforderungen

5Die Scrum-Events

5.1Sprint Planning

5.1.1Ziele

5.1.2Ablauf

5.1.3Häufige Herausforderungen

5.2Daily Scrum

5.2.1Ziele

5.2.2Ablauf

5.2.3Häufige Herausforderungen

5.3Sprint-Review

5.3.1Ziele

5.3.2Ablauf

5.3.3Häufige Herausforderungen

5.4Sprint-Retrospektive

5.4.1Ziele

5.4.2Vorbereitung

5.4.3Ablauf

5.4.4Varianten

5.4.5Häufige Herausforderungen

6Remote Scrum

6.1Remote-Zusammenarbeit

6.1.1Remote-Moderation

6.1.2Remote-Ausstattung

6.1.3Häufige Herausforderungen

6.2Remote-Sprint

6.2.1Sprint Planning

6.2.2Daily Scrum

6.2.3Sprint-Review

6.2.4Sprint-Retrospektive

6.2.5Häufige Herausforderungen

6.3Remote-Verantwortlichkeiten

6.3.1Scrum Master

6.3.2Product Owner

6.3.3Entwickler

6.3.4Häufige Herausforderungen

Anhang

ALiteraturverzeichnis

BGlossar

Index

1Einleitung

Wie das Buch aufgebaut ist

Wir haben das Buch so konzipiert, dass Sie an jeder Stelle des Buches zielgerichtet nachschlagen und direkt ins Thema einsteigen können.

In Kapitel 2 reflektieren wir die agilen Werte und Prinzipien, die eine Basis für ein erfolgreiches Scrum-Projekt schaffen und die es zu verinnerlichen gilt.

In Kapitel 3 erläutern wir, wie wichtig jeder Mensch aus dem Scrum-Team für den Erfolg ist. Wir beschreiben die Verantwortlichkeiten des Entwicklers, des Scrum Masters und des Product Owners und geben wertvolle Hinweise, worauf Sie bei der Besetzung der Teammitglieder achten sollten.

In Kapitel 4 erfahren Sie, welche Aufgaben vor und während eines Scrum-Projekts anfallen. Beginnend mit dem Kick-off führen wir Sie über Schätzverfahren und der Pflege des Product Backlog bis hin zur Releaseplanung.

In Kapitel 5 starten wir einen Sprint-Zyklus und führen Sie durch einen Sprint. Wir beginnen mit dem Sprint Planning und enden mit der Sprint-Retrospektive. Auf dem Weg geben wir zahlreiche praktische Tipps und Hinweise für die Gestaltung der Scrum-Events und besonderer Situationen.

In Kapitel 6 widmen wir uns einem Schwerpunkt, der für viele Scrum-Teams mittlerweile zum Alltag gehört: die verteilte Arbeit über mehrere Standorte hinweg.

Wovon Sie profitieren

Wir haben uns bei der Gestaltung des Buches vor allem die Frage gestellt, wie wir übersichtlich und verständlich praktisches Wissen vermitteln und wertvolle Anregungen geben können. Ihnen stehen mit diesem Buch die folgenden Hilfsmittel zur Verfügung:

Scrum Guide

Wir orientieren uns inhaltlich am aktuellen Scrum Guide (

scrumguides.org

)

und stellen explizit heraus, wenn wir davon abweichen.

Terminologie

Wir verwenden bewusst die bekannten englischsprachigen Scrum-Begriffe, um nicht neue Wortschöpfungen zu erschaffen und damit unnützerweise zu verwirren.

Praxistipps

Sie finden eine Vielzahl hilfreicher Tipps aus der Praxis im Buch, die wir durch Hinweisboxen hervorgehoben haben.

Glossar

Dieses Buch verfügt über ein umfangreiches Glossar mit allen wichtigen Erläuterungen zu den verwendeten Fachtermini, das auch über die Website zum Buch zugänglich ist. Wir weisen mit einem Pfeil-Symbol () auf Glossareinträge hin.

Verfügbarkeit

Ihnen stehen neben diesem Buch viele Checklisten, Empfehlungen, Referenzen, Illustrationen sowie das Glossar unter

scrum-in-der-praxis.de

in digitaler Form zur Verfügung.

Wer Sie begleitet

Ihre ständige Begleitung wird das Team der SidP GmbH sein. Wir möchten mit der Geschichte des SidP-Teams die einzelnen Projektphasen noch lebhafter gestalten. Die Beispiele ziehen sich wie ein roter Faden durch das Buch und veranschaulichen somit die wichtigen Stationen und typische Herausforderungen in Scrum-Projekten. Nachfolgend stellen wir Ihnen die Scrum in der Praxis (SidP) GmbH sowie unsere Akteure kurz vor.

Die SidP GmbH

Die SidP GmbH wurde 2001 als Spin-off der Universität Hamburg gegründet. Sie besteht heute aus rund 70 Mitarbeitenden, vorwiegend Softwareentwicklerinnen, Scrum Master, IT-Berater, Webdesignerinnen und Softwarearchitekten.

Das Angebotsspektrum der SidP GmbH ist groß und erstreckt sich neben der Gestaltung von Desktop-Anwendungen über die Pflege von Internetportalen bis hin zum Themenschwerpunkt, den Applikationen für eine Vielzahl von mobilen Endgeräten. Vom Anforderungsmanagement über die agile Abwicklung von Projekten bis hin zum Servicemanagement deckt die SidP GmbH den gesamten Lebenszyklus einer Software ab. Seit ihrer Entstehung arbeitet die SidP GmbH mit einem breiten nationalen und internationalen Partnernetzwerk zusammen, das bei der Realisierung der Kundenwünsche unterstützt.

Die SidP GmbH entwickelt Software agil mit Scrum. Die Kundschaft profitiert seit 2005 von einer individuellen Vertragsgestaltung und Auslieferung in kurzen Intervallen. Mit einer weiteren Niederlassung in Mailand ist die SidP GmbH seit 2020 auch international vertreten. Dies verschafft den italienischen Kunden der SidP GmbH zusätzliches Expertenwissen und die persönliche Nähe vor Ort.

Das Scrum-Projekt

Die SidP GmbH hat gerade einen neuen Auftrag erhalten, der bis Ende des Jahres fertiggestellt werden soll. In Hamburg findet im dritten Jahr in Folge eine große Konferenz zum Thema »Agil mit Scrum« statt. Da die Konferenz weltweit einen ausgezeichneten Ruf hat, werden ca. 600 Gäste aus aller Welt in der Hansestadt erwartet. Aufgrund des Feedbacks des letzten Jahres soll es diesmal eine Applikation für mobile Endgeräte geben, mit der die Gäste das Konferenzprogramm, Raumpläne, Informationen zu den Sprecherinnen und vieles mehr abrufen können.

Das Scrum-Team

Herr Hold ist der Geschäftsführer der SidP GmbH und Organisator der Konferenz. Er kümmert sich um alles, was mit dem Event zu tun hat. Für unser Scrum-Team ist er der Auftraggeber des Projekts. Da der Konferenztermin feststeht, benötigt er die Anwendung zu einem fixen Zeitpunkt.

Casper hat bereits ein paar Jahre als Produktmanager gearbeitet. Er kennt sich gut im Markt aus und bezeichnet sich selbst als Power User seines Mobiltelefons. Casper hat bereits kleinere Projekte als Product Owner begleitet und freut sich auf diese neue Herausforderung.

Finn hat eine Ausbildung als traditioneller Projektmanager. Vor vier Jahren hat er von Scrum gehört und seinen Chef von der Idee überzeugen können, sich als Scrum Master zertifizieren zu lassen. Seitdem ist er von Scrum überzeugt und setzt alles daran, Scrum in der Organisation zu etablieren.

Alva hat viele Jahre als Webentwicklerin gearbeitet und ist mit dem Markteintritt des ersten iPhones auf mobile Plattformen umgeschwenkt. Sie behält immer das System als Ganzes im Auge und kümmert sich im Team um die Softwarearchitektur.

Jordi ist der Junior im Team. Bereits während des Studiums hat er seine Praktika in der Firma absolviert und hat direkt nach seinem Abschluss bei der SidP GmbH als Softwareentwickler angefangen. Er interessiert sich besonders für die Schnittstellenentwicklung.

Sergio ist ein alter Hase in der Softwareentwicklung. Von der prozeduralen Entwicklung mit PASCAL über die objektorientierte mit C++, Java und Ruby ist er jetzt bei mobilen Anwendungen angekommen.

Mina hat einige Zeit als Softwareentwicklerin gearbeitet, bevor sie ihre Begeisterung für Qualitätssicherung entdeckte. Durch die gesammelten Erfahrungen fällt es ihr leicht, andere von der Notwendigkeit des Testens zu überzeugen. Im Team achtet sie vorrangig auf die Qualität der Software.

Lara ist der kreative Kopf. Sie kümmert sich sowohl um das Design als auch um die Benutzerfreundlichkeit der Applikation. Sie sorgt dafür, dass die Funktionalitäten gut aussehen und einfach benutzt werden können.

2Werte und Prinzipien

Aller Anfang ist ein Anfang

Auch die SidP GmbH ist durch ein Tal der Tränen gegangen. Als Finn im Unternehmen als Scrum Master startete, hatte Herr Hold die Zügel in der Hand. Keiner kam am Geschäftsführer vorbei. Jede Entscheidung lief über seinen Tisch. Viele Gespräche, meist kontrovers zwischen Herrn Hold und Finn geführt, lösten anfänglich zu viel Spannungen aus. Finn war sich nicht sicher, ob er etwas erreichte, und Herr Hold war hin- und hergerissen zwischen dem Loslassen und alles entscheiden zu müssen.

Auf Basis dieser Gespräche erstellte Finn eine Liste von Dingen, die Herrn Hold, Finn und den Mitgliedern des Scrum-Teams wichtig waren. Mit dieser Liste hatte Finn etwas vor. Er brachte nämlich alle an einen Tisch und gemeinsam klärten sie, bei welchen Aspekten Herr Hold noch mitbestimmen wollte und bei welchen das Scrum-Team entscheiden durfte. Dieses Art und Weise über die Delegation von Aufgaben zu sprechen, war für alle Beteiligten sehr befreiend [URL:DelegationPoker]. Herrn Hold wurde bewusst, dass die Teammitglieder viel mehr entscheiden wollten, als er anfänglich glaubte. Den Teammitgliedern wurde deutlich, dass Herr Hold ihnen mehr Vertrauen schenkte, als sie annahmen.

Finn war zufrieden mit diesem Ergebnis, denn er wusste genau, dass die Ermächtigung des Teams ein Grundstein für den Erfolg des Projekts war. Und erfolgreich sein wollte er unbedingt, denn es war ja das erste Scrum-Projekt der Firma.

Heutzutage werden agile Methoden in einer immer größer werdenden Anzahl von Projekten eingesetzt. In einer aktuellen Umfrage aus dem Jahr 2021 wird deutlich, dass sich neben der reinen Softwareentwicklung immer mehr Teile einer Organisation oder ganze Unternehmen, agiler Denkweisen oder Methoden zuwenden [URL:Digitalai].

Mit dieser wachsenden Anzahl erhöhen sich auch die Herausforderungen, die an die Beteiligten gestellt werden. Denn die Anwendung von agilen Methoden ist, verglichen mit der Verinnerlichung der zugrunde liegenden Wertesysteme und Grundprinzipien, einfach. Dies führt in vielen Unternehmen zu der Situation, dass ein leichtgewichtiges Rahmenwerk wie Scrum eingesetzt wird, aber die nötige Grundeinstellung nicht stimmt: »Wir arbeiten agil, denn wir nutzen Scrum« – eine weitverbreitete Fehleinschätzung. In vielen Fällen kann die Mechanik von Scrum für Verbesserung sorgen. Diese sind jedoch nicht von Nachhaltigkeit geprägt, da sie oftmals in ein System gepresst werden, das mit der Zeit wieder die Oberhand gewinnt und keine Verhaltensänderung notwendig macht.

Wir haben uns in den letzten Jahren angewöhnt, nicht mehr das Wort »agil« zu verwenden, wenn es um die gemeinsame Zusammenarbeit geht. Für uns ist das Agile Manifest ein Selbstverständnis des gemeinsamen Miteinanders geworden, sodass wir eher über das Erleben den Begriff greifbar machen.

Der falsche Ansatz

Wenn wir uns heute, mehr als 20 Jahre nach Veröffentlichung des Agilen Manifests (agilemanifesto.org), in Unternehmen umsehen, dann erhalten wir ein durchwachsenes Bild. Die meisten Menschen haben zumindest von Scrum oder anderen agilen Methoden gehört.

Wenn wir uns genauer anschauen, wie der Erfolg von agilen Methoden zustande gekommen ist, dann sicherlich nicht durch radikale Veränderungen innerhalb von Organisationen. Vielmehr ist es häufig ein Versprechen gegenüber dem Management, schneller und vorhersehbarer zu entwickeln und mehr Wert bei weniger Entwicklungskosten und hohem Flexibilitätsgewinn zu liefern. Doch was hat sich in der gleichen Zeit auf Managementebene oder in den Organisationen getan? Nicht viel.

Es ist ein weitverbreitetes Missverständnis, dass sich Agilität vom Management verordnen lässt. Das Verwenden eines neuen Prozesses wird mit der Einführung von Agilität in Unternehmen gleichgesetzt, ohne die zugrunde liegenden agilen Werte auch nur ansatzweise zu betrachten. Die Frage nach der Anwendungspraxis agiler Werte ist immer auch eine Frage der Persönlichkeit, Seniorität und Unabhängigkeit des Scrum Masters bzw. Agile Coaches (vgl. Abschnitt 3.2). Eine Aufgabe des Scrum Masters ist es u.a., die bestmöglichen Rahmenbedingungen für ein Projekt zu schaffen. Dies kann nur mit der Unterstützung leitender Führungspersonen oder des Managements funktionieren. Denn gerade vom Management sind ein klares Bekenntnis und uneingeschränkte Unterstützung gefragt. Erfolgt dies nicht, entstehen unterschiedlichste Konflikte und die Umsetzung bleibt inkonsequent und lückenhaft.

Führungspersonen können in ihrem Verantwortungsbereich bereits eine Menge erreichen, indem sie die agilen Werte in ihr Verhalten integrieren und damit vorleben. Wenn solche Bemühungen in den höheren Ebenen aber nicht flächendeckend unterstützt werden, kann das Unternehmen insgesamt nicht optimal von Agilität profitieren.

Suchen Sie sich Verbündete im Management, die Ihnen helfen, den agilen Gedanken zu verbreiten. Gehen Sie unkonventionelle Wege und machen Sie z. B. eine Roadshow durch das Unternehmen, auf der Sie über neue Führungsmethoden wie beispielsweise »Theorie U« [Scharmer 2011] sprechen und dies mit den Vorteilen von Scrum gleichsetzen. Organisieren Sie interne Meetups, zu denen Sie externe Speaker einladen, die zu einem Schwerpunktthema vortragen. Gründen Sie eine Community of Practice zum Thema Agilität und vernetzen Sie die Personen, die sich bereits engagieren bzw. ein Interesse daran haben. Oder legen Sie Ihrer Vorgesetzten das Buch von Frédéric Laloux »Reinventing Organizations« [Laloux 2016] auf den Tisch und laden Sie zum gemeinsamen Diskurs ein.

Fast niemand macht wirklich Scrum

Es mag für Sie erst einmal überraschend sein, das zu lesen. Fakt ist aber, die Leichtgewichtigkeit von Scrum endet oftmals dort, wo Organisationen ihre Probleme unter den Tisch kehren und alte Muster und Verhaltensweisen Einzelner mehr Wichtigkeit beigemessen wird als der Wertschöpfung für Kunden. In den vielen Jahren, die wir Scrum-Teams begleiten, treffen wir selten auf funktionierende Scrum-Teams oder eine wertstiftende Anwendung von Scrum. Schon allein die Frage, ob jemand aus einem Scrum-Team den Scrum Guide (scrumguides.org) gelesen hat, führt in den meisten Fällen zu kollektivem Achselzucken.

Stellen Sie in einer Ihrer nächsten Retrospektiven doch einmal Scrum als Rahmenwerk in den Mittelpunkt. Sprechen Sie mit den Teammitgliedern darüber, wozu das Rahmenwerk existiert, und finden Sie kollektiv heraus, dass komplexe Produktentwicklung ein iteratives Vorgehen braucht, das durch die Fertigstellung von Produktinkrementen überprüft, ob getroffene Annahmen richtig sind und somit an den richtigen Dingen gearbeitet wird, um für Kunden einen größtmöglichen Wert zu liefern.

Die mechanische Verwendung von Scrum bringt dann vorerst einige Verbesserungen, unterliegt dann aber oftmals dem System, also dem, was in einer Organisation vorherrschend gelebt und praktiziert wird. Für uns wird dies dann an folgenden wiederkehrenden Anzeichen sichtbar:

Fehlende Veränderung

Viele Organisationen messen der notwendigen kulturellen Veränderung nur einen geringen Stellenwert bei, sodass im laufenden hektischen beruflichen Alltag nachhaltige Veränderungen unter den Tisch fallen [

URL:Wiechmann a

]. In vielen Fällen ergibt sich dann ein Kreislauf, der daraus besteht, sich gegenseitig Vorhaltungen zu machen, wer jetzt nicht mitzieht oder was nicht getan wird oder wurde.

Dominante Stakeholder

Stakeholder dominieren oftmals das Geschehen, indem ein enormer Druck auf Scrum-Teams aufgebaut wird. Daraufhin entsteht in vielen Fällen ein Abarbeiten von Roadmaps anstelle eines Nachdenkens über das, was erreicht werden soll und für den Kunden Wertschöpfung liefert.

Funktionsgetrieben (Feature-Driven)

Scrum-Teams gelangen so in vielen Fällen schnell in einen Strudel, der sie nicht mehr Probleme für die Kunden lösen lässt, sondern nur den Blick auf die nächste Funktion (engl. Feature) zulässt. In vielen Fällen sind Product Owner damit beschäftigt, Anforderungen aufzunehmen, anstatt Probleme der Kunden zu identifizieren und wertstiftend im Sinne des Produktziels zu agieren.

Ungeklärte Probleme

Scrum ist unermüdlich beim Aufspüren von Dysfunktionen einer Organisation. Häufig wird über aufgedeckte Missstände jedoch hinweggegangen oder diese nicht in Angriff genommen. Manchmal fehlt die Zeit, weil wieder ein wichtiges Release vor der Tür steht, manchmal weil die Unterstützung einer leitenden Funktion fehlt oder ein Scrum-Team nicht die Verantwortung für die eigenen Verbesserungen übernimmt.

Fehlende Autonomie

Viele Scrum-Teams unterliegen den vorherrschenden Gesetzmäßigkeiten des Systems, in dem sie arbeiten – egal ob in einer Matrixorganisation unter vielen Hierarchieebenen eingebettet, abhängig von einem stark kontrollierenden Firmenchef oder in der Rolle des Dienstleisters anstatt Partners auf Augenhöhe, für einen externen Auftraggeber oder eine interne Abteilung.

Alles zur gleichen Zeit

Mit der Entscheidung, Scrum zu nutzen, beginnen viele gleichzeitig, Praktiken wie z.B. User Stories (

Abschnitt 4.3.2

), Story Mapping (

Abschnitt 4.2.4

) oder Personas einzuführen. Oftmals wird es dann als Teil von Scrum verstanden, obwohl diese nichts mit Scrum zu tun haben. Die Menge dessen, was dann zur selben Zeit verändert wird, führt zu Überforderung oder Ablenkung vom Wesentlichen.

»Scrum, but

«

»Wir machen Scrum, aber

…«

ist ein häufig verwendeter Satzbeginn. Diesem folgen dann viele Gründe, die herausstellen sollen, warum Scrum »by the book« nicht funktioniert. Wir hören dann: »Wir nutzen Scrum, aber …

… ein tägliches Daily Scrum ist zu viel Aufwand.

… die Sprint-Retrospektive bringt uns keinen Mehrwert.

… die laufende Pflege des Produkts sorgt dafür, dass wir die Sprints nicht fertigstellen.

… die Scrum-Master-Verantwortlichkeit übernimmt unser Senior-Entwickler mit.

… nur in einem Projekt zu arbeiten, funktioniert bei uns nicht.«

Fehlende Komplexität

»Wir arbeiten agil, denn wir nutzen Scrum.« Dieser Satz führt in einigen Organisationen dazu, dass Scrum genutzt wird, obwohl es nicht geeignet für die Aufgabe ist. Der Scrum Guide definiert:

»Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.«

Dies bedeutet, Scrum zu verwenden, führt zu einem Overhead, der dann wiederum dem Rahmenwerk angelastet wird.

Kontrolle

Es wird häufig versucht, die Komplexität von Scrum-Projekten genauso (be)greif-bar zu machen, wie es unter Anwendung von klassischen Projektmanagementmethoden versucht wird. Der Versuch scheitert dann oftmals kläglich, da die Planung von etwas Unbekanntem – wir wissen ja noch nicht, was als Ergebnis herauskommen wird – nicht möglich ist (Projektparadoxie). Dies führt dann in stark kontrollierten Umfeldern zu noch mehr Planung, um den Schein von Vorhersagbarkeit und Sicherheit aufrecht zu erhalten.

»Scrum by the book funktioniert bei uns nicht« ist ein nicht seltener Ausspruch, den wir zu hören bekommen. Wir haben dann oftmals den Reflex, nachzufragen, wann die 10 Seiten des Scrum Guide überhaupt einmal Anwendung gefunden haben, um zu diesem Schluss zu kommen. Wir fragen dies nicht, denn wir stellen in vielen Fällen fest, dass die agilen Prinzipien und die Werte von Scrum keine Rolle spielen. Ein Zeichen für uns, dass Scrum lediglich ein Vehikel dafür ist, den organisatorischen Status quo aufrechtzuerhalten, aber unter dem Vorwand, agil zu sein.

Wir werden also hellhörig, wenn wir Menschen »by the book« sagen hören. Werden Sie dies auch und hinterfragen Sie sich selbst, wenn Sie die Person sind, die es sagt.

Wir könnten allein diesem Themenfeld ein ganzes Buch widmen und diese Liste noch weiter fortsetzen. Wir haben uns jedoch für diese Praxisbuch entschieden, das Ihnen Alternativen aufzeigt und Impulse gibt, mit denen Sie Ihre Organisation oder Ihre Scrum-Teams jeden Tag ein klein wenig »agiler« machen können.

Wenn Sie bei Ihrer Arbeit den Fokus auf folgende drei Aspekte in all Ihren Handlungen legen, dann stellen Sie die Weichen für ein erfolgreiches Scrum-Projekt:

Wertschöpfende Inkremente

»Das gesamte Scrum Team ist ergebnisverantwortlich (accountable), in jedem Sprint ein wertvolles, nützliches Inkrement zu schaffen«

(

scrumguides.org

). Am Ende eines jeden Sprints sollte Wert geliefert werden. Diese Produktinkremente entsprechen der Definition of Done (siehe

Abschnitt 4.1.3

) und sind potenziell auslieferbar (Potentially Shippable).

Selbstmanagement

Scrum-Teams managen sich selbst und entscheiden, was notwendig ist, um die gemeinsame Zusammenarbeit zu verbessern und das Projekt zum Erfolg zu führen. Dafür ist die Bevollmächtigung (engl. Empowerment) aller Beteiligten notwendig, damit das Scrum-Team im Sinne des Scrum Guide

»umsetzungsverantwortlich (responsible) für alle produktbezogenen Aktivitäten«

(

scrumguides.org

) agieren kann.

Inspect & Adapt

»Scrum basiert auf Empirie und Lean Thinking. Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf der Grundlage von Beobachtungen getroffen werden«

(

scrumguides.org

). Der Kern von Scrum ist die Empirie und daher ein täglicher Begleiter, der nicht mal eben ausgesetzt werden kann. Das inkrementelle und iterative Vorgehen von Scrum dient der Vorhersagbarkeit und Risikokontrolle.

Wir geben Ihnen in Kapitel 3 mit dem Blick auf das Scrum-Team noch weitergehende Impulse an die Hand.

Wir machen Scrum-Teams gerne bewusst, dass keines der Elemente von Scrum weggelassen werden kann. Dazu nutzen wir die Übung »Scrum ohne …«. Die Teilnehmenden werden in der Übung in Kleingruppen aufgeteilt. Jede Gruppe nimmt sich dann einen Bestandteil von Scrum vor und überlegt sich, was dies für Implikationen auf die Verwendung von Scrum hat. »Was wäre Scrum ohne Retrospektive?« steht dann z. B. für eine Kleingruppe im Fokus. Oder: »Was wäre Scrum ohne Product Owner?« Die Diskussionen und gewonnenen Erkenntnisse aus der Übung setzen viele »Aha«-Momente frei.

Ein Scrum Master kann die Übung dazu nutzen, um zu informieren, aufzuklären und aktuelle Schwachstellen in den Fokus zu nehmen.

Agil sein beginnt im Kopf

Agilität ist eine Haltung. Diese Haltung wird durch das tägliche Lernen in der praktischen Arbeit mit anderen Menschen gebildet. Je mehr positive Aspekte und Assoziationen mit der täglichen Arbeit einhergehen, desto mehr wird Agilität zum Selbstverständnis.

Nachfolgend stellen wir agile Werte vor, deren bewusste Einforderung sich in der Praxis besonders bewährt hat.

Anstatt die Werte nur in einer Präsentation zu vermitteln, machen Sie diese, wann immer es geht, greifbar und erlebbar. Beziehen Sie dafür Situationen aus dem Arbeitsalltag mit ein, sodass nicht nur ein »Ihr müsst Mut beweisen« auf dem Papier steht, sondern auch gleichzeitig der Kontext deutlich wird.

Wann immer nach den Werten gehandelt wird, sollte dies vorgehoben und gelobt werden. Soweit alte Muster oder Verhaltensweisen auftreten, sollte darüber gemeinschaftlich reflektiert und die Frage gestellt werden: »Was hätte auch bzw. besser funktioniert?«

2.1Agile Werte

Spielerisch wertvoll

Als Scrum Master möchte Finn alle in puncto agile Werte gerne auf einen gemeinsamen Nenner bringen. Dazu hatte er sich etwas überlegt und das gesamte Scrum-Team am Nachmittag auf einen Kaffee eingeladen. In der Einladung hatte er nur angedeutet, dass es lustig werden würde.

Finn hatte die Idee, die agilen Werte auf Basis des bekannten Memory-Spiels zu vermitteln. Dieses Spiel hat er statt der Bilderpärchen mit Bildern und Worten, die die agilen Werte umschreiben bzw. benennen, umgestaltet. Auf den Memory-Karten standen Wörter wie »Kommunikation«, »Mut«, »Feedback«, »Respekt«, »Offenheit« und weitere. Nachdem Finn die Regeln erklärt hatte und die skeptischen Blicke auf einigen Gesichtern verflogen waren, bat er alle, sich in drei Pärchen aufzuteilen. Den Siegern stellte er einen Gewinn in Aussicht.

Alle fingen sofort an zu spielen. Finn hatte Spaß, den drei Pärchen zuzusehen, die völlig in ihr Spiel vertieft waren. Dabei flogen ständig die agilen Werte im Raum herum, wenn jemand die Karten umdrehte und vielleicht daneben lag. Als auch die Letzten ihr Spiel beendet hatten, wurden feierlich die Sieger gekürt. Anschließend kam Finn zurück auf das Spiel und stellte die Frage in die Runde: »Sagt mal, was verbirgt sich für euch hinter den Begriffen auf den Karten?« Nachdem klar war, dass es agile Werte waren, die für die Zusammenarbeit im Team wertvoll und wichtig sind, fragte Finn nach Beispielen aus der Praxis und hielt das Gespräch am Laufen. Es kamen auch Gegenfragen, die Finn, wenn niemand aus dem Team eine passende Antwort hatte, beantwortete.

Sein Plan ging auf, denn er hatte einen spielerischen Weg gesucht, die Werte greifbar zu machen. Am Ende übergab er jedem aus dem Team eine Version des Spiels und eine Spielbeschreibung, auf der neben den agilen Werten auch das Agile Manifest und die agilen Prinzipien niedergeschrieben waren.

Den agilen Weg zu gehen, bedeutet auf der einen Seite, Auftraggeber, Kunden und Anwender in das Zentrum aller geplanten Bemühungen zu stellen. Auf der anderen Seite stellen die agilen Werte und Prinzipien, gepaart mit neuen Modellen der Führung, auch den Umgang mit allen in der Organisation in den Vordergrund. Genauso wie die Kundschaft, für die wir Lösungen entwickeln, im Fokus steht, so steht auch jeder Mensch in einem Unternehmen im Zentrum der Aufmerksamkeit.

Dem Themenschwerpunkt haben sich Laura Paradiek und Robert Wiechmann in ihrem Buch »Agile Werte leben« gewidmet [WiechmannParadiek 2020]. Weitere Ideen für das Finden oder Erlebbarmachen von Werten finden Sie auf wertehelden.de.

Heutzutage stellen gute Wissensarbeiterinnen den entscheidenden Wettbewerbsvorteil gegenüber der Konkurrenz dar. Der Markt ist in einigen Segmenten spärlich gesät mit guten Fachkräften. Diese verfügen häufig über ein sehr genaues Bild darüber, was möglich und was nicht möglich ist, und wollen an Entscheidungen partizipieren und diese nicht einfach nur vorgesetzt bekommen. Das fängt bei der Auswahl guter Arbeitswerkzeuge an und reicht bis zu strategischen Entscheidungen des Managements.

Es gilt, Vertrauen und Wertschätzung zu zeigen sowie Mut und Kreativität bei den Menschen zu fördern. Dabei geht es in erster Linie darum, sich Bedürfnissen anzunehmen, mit Wünschen auseinanderzusetzen oder Menschen mit ihren Gefühlen und Emotionen ernst zu nehmen. Es geht um das Miteinander und nicht um die Befriedigung individueller Ziele oder Bedürfnisse auf Führungsetagen. Es sind individuelle Freiräume zu schaffen, um die Entwicklung aller zu fördern und sie nicht zu kontrollieren [Semler 1993]. Es geht für Manager um das Verstehen, um Vertrauen in die eigenen Fachkräfte und um das Setzen der richtigen Führungsimpulse im richtigen Augenblick.

Es ist schwierig, das Verhalten von Menschen respektive Managern zu ändern. Daher gilt es eher, das Verständnis für die Werte und notwendigen Veränderungen zu entwickeln. Nach und nach werden sich diese Veränderungen im Denken der Personen durchsetzen und Früchte tragen. Scheuen Sie sich daher nicht, Führungspersonen Feedback zu geben. Auch wenn Sie dies im ersten Moment Überwindung kostet, werden Sie merken, dass die Person dankbar sein wird, dieses Feedback zu erhalten. Denn in den vielen Unternehmen hört das Feedback-Geben und -Nehmen in den leitenden Positionen auf.

Sprechen wir mit Führungspersonen über die Wichtigkeit der Werte, erhalten wir in der Regel sofortige Zustimmung, sind die Werte doch so trivial und selbstverständlich. Wir hören dann Sätze wie beispielsweise: »Natürlich kommunizieren wir ausreichend. Aber wir können die Mitarbeiterinnen ja nicht mit jeder Information verrückt machen.« Kratzt man etwas an der Oberfläche, stellt man aber schnell fest, dass nicht alles Gold ist, was glänzt, und dass die agilen Werte doch noch etwas nachhaltiger verankert werden sollten.

In unseren Workshops, die wir zu Beginn eines Projekts mit neuen Scrum-Teams durchführen, stellen die agilen Werte einen wichtigen Abschnitt dar. Jedes Scrum-Team hat seine eigene Interpretation der Werte, sodass wir das Team neben der Benennung allgemeiner Beispiele bitten, für sich selbst zu definieren, was es unter dem jeweiligen Wert versteht. Dieses Verständnis notieren wir und machen es im Nachgang für alle zugänglich.

Die verschiedenen agilen Vorgehensweisen benennen zum Teil unterschiedliche Werte, die aber in ihrem Zusammenwirken sehr ähnlich sind – nicht zuletzt, weil sie untereinander ein stimmiges, sich selbst regulierendes System bilden.

Das Wertesystem von Scrum umfasst fünf Werte. Der Scrum Guide (scrumguides.org) definiert:

»Die erfolgreiche Anwendung von Scrum hängt davon ab, dass die Menschen immer besser in der Lage sind, fünf Werte zu leben: Commitment, Fokus, Offenheit, Respekt und Mut.«

In Ergänzung heißt es dort:

»Wenn diese Werte durch das Scrum Team und die Menschen, mit denen es arbeitet, verkörpert werden, werden die empirischen Scrum-Säulen Transparenz, Überprüfung und Anpassung lebendig und bauen Vertrauen auf.«

Um die Scrum-Werte greifbar zu machen, nutzen wir als Metapher das Scrum-Haus (siehe Abb. 2–1). Es macht deutlich, dass die Scrum-Werte tragende Säulen sind, um Vertrauen im Team aufzubauen. Die Stufen ins Haus führen über die Transparenz des Gesamtprozesses und der eingesetzten Artefakte. Diese Transparenz macht das Überprüfen (Inspect) möglich und führt zu notwendigen Anpassungen (Adapt). Um diese Stufen hinaufgehen zu können, muss das Scrum-Team handlungsfähig (empowered) sein, damit Entscheidungen zur Veränderung auch durchgeführt werden können.

In unserer Arbeit mit unterschiedlichen Teams ergänzen wir die Scrum-Werte um zwei wichtige Aspekte: Kommunikation und Feedback. Wir haben in vielen Organisationen festgestellt, dass mit Einführung neuer Arbeitsweisen das Phänomen entsteht, dass nicht mehr offen kommuniziert und Feedback vermieden wird. Es wird zum Schein eine »Alles-in-bester-Ordnung«-Mentalität an den Tag gelegt, weil es eben zur neuen Arbeitsweise dazu gehört und somit vieles unausgesprochen bleibt. Diese Scheinrealität implodiert dann oftmals sehr schnell, sobald die Beteiligten unter Stress geraten, ein kritischer Fehler auftaucht oder jemandem sprichwörtlich der Kragen platzt. Daher sind eine offene Kommunikation und mutiges Feedback ein wichtiger Bestandteil unseres Wertesystems.

Abb. 2–1Scrum-Haus

[WiechmannParadiek 2020] zeigen in ihrem Buch anschaulich auf, was das Leben der Werte im Arbeitsalltag eines Scrum-Teams bedeuten kann und welchen Einfluss diese auf Verhalten und Handlungen der Beteiligten haben.

Tab. 2–1Agile Werte im Alltag eines Scrum-Teams

Wert

Beispiel Handlungen & Verhalten

»Das Scrum Teamcommittetsich, seine Ziele zu erreichen und sich gegenseitig zu unterstützen. Sein primärerFokusliegt auf der Arbeit des Sprints, um den bestmöglichen Fortschritt in Richtung dieser Ziele zu bewirken. Das Scrum Team und dessen Stakeholder sindoffenin Bezug auf die Arbeit und die Herausforderungen. Die Mitglieder des Scrum Teamsrespektierensich gegenseitig als fähige, unabhängige Personen und werden als solche auch von den Menschen, mit denen sie zusammenarbeiten, respektiert. Die Mitglieder des Scrum Teams haben denMut, das Richtige zu tun: an schwierigen Problemen zu arbeiten.« (scrumguides.org)

Mut (Courage)

Wir teilen jede Information und halten diese nicht hinter dem Berg oder geben anderen die Schuld, auch bei negativen Ergebnissen.

Wir sagen lieber »Nein«, als falsche Versprechungen zu machen.

Wir ziehen die Möglichkeit des Scheiterns in Betracht und erkennen an, dass wir aus dem Scheitern für spätere Aufgaben lernen.

Wir sagen offen, wenn wir Hilfe benötigen, und bitten darum.

Offenheit (Openness)

Wir versuchen, die Wahrheit zu verstehen und zu akzeptieren.

Wir bemühen uns um ein sicheres Umfeld, in dem alle offen die Wahrheit sagen.

Wir sind ehrlich in unserer Kommunikation und in unserem Verhalten.

Wir zeigen Transparenz in unserem Entscheidungsprozess.

Wir liefern genaue Informationen in einer gut sichtbaren und zeitnahen Weise.

Wir machen implizite oder explizite Zusagen und Versprechen in gutem Glauben.

Selbstverpflichtung (Commitment)

Wir übernehmen Verantwortung für die Verpflichtungen, die wir eingehen.

Wir treffen Entscheidungen und handeln im Interesse des Unternehmens, der öffentlichen Sicherheit und unserer Umwelt.

Wir übernehmen die Verantwortung für Fehler und nehmen umgehend Korrekturen vor und kommunizieren diese an relevante Personen.

Wir legen alle tatsächlichen oder potenziellen Interessenkonflikte den entsprechenden Parteien proaktiv und vollständig offen.

Fokus (Focus)

Wir fokussieren uns auf das vereinbarte Ziel und lassen uns nicht davon abbringen.

Wir kommunizieren frühzeitig, wenn wir nicht in der Lage sind, das Ziel zu erreichen.

Wir erkennen an, dass wir unsere Aussagen mit bestem Wissen und Gewissen tätigen, es jedoch zu Veränderungen kommen kann.

Wir nähern uns in kleinen Schritten dem Ziel, um Fehler frühzeitig zu erkennen und den Kunden schnellstmöglich zufriedenzustellen.

Wir treffen Zielvereinbarungen immer vor dem Hintergrund, qualitativ hochwertige Arbeit an den Kunden auszuliefern.

Respekt (Respect)

Wir respektieren die Rechte und Überzeugungen anderer.

Wir wenden uns direkt an diejenigen Personen, mit denen wir einen Konflikt oder eine Meinungsverschiedenheit haben.

Wir verhalten uns professionell, auch wenn es nicht erwidert wird.

Wir diskriminieren andere nicht aufgrund von Geschlecht, Rasse, Alter, Religion, Behinderung, Nationalität oder sexueller Orientierung.

Vertrauen (Trust)

Wir vertrauen uns gegenseitig und unterstützen uns auch in schwierigen Situationen.

Wir vertrauen darauf, dass alle nach bestem Gewissen handeln.

Wir üben nicht die Macht unseres Fachwissens oder unserer Position aus, die Entscheidungen oder Handlungen anderer unangemessen zu beeinflussen, um auf ihre Kosten persönlich davon zu profitieren.

Wir schmücken uns nicht mit fremden Federn für die Leistungen anderer.

Kommunikation

Wir kommunizieren offen und frühzeitig miteinander.

Wir kommunizieren lösungsorientiert und wertschätzend miteinander.

Wir schützen vertrauliche Informationen, die uns anvertraut wurden.

Feedback

Wir geben uns regelmäßig Feedback, um Missverständnisse zu vermeiden.

Wir sehen Feedback als Möglichkeit, zu wachsen und besser zu werden.

Wir erkennen an, dass negatives Feedback eine Chance ist, um über eigenes oder fremdes Verhalten zu reflektieren.

Wir erkennen die Regeln zum Feedback-Geben und Feedback-Nehmen an und legen Wert darauf, diese einzuhalten.

Die genannten Werte sind ein guter Startpunkt für die Arbeit mit Ihrem Scrum-Team. Gehen Sie jedoch noch einen Schritt weiter und erarbeiten Sie mit allen relevanten Personen für das Projekt ein gemeinsames Verständnis der Werte und halten Sie sich nicht zurück, weitere Werte wie z. B. Achtsamkeit, Spaß oder Zuverlässigkeit zu ergänzen.

Neben den genannten Werten möchten wir die Wichtigkeit der agilen Prinzipien für die richtige Umsetzung von Scrum noch einmal explizit hervorheben. Nachfolgend beleuchten wir die agilen Prinzipien und arbeiten die darin enthaltenen agilen Werte, Schlüsselbegriffe sowie Artefakte und Scrum-Events heraus. Entgegen dem Agilen Manifest verwenden wir eine leicht angepasste Version, die allgemeingültiger ist und nicht den Fokus auf Softwareentwicklung, sondern Produktentwicklung hat.

2.2Agile Prinzipien

Das Agile Manifest (agilemanifesto.org) ist ein wesentlicher Grundstein der agilen Bewegung und die Grundlage des Handelns und Denkens vieler »Agilisten«. Genauso bilden die 4 Leitsätze und 12 Prinzipien des Manifests auch die Leitplanken für jeden unserer Schritte. Wir verstehen das Agile Manifest als den Ausgangspunkt, der durch gemeinsames Erleben und Ausgestalten zu einem jeweils für den Unternehmenskontext und die Unternehmenskultur individuellen Manifest entwickelt werden kann. Jeff Sutherland, Mitbegründer des Agilen Manifests, hat nach 20 Jahren des Bestehens noch einmal erläutert, wie es entstanden ist, und prognostiziert für die Zukunft: »Der Einsatz von Agile und Scrum nimmt weiter zu, aber es kann noch mehr getan werden. Ich bin fest davon überzeugt, dass irgendwann alle Organisationen agil sein werden. Jeder muss agil sein, aber diejenigen, die am agilsten sind, werden am erfolgreichsten sein« [URL:Sutherland a].

Abb. 2–2Das Agile Manifest als Grundlage der Zusammenarbeit

Im Zentrum des Manifests steht der Mensch. Lassen Sie uns nachfolgend gemeinsam einen Blick darauf werfen, was in den knappen Handlungsanweisungen für wertvolle Informationen und Inspirationen stecken.

Neben dem Agilen Manifest (auch bekannt als »Manifesto for Agile Software Development« oder »Agile Manifesto«, agilemanifesto.org) haben sich über die Jahre weitere Strömungen entwickelt, die den Schwerpunkt nicht auf die Softwareentwicklung legen. Zur weiteren Auseinandersetzung empfehlen wir Ihnen die folgenden Quellen: modernagile.org, agile2.net, next-level-working.com, betacodex.org oder das »Manifest für menschliche Führung« von Marcus Raitner [Raitner 2019].

Kunden zufriedenstellen

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Produkte zufriedenzustellen.

Für die Entwicklung von wertvollen Produkten ist ein Scrum-Team zusammenzustellen, das alle erforderlichen Aufgaben eigenständig bewerkstelligen kann. Um der höchsten Priorität volle Aufmerksamkeit widmen zu können, ist für stabile Rahmenbedingungen zu sorgen und Störungen sind fernzuhalten. Frühe Auslieferung bedeutet, dass die Ergebnisse so schnell wie möglich dem Kunden präsentiert werden sollten, um zügig Feedback zu erhalten und neues Wissen in die Entwicklung einfließen zu lassen. Das iterative Vorgehen mit Scrum sorgt für die kontinuierliche Lieferung und Abstimmung von Resultaten in kurzen Zyklen, die nicht länger als vier Wochen sind. Was wertvolle Inkremente sind, wird durch den Product Owner (vgl. Abschnitt 3.3) definiert, der die Product Backlog Items nach ihrem Geschäftswert im Product Backlog (vgl. Abschnitt 4.2) sortiert.

In diesem prägnanten Satz sticht die Nutzung der iterativen Produktentwicklung heraus sowie der wichtige Aspekt, den Kunden in das Zentrum der Aufmerksamkeit zu rücken.

Wir stellen in unserer Praxis vielerorts fest, dass diejenigen, die das Produkt verwenden und dafür Geld zahlen, nur eine untergeordnete Rolle spielen und in den Hintergrund rücken. Der Produktverantwortliche weiß vermeintlich genau, was die Kunden wollen. Der Vertrieb macht unabgesprochene Zusagen für Funktionen, die »eigentlich schon längst da sein müssten«. Die Marketingabteilung grübelt darüber, wie die Preisgestaltung nach oben angepasst werden kann, ohne dass der Kunde einen spürbaren Mehrwert davon hat.

Sorgen Sie als Scrum Master dafür, dass der Product Owner als Vertreter oder Vertreterin der Kunden diese nicht aus den Augen verliert und zu einer Marionette interner Stakeholder mutiert.

Änderungen willkommen heißen

Wichtige Anforderungsänderungen, selbst spät in der Entwicklung, sind willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

Die positive Ausdrucksweise dieses Prinzips spiegelt den offenen Umgang mit möglichen Änderungen wider. Die Rahmenbedingungen für die Entwicklung eines Produkts sind vielfältig und einem laufenden Wechsel unterworfen. So wie sich der Markt ändern kann oder der Bedarf an einem Produkt, so agil sollte man auch mit diesen Änderungen umgehen, um nah am Marktgeschehen zu bleiben. Diese Änderungen sind für die Kundenzentrierung bedeutend, denn sie können von großem Vorteil für den Kunden sein.

Die Marketingabteilung fragt zum wiederholten Male, ob nicht »noch schnell eine kleine Änderung« mit aufgenommen werden kann, da bereits in wenigen Tagen eine Werbekampagne startet. Oder die Abteilungsleiterin trifft in einem Meeting die Entscheidung, dass etwas »ganz dringend umgesetzt« werden soll, und übt Druck auf das Scrum-Team aus, dies in den laufenden Sprint mit aufzunehmen. Es gibt viele Arten, die Planung eines Scrum-Teams zunichte zu machen und den geschützten Sprint sowie Arbeitsfluss zu stören. Dieses Prinzip bedeutet nicht, dass Änderungen willkürlich getroffen werden können, sondern vorrangig auf Basis von frühem Kundenfeedback oder wenn es strategisch sinnvoll ist.

Als Scrum Master ist es wichtig, hier offenzulegen, wann es sich um vermeidbare Änderungen und damit um die Störung des Ablaufs handelt.

Häufige Auslieferung

Liefern Sie funktionierende Produktlösungen regelmäßig, innerhalb weniger Wochen oder Monate aus und bevorzugen Sie dabei die kürzere Zeitspanne.

Am Ende eines jeden Sprints soll ein fertiges, potenziell auslieferbares Inkrement (Potentially Shippable) vorliegen, das vollumfänglich einsetzbar und kein Prototyp oder eine theoretische Ausarbeitung ist. Die Frequenz, in der dies passiert, ist möglichst kurz zu halten, um zügiges Feedback von den Anwendern zu erhalten. Dieses Feedback wird dann wiederum in die Weiterentwicklung des Produkts einfließen. Je wichtiger oder riskanter die Produktentwicklung ist, desto kürzer sollten die Iterationen sein und desto enger die Zusammenarbeit mit Anwendern, Kunden oder Auftraggebern gestaltet werden.

Wir denken eher in Tagen oder Wochen als in langen 4-wöchigen Sprints. Scrum-Teams, die z. B. eine Webanwendung bauen, liefern teilweise mehrmals täglich, wenn ihre technischen und organisatorischen Rahmenbedingungen es erlauben.

Fachübergreifende Zusammenarbeit

Fachexperten und Produktentwickler müssen während des Projekts täglich zusammenarbeiten.

Die enge Zusammenarbeit der Menschen, die ein breites Wissen über die Zielgruppe oder den Zielmarkt haben, mit jenen, die das Produkt entwickeln, führt zu den besten und wertschöpfendsten Resultaten. Der Product Owner sortiert die Backlog Items entsprechend dem höchsten Geschäftswert und die Entwickler unterstützen ihn bei der Pflege des Product Backlog (vgl. Abschnitt 5.4). Das Prinzip drückt stark die notwendigen Komponenten Kommunikation und Kollaboration aus, die einen klaren Vorteil agiler Entwicklung repräsentieren. Um schnelle Feedbackschleifen durch den direkten Austausch aller Personen zu gewährleisten, sollten sich die Beteiligten nur auf das Produktziel konzentrieren und über die gesamte Projektlaufzeit zusammenarbeiten dürfen.

Wir haben viele Organisationen kennengelernt, in der die IT oder die Entwicklung als Dienstleister gesehen oder behandelt wird. Anforderungen werden sprichwörtlich über den Zaun geworfen und erwartet, dass die Scrum-Teams sich darum kümmern werden. Oder Auftraggeber beauftragen einen Dienstleister, der sich um die Produktentwicklung kümmern soll und erwarten dementsprechend nur Ergebnisse, statt bei der Entwicklung zu partizipieren.

Es gibt zwei wichtige Aspekte, denen Sie als Scrum Master Beachtung schenken sollten. Die Mitglieder des Scrum-Teams benötigen das notwendige Know-how, um zur Lösungsfindung beizutragen. Zweitens sind Stakeholder, wie z. B. Auftraggeber, Projektsponsoren oder interne Abteilungen, eher als Partner zu verstehen und eng an das Scrum-Team zu binden, damit Expertenwissen und Expertise direkt genutzt werden kann.

Unterstützen und Vertrauen

Errichten Sie Projekte rund um motivierte Individuen. Geben Sie ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertrauen Sie darauf, dass sie die Aufgabe erledigen.

Mit der Auswahl der richtigen Teammitglieder steht und fällt auch jedes agile Team. Individuen, die mit dem Herzen dabei sind und im Sinne des Scrum-Teams agieren, werden das Projekt voranbringen. Gibt man ihnen dazu die Freiheit, das zu tun, was getan werden muss, wird sich die Kreativität schnell entfalten. Das Setzen von Rahmenbedingungen, die eine freie Entfaltung ermöglichen, die Einrichtung einer störungsfreien Arbeitsatmosphäre und die Bereitstellung adäquater Arbeitswerkzeuge wird das in das Scrum-Team gesetzte Vertrauen nicht enttäuschen.

Wenn Sie als Scrum Master vor der Zusammenstellung eines neuen Scrum-Teams stehen oder ein neues Projekt umgesetzt werden soll, setzen Sie sich dafür ein, dass die Personen eigenständig die Entscheidung treffen können, ob sie in diesem Team oder an diesem Projekt arbeiten wollen. Sie erreichen damit, dass die Eigenmotivation bei den Beteiligten steigt, wenn diese ihrem Interesse nach an etwas arbeiten können, an das sie glauben bzw. was sie intrinsisch motiviert.

Direkte Kommunikation

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Teams zu übermitteln, ist ein Gespräch von Angesicht zu Angesicht.

Transparenz ist eines der Schlüsselelemente des Rahmenwerks. Es reicht dabei jedoch nicht, Informationen sichtbar zu machen, sondern auch der direkte Austausch mit Menschen ist zu pflegen. Das direkte Gespräch ist dabei zu bevorzugen, anstatt den Umweg über indirekte Kommunikationsmittel zu wählen. Die Events von Scrum zielen vordergründig darauf ab, dass der Informationsfluss innerhalb des Scrum-Teams nicht abreißt.

Das Agile Manifest oder auch Scrum sind ursprünglich davon ausgegangen, dass die Menschen zusammen an einem Standort arbeiten. Heutzutage ist das eher die Ausnahme und die verteilte Arbeit über mehrere Standorte die Regel. Ein häufig auftretendes Verhalten ist dann oft, weniger von Angesicht zu Angesicht zu kommunizieren und den Teamchat oder E-Mails zu nutzen. Als Scrum Master sind Sie hier frühzeitig gefragt, zu intervenieren. Wir gehen in Kapitel 6 vertiefend darauf ein.

Funktionierende Lösungen

Funktionierende Lösungen sind das wichtigste Fortschrittsmaß.

Am Ende einer jeden Iteration zählt nur, ob die erstellte Lösung auch den Abnahmekriterien entspricht und vollumfänglich und fehlerfrei einsatzbereit ist. Andere Maßeinheiten spielen eine untergeordnete Rolle. Für ein Scrum-Team zählt in erster Linie auslieferbare Inkremente am Ende eines Sprints.

Nicht selten haben wir Scrum-Teams erlebt, die im Sprint-Review darüber berichten, was alles während eines Sprints angefasst wurde. Es werden dann gelöste Fehler vorgestellt, über unfertige Arbeitsergebnisse berichtet oder sogar mit Verweis auf den nächsten Sprint gezeigt.

Eines der schaurigsten Beispiele, die wir erlebt haben, ist, den Scrum-Prozess »wasserfallartig« anzulegen, sodass die Fertigstellung eines Inkrements über mehrere zweiwöchige Sprints erfolgte (Wasserfallmethode). In einem ersten Sprint wird das Design erstellt. In einem folgenden Sprint wird von einem Teil des Scrum-Teams die Entwicklung vorgenommen, um diese Teilergebnisse dann von einem anderen Teil des Teams im nächsten Sprint zu testen. In diesem Fall war es so, dass sich die Fertigstellung von einem Sprint Backlog Item von zwei Wochen auf bis zu zehn Wochen dehnte und keine Transparenz darüber herrschte, wann ein Inkrement wirklich abgeschlossen war.

Legen Sie als Scrum Master den Fokus auf die Wertschöpfung des Scrum-Teams und sorgen Sie dafür, dass die kurzen Zyklen dazu führen, dass nicht nur Fortschritt im Sinne des Produktziels, sondern auch im Sinne des Lernens und der Weiterentwicklung der Beteiligten entsteht.

Nachhaltige Geschwindigkeit

Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Developer und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Dieses Prinzip ist auf den ersten Blick schwer zu verstehen, da Sie sich eventuell fragen, was mit »nachhaltiger Entwicklung« gemeint ist. Es bedeutet, dass eine konstante und ausgeglichene Arbeitszeit besser ist als hohe Schwankungen durch Mehrarbeit. Diese können sich negativ auf die Produktivität des Scrum-Teams auswirken und damit unter Umständen auf den Projekterfolg. Aber auch Wartezeiten oder Langeweile können ein Ausdruck für eine schwankende Entwicklungsgeschwindigkeit sein. Mit einer guten Sprint-Planung können diese Schwankungen vermieden werden. Um zu einem »Flow« zu gelangen, ist die Einbeziehung und ein Dialog aller Projektbeteiligten sowie ständiges Inspect & Adapt notwendig.

Kontinuität ist ein sehr wichtiges Element für Scrum-Teams. Keine funktionierenden Lösungen zu liefern, die letzten Tage des Sprints bis spät am Abend zu arbeiten, um Aufgaben zu erledigen, oder nicht die Werte und Prinzipien zu befolgen, werden zuverlässig zum Misserfolg führen.

Als Scrum Master sollten Sie auf die »Sustainable Pace« achten und nicht zulassen, dass von außen Druck auf das Scrum-Team ausgeübt wird, der beispielsweise zu Demotivation, Qualitätseinbußen oder Fluktuation führt.

Streben nach Qualität

Ständiges Augenmerk auf Qualität und gutes Design fördert Agilität.

Ein ständiges Streben nach Qualität lässt keine Routine zu. Routine würde bedeuten, nicht zu lernen und sein Wissen nicht auszubauen. Die Sammlung und der Austausch von Wissen innerhalb des Scrum-Teams ist ein wesentlicher Erfolgsfaktor. Dieser Wissenstransfer sollte kultiviert werden. Produkte sind ganzheitlich zu betrachten und sollten aufgeräumt und sicher sein. Es reicht nicht, wenn der Anwender zufrieden ist, sondern unter der Motorhaube darf auch keine Zeitbombe ticken, die ggf. früher oder später zu einem bösen Erwachen führt. Wenn Teams diese ganzheitliche Sicht verstehen und dazu bereit sind, sich laufend weiterzuentwickeln, dann wird der agile Funke überspringen.

Lean Thinking versteht unter Verschwendung jede Aktivität, die Ressourcen verbraucht, aber keinen Mehrwert für den Kunden bringt [PoppendieckPoppendieck 2003]. Fehler, die nachträglich gefunden werden, sorgen für Nacharbeit und im schlimmsten Fall wurde Ausschuss produziert oder Kunden verärgert.

Als Scrum Master sollten Sie die Fehlerrate des Scrum-Teams genau im Blick behalten und neben einem hohen Qualitätsbewusstsein bei allen Teammitgliedern auf eine hohe Testabdeckung und -automatisierung sowie technische Exzellenz achten.

Einfachheit ist essenziell

Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.

Einfachheit zielt auf die Reduzierung auf das Wesentliche ab. Wenn wir weitere Funktionalität zum Produkt hinzufügen, inwieweit können wir dann bestehende Funktionalität überarbeiten oder sogar entfernen? Sind die Features notwendig und liefern sie ausreichend Geschäftswert? Müssen wir das Rad neu erfinden oder können wir uns an freien Bibliotheken, Open-Source-Projekten oder kommerziellen Produkten bedienen? Kent Beck fordert daher zur Einfachheit auf, indem er seine Teams fragt: »What is the simplest thing that could possibly work?« [Beck 2004]. Sollten sich später Ergänzungen ergeben, werden diese erst dann behandelt. Bei all diesen Überlegungen ist es wesentlich, dass der höchste Geschäftswert zur Zufriedenheit des Kunden erzielt wird, ohne dem Kunden oder den Auftraggebern falsche Tatsachen vorzutäuschen.

Erinnern Sie die Entwickler und den Product Owner daran, dass sie sich »Just-in-Time« mit den wichtigsten Anforderungen auseinandersetzen sollten. Dies kann ruhig in einer Vorausschau von 2–3 Sprints erfolgen. Sich jedoch schon an die Ausarbeitung von etwas zu begeben, was in drei Monaten relevant sein könnte, ist meistens ein Investment zum falschen Zeitpunkt.

Selbstorganisiert agieren

Die besten Ideen und Lösungen entstehen durch selbstorganisierte Teams.

Wenn das gesamte Scrum-Team kollaborativ Ergebnisse erarbeitet, sich gemeinschaftlich verantwortlich fühlt und über Vor- und Nachteile von Produktideen und -funktionalitäten spricht, führt dies zu einer produktiven Arbeitsatmosphäre und sicher auch guten Endresultaten. Dabei hilft »Inspect & Adapt« dem Scrum-Team, sich ständig zu verbessern und gezielt gegenzusteuern, sollte eine Kursänderung notwendig sein.