Kitabı oxu: «30 Minuten Scrum»
Jürgen Hoffmann
30 Minuten
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.
©2021 GABAL Verlag GmbH, Offenbach
Das E-Book basiert auf dem 2021 erschienenen Buchtitel »30 Minuten Scrum« von Jürgen Hoffmann ©2021 GABAL Verlag GmbH, Offenbach.
ISBN Buchausgabe: 978-3-96739-079-7
ISBN epub: 978-3-96740-128-8
Umschlaggestaltung: die imprimatur, Hainburg
Umschlagkonzept: Martin Zech Design, Bremen
Lektorat: Eva Gößwein, Berlin
Abbildungen: Jürgen Hoffmann
Autorenfoto: Frank Hügle
Satz: Zerosoft, Timisoara (Rumänien)
© 2021 GABAL Verlag GmbH, Offenbach
Alle Rechte vorbehalten. Nachdruck, auch auszugsweise, nur mit schriftlicher Genehmigung des Verlags.
www.gabal-verlag.de
www.gabal-magazin.de
www.twitter.com/gabalbuecher
www.facebook.com/Gabalbuecher
www.instagram.com/gabalbuecher
In 30 Minuten wissen Sie mehr!
Dieses Buch ist so konzipiert, dass Sie in kurzer Zeit prägnante und fundierte Informationen aufnehmen können. Mithilfe eines Leitsystems werden Sie durch das Buch geführt. Es erlaubt Ihnen, innerhalb Ihres persönlichen Zeitkontingents (von 10 bis 30 Minuten) das Wesentliche zu erfassen.
Kurze Lesezeit
In 30 Minuten können Sie das ganze Buch lesen. Wenn Sie weniger Zeit haben, lesen Sie gezielt nur die Stellen, die für Sie wichtige Informationen beinhalten.
 Zahlreiche Zusammenfassungen innerhalb der Kapitel erlauben das schnelle Querlesen. |  |
Ein Fast Reader am Ende des Buches fasst alle wichtigen Aspekte zusammen.
Inhalt
Vorwort
1. Was ist Scrum?
Die „Entdeckung“ von Scrum
Wann ist Scrum sinnvoll?
Scrum-Werte
2. Scrum heute
Verantwortungen des Scrum Teams
Events im Rhythmus der Produktentwicklung
Scrum-Artefakte und Commitments
3. Von der Vision zum Produkt
Kick-off und Erarbeitung des Produkt-Ziels
Anforderungen verstehen
Kundenzentrierte Produktentwicklung
Scrum in der Praxis – Beispiele
7 Erfolgsregeln für den Start mit Scrum
Fast Reader
Der Autor
Weiterführende Literatur
Vorwort
Warum sollten Sie sich mit Scrum beschäftigen? Scrum ist seit einigen Jahren der Standard in der Produktentwicklung. Im Jahr 2020 gaben von weltweit mehr als 40.000 befragten Führungskräften, Anwendern und Beratern 75 Prozent an, dass sie Scrum einsetzen (digital.ai, 2020), und das umfasst praktisch jede Branche bis hin zu Non-Profit-Organisationen. Dabei nutzen große Firmen mit mehr als 20.000 Mitarbeitern Scrum schon länger als fünf Jahre – während mittelständische Unternehmen mit weniger als 1000 Mitarbeitern Scrum viel intensiver quer durch viele Funktionsbereiche einsetzen.
Die Fähigkeit, mit wechselnden Prioritäten gut umzugehen, ist die am häufigsten genannte Motivation für den Einsatz von Scrum. Dicht gefolgt von Transparenz in der Produktentwicklung, besserer Kooperation zwischen Geschäftsbereichen und IT, schnellerer Time-to-Market, höherer Team-Motivation und Produktivität sowie der Verringerung von Risiken und besseren Prognosen in der Produktentwicklung. Wenn Sie auch nur eines dieser Themen interessiert, dann ist dieses Buch für Sie der ideale Einstieg. An einigen Stellen im Text habe ich Verweise auf Bücher und kostenlos verfügbare Spezialliteratur hinzugefügt, falls Sie nach dem Einstieg noch etwas tiefer bohren möchten.
Bei der Benennung und Schreibweise der Scrum-Fachbegriffe folge ich den Übersetzern der deutschen Ausgabe des Scrum Guides vom November 2020. Dort ist auf den letzten zwei Seiten ein Glossar mit den entsprechenden für den deutschen Sprachraum empfohlenen Begriffen veröffentlicht.
Aufgrund des kompakten Buchformats nutze ich bei Pluralformen in der Regel das generische Maskulinum, bei Beispielen im Singular wechsle ich zwischen männlichen und weiblichen Formen. In jedem Fall beziehen sich die Aussagen auf alle Geschlechter.
Viel Erfolg mit Scrum wünscht Ihnen
Dr. Jürgen Hoffmann
www.emendare.de
1.Was ist Scrum?
Um größere Ziele zu erreichen, schließen sich Menschen seit Jahrtausenden in Organisationen zusammen. Über Jahrhunderte strukturierten sich große Organisationen in Einliniensystemen. Jeder Mensch hat genau einen Vorgesetzten und die Kollegen haben eine ähnliche Ausbildung und vergleichbare Tätigkeiten. Frederick Taylor beschreibt in seinem Hauptwerk „The Principles of Scientific Management“ die dazu passende Trennung von Denken und Handeln als die Aufteilung in Aufgaben von Management und Aufgaben der Arbeiterschaft. Er vertrat die Ansicht, dass der Arbeiter nicht fähig wäre, die beste Arbeitsmethode zu finden. Dieses Unterfangen müsse mit wissenschaftlichen Methoden von Spezialisten im Management durchgeführt werden. Scrum hingegen ist ein Ansatz, der das Denken und Handeln wieder an einer Stelle – im Scrum Team – zusammenführt. Ziel ist es, komplexe Probleme der Produktentwicklung schneller zu lösen und aus einer Kommunikation zwischen Bereichen, Abteilungen und Teams – aus der Inter-Team-Kommunikation – eine Intra-Team-Kommunikation zu machen.
1.1Die „Entdeckung“ von Scrum
Traditionelle Produktentwicklung ist mit einem Staffellauf vergleichbar. Spezialisten eines Fachgebiets geben den Staffelstab an die nächsten Spezialisten sequenziell weiter. Takeuchi und Nonaka veröffentlichten 1986 im Harvard Business Review (Takeuchi, 1986) eine Analyse der Produktentwicklungsprozesse erfolgreicher Produkte aus der Mitte der 1970er-Jahre. Sie entdeckten gemeinsame Muster und benutzten Rugby als Metapher für die neue Art der Produktentwicklung, bei der der Entwicklungsprozess aus der ständigen Interaktion von Spezialisten verschiedener Fachrichtungen entsteht. Das multidisziplinäre und handverlesene Team arbeitet von der ersten bis zur letzten Minute der Produktentwicklung zusammen. Der Wechsel zu einem solchen integrierten Ansatz ermöglicht schnelles Lernen und neue Denkansätze auf allen Ebenen der Organisation. Damit ist er auch ein Katalysator für marktangepasste Organisationsveränderungen.
Was hat Scrum mit Rugby zu tun?
Dass Scrum auf die Rugby-Metapher von Takeuchi und Nonaka zurückgeht, verrät schon der Begriff: „Scrum“ ist eine Bezeichnung aus dem Rugby-Sport und bedeutet „Gedränge“.
Sechs Erfolgsfaktoren
Nonaka und Takeuchi identifizierten in diversen Firmen wie zum Beispiel Honda, Epson, Fuji-Xerox, Canon und 3M sechs Erfolgsfaktoren. Diese führenden Unternehmen setzten Mitte der 1970er-Jahre mit Scrum auf folgende ineinandergreifende und sich ergänzende Erfolgsfaktoren beim Management ihrer Produktentwicklungsprozesse:
1. Eingebaute Instabilität
Die Unternehmensführung gibt nur ein sehr grobes Ziel oder eine strategische Richtung in Kombination mit herausfordernden Rahmenbedingungen vor. Alle Details bleiben in der Hand des Produktentwicklungsteams, das in einem täglichen Ringen um das tatsächlich Mögliche die Grenzen weitersteckt. Das Team startet aus einem Zustand von „Zero Information“ und erarbeitet sich immer weiter reichendes Wissen.
2. Selbstorganisierende Teams
Man erkennt ein selbstorganisierendes Team an drei charakteristischen Merkmalen:
Autonomie – es hat oder entwickelt alle Fähigkeiten, um zu liefern.
Gegenseitige Inspiration – es besteht aus einer breiten Mischung von Spezialisten und Persönlichkeiten.
Selbsttranszendenz – es reicht über sich selbst hinaus und verschiebt scheinbar unerreichbare Grenzen in der Produktentwicklung immer weiter.
3. Überlappende Entwicklungsphasen
Der sehr herausfordernde Zero-Information-Startpunkt zwingt die Teammitglieder, all ihr Wissen auf den Tisch zu bringen, um gemeinsam den nächsten Schritt zu gehen. Marktinformationen und technische Details spielen von der ersten Minute an zusammen und es entsteht ein gemeinsamer Rhythmus und ein perfektes Zusammenspiel aller beteiligten Experten.
4. Lernen auf allen Führungsebenen und in allen Fachrichtungen
Beschleunigtes individuelles Lernen und Gruppenlernen werden gefördert durch den Blick über den Tellerrand und herausfordernde Ziele, die den äußersten Einsatz von Kreativität fordern. Der Erwerb von Wissen außerhalb der eigenen Spezialisierung wird gefördert und ist erwünscht.
5. Fast unmerkliche Kontrolle
Kontrolle findet nicht durch Kontrolle der Tätigkeiten statt – das Management übt Kontrolle eher über die Gestaltung von Rahmenbedingungen aus. Nonaka und Takeuchi haben folgende Beispiele dafür zusammengestellt:
Wie sind Teams zusammengesetzt?
Unterstützt die Arbeitsumgebung Zusammenarbeit?
Wann haben die Ingenieure das letzte Mal mit einem Kunden gesprochen?
Führung durch Teamziele statt individueller Ziele.
Etablieren einer offenen Fehlerkultur, in der Fehler als Lernmomente begriffen werden.
Das Belohnen der Selbstorganisation von Zulieferern – sie erhalten den Auftrag, Probleme zu lösen, statt vorgedachte Lösungen anzufertigen.
6. Unternehmensweiter Wissenstransfer
Die Mitarbeiter geben ihr neu gelerntes Wissen innerhalb des Unternehmens gerne weiter – wenn das Management Kontaktmöglichkeiten schafft. Erfahrungen werden auch institutionalisiert. Wobei man da vorsichtig sein muss: Unter sich plötzlich ändernden Bedingungen können Lehren der Vergangenheit hinderlich sein. Es braucht einen Wechsel von Lernen und Abgewöhnen von Vertrautem, um in sich schnell wandelnden Märkten zu bestehen.
Die Entdeckung von Scrum für Software
1993 formte Jeff Sutherland das erste Scrum Team bei der Easel Corporation. 1995 präsentierte Ken Schwaber die Erfahrungen mit Scrum in der Softwareentwicklung auf der OOPSLA-Konferenz. In den Jahren seitdem ist Scrum von der Agile Community weiterentwickelt worden. Unzählige Beiträge von Anwendern und viele Konferenzen haben geholfen, Scrum zu verbessern und auf der ganzen Welt bekannt zu machen.
| Scrum ist nicht am Reißbrett entstanden. Es ist die kondensierte Erfahrung aus der Entwicklung Tausender Produkte. Sein erfolgreicher Einsatz setzt ein auf gegenseitigem Vertrauen basierendes Zusammenspiel von Management und Produktentwicklungsteams voraus. | |
1.2Wann ist Scrum sinnvoll?
Nicht in jeder Situation ist der Einsatz von Scrum sinnvoll. Ein Denkmodell, um sinnvolle Einsatzszenarien zu identifizieren, stammt aus frühen Versionen des Buches „Strategic Management and Organisational Dynamics“ von Ralph Stacey.
Abb. 1: Die Stacey-Matrix
Die den Denkraum aufspannenden Achsen sind die Fragen nach dem „Was“ (den Anforderungen) und dem „Wie“ (der Technologie) der zu bewältigenden Herausforderung. Im Bild erkennen wir nahe des Ursprungs beider Achsen die einfache Domäne. Hier geht es um sich wiederholende einfache Tätigkeiten, wie sie zum Beispiel in der Produktion am Fließband anfallen.
Beispiel: Als Student habe ich im Mercedes-Werk in Wörth am Rhein in der Fahrerhaus-Produktion mitgearbeitet. Alles, was ich für diesen Job – Einbau von Mittelkonsolen – wissen musste, hatten mir meine beiden Kollegen an der Fließbandstation innerhalb eines Tages beigebracht.
Wenn das zu lösende Problem etwas weiter weg vom Ursprung verortet ist, liegt es im Modell in der komplizierten Domäne. Hier ist eine Analyse einer Expertin erforderlich. Sie wird dann einen Plan entwickeln. Wenn die richtigen Mitarbeiter diesen Plan korrekt ausführen, wird er funktionieren.
Ganz anders die Situation sehr weit weg vom Ursprung: Wir wissen weder annähernd, was das Produkt können soll, noch haben wir die leiseste Idee, mit welcher Technologie eine Umsetzung gelingen kann. Vielleicht müssen wir die Technologie erst erfinden? Das ist die chaotische Domäne – manchmal auch Forschung oder Vision genannt. Bei dieser Art von Herausforderung braucht es ein paar Ansagen, um zum Beispiel auf der „Was“-Achse näher an den Ursprung zu gelangen.
Beispiel: Die Firma SpaceX wurde gegründet, um der Menschheit zu ermöglichen, den Mars zu kolonisieren. Zum Gründungsdatum im Juni 2002 war die Herausforderung in der chaotischen Domäne. Der wichtige Shift in die komplexe Domäne gelang durch den Fokus auf: „Baut erst mal eine Rakete, die starten und wieder landen kann. Über den Mars sprechen wir später.“
In der komplexen Domäne sind die Probleme lösbar durch einen Zyklus aus Experiment, einem Schritt der Überprüfung und einer anschließenden Anpassung des Experiments. Wie wir später sehen werden, realisiert Scrum einen solchen Zyklus.
Kompliziert oder komplex?
Im Scrum-Training werde ich oft nach dem genauen Unterschied zwischen „kompliziert“ und „komplex“ gefragt. Dazu ein Beispiel:
•Kompliziert: In der komplizierten Domäne kann die Expertin tatsächlich einen realistischen Plan machen. Sie fügt noch eine Liste mit zu klärenden Fragen hinzu und sobald die Mitarbeiter diese Liste abgearbeitet haben, steht der Plan fest.
•Komplex: In der komplexen Domäne hilft uns diese Analyse nur für einen sehr kleinen Schritt, weil dann auf einmal unsere Liste mit offenen Fragen um neue Fragen ergänzt wird. Im Komplexen ist es prinzipiell nicht möglich, einen Plan zu machen, der den gesamten Weg bis zur Lösung Bestand hat. Wir müssen ihn ständig neu anpassen und immer wieder neue Experimente vornehmen, die zu Beginn nicht absehbar waren. Das Ziel bewegt sich vor unseren Augen. Retrospektiv betrachtet sehen wir die Evolution der exzellenten Lösung – die man vorwärts in die Zukunft nicht planen konnte. Überall fehlten Daten und Erfahrungen, über die wir am Ende der Entwicklung verfügen.
Da Scrum den abgebildeten Zyklus aus „Experiment“, „Anpassen“ und „Überprüfen“ realisiert, ist es sinnvoll, Scrum in der komplexen Domäne einzusetzen. Hierbei ist es wichtig, zu verstehen, dass Produktentwicklung immer aus einer Mischung von einfachen, komplizierten, komplexen oder auch chaotischen Herausforderungen besteht. Wenn der Schwerpunkt im Komplexen liegt, ist der Einsatz von Scrum empfehlenswert. Und das ist der Erfahrung nach bei der Entwicklung wirklich neuer Produkte der Fall.
Dabei kann es sein, dass ein Produkt seinen Lebenszyklus in der chaotischen Domäne beginnt. Eine vage Idee – noch sehr unscharf – ist entstanden. Mit der Fokussierung auf einen Markt, eine Kundengruppe oder eine bestimmte Technologie bewegt sich das Produkt in die komplexe Domäne. Extrem beschleunigtes Lernen während der Entwicklung hilft uns, den entscheidenden Vorteil vor der Konkurrenz herauszuarbeiten.
Irgendwann ist das Produkt bei vielen Kunden im Einsatz. Es findet noch Produktpflege im geringen Umfang statt. Erfahrung und stabile Messwerte helfen jetzt, wo das Produkt in der komplizierten Domäne angekommen ist. Ein Kundenproblem kann von einem der Produktexperten analysiert und einer Kundin kann eine wasserdichte Reparaturanleitung oder ein funktionierender Workaround übermittelt werden.
In der einfachen Domäne angekommen, geht es nur noch um die Nutzung des Produktes. Einfache Schrittfür-Schritt-Anleitungen helfen, jedes mögliche Einsatzszenario in den Griff zu bekommen. Am Produkt selbst ändert sich nichts mehr.
Einsatzgebiete von Scrum
Neben der Anforderung, dass die zu lösende Herausforderung ein Team erfordert und in der komplexen Domäne liegen sollte, gibt es keine weiteren Einschränkungen. Bekannt wurde Scrum durch die Erfolge bei Softwareprodukten.
Wenn man mit der Liste von Produkten beginnt, die Nonaka und Takeuchi damals untersucht haben, findet man eine Spiegelreflexkamera, einen Kopierer, ein PC-System, ein Auto und eine Sucherkamera. Offensichtlich kann man Scrum in der Hard- und Softwareentwicklung sinnvoll einsetzen.
Meine Kollegen und ich haben in der Vergangenheit Teams begleitet, die in vielfältigen Bereichen tätig waren: Immobilienverwaltung, Entwicklung von Unterwasserrobotern, Sicherheitssysteme, Fensterheber für Autotüren. Wir kennen Scrum Teams, die an Sitzmechaniken, an medizinischen Geräten oder an Maschinen zur Herstellung von PET-Flaschen arbeiten. Außerdem haben wir Scrum in der Hochschullehre eingesetzt und es ist eine ganze Community rund um den Einsatz in Schulen und in der Erwachsenenbildung entstanden.
| Scrum kann immer dann angewendet werden, wenn es um eine komplexe Entwicklungsaufgabe geht. Ob das zukünftige Produkt eine Dienstleistung, ein Gerät oder eine Software ist, spielt nur für die Auswahl der Entwicklungspraktiken eine Rolle. Das Scrum Framework ist universell einsetzbar. | |
1.3Scrum-Werte
Scrum ist mit fünf Werten verknüpft. Beschrieben wurden sie in dem ersten Buch zu Scrum: „Agile Software Development with Scrum“ von Ken Schwaber und Mike Beedle. Darin vertreten die beiden Autoren die Idee, dass diese Werte keine Voraussetzung für die Einführung von Scrum sind, sondern dass bei konsequenter Anwendung von Scrum diese Werte in den beteiligten Menschen automatisch wachsen. Das ist eng damit verknüpft, die drei Säulen empirischer Prozesskontrolle – Transparenz, Überprüfung und Anpassung – lebendig werden zu lassen. Die fünf Werte sind:
1.Offenheit: Alle Informationen und Herausforderungen rund um die Arbeit des Scrum Teams werden zwischen diesem und den Stakeholdern in aller Transparenz bearbeitet.
2.Fokus: Das Sprint-Ziel und die Arbeit im Sprint liegen im täglichen Fokus des Scrum Teams.
3.Commitment: Die persönliche Verpflichtung auf die Ziele des Scrum Teams bestimmt das Handeln des Einzelnen.
4.Respekt: Der Umgang miteinander und mit Stakeholdern ist von gegenseitigem Respekt als fähige und eigenverantwortliche Menschen geprägt.
5.Mut: Das Scrum Team hat den Mut, schwierige Probleme anzupacken und dann das Richtige zu tun.
Das Manifest für Agile Softwareentwicklung
Neben diesen Werten wird das Handeln im Scrum Team auch von den Ideen und Prinzipien bestimmt, die im Manifest für Agile Softwareentwicklung 2001 beschrieben wurden. Dieses finden Sie unter: https://agilemanifesto.org/iso/de/manifesto.html
Allein die Diskussion der Auswirkungen der Werte und Prinzipien von Scrum auf die Arbeits-, Aufbau- und Ablauforganisation von Unternehmen kann ganze Bücher füllen. In unseren Scrum-Trainings diskutieren wir diese Folgen regelmäßig mit den Teilnehmern. Hier verweise ich stellvertretend auf das Buch „Agile Unternehmen“ (Hoffmann, 2018).
| Das Scrum Framework lässt sich in den unterschiedlichsten Bereichen anwenden. Besonders geeignet ist es für komplexe Entwicklungsaufgaben. Wichtig dabei ist, dass Management und Produktentwicklung einander vertrauen. Ohne Managementsupport wird der Versuch, Scrum einzusetzen, scheitern. Und ohne den Willen des Produktentwicklungsteams, neue Wege zu gehen, wird der Versuch des Managements, Scrum einzusetzen, sinnlos sein. Scrum ist mit den Werten Offenheit, Mut, Respekt, Fokus und Commitment verbunden. Mehr zu den Werten und Prinzipien lässt sich dem Manifest für Agile Softwareentwicklung entnehmen. Ihre Firmenkultur sollte mit diesen Werten und Prinzipien vereinbar sein, damit Scrum ohne Schwierigkeiten und mit Erfolg eingesetzt werden kann. | |
2.Scrum heute
Die aktuelle Definition von Scrum ist im Scrum Guide zu finden (https://www.scrumguides.org/). Zum Zeitpunkt der Erstellung dieses Buches ist der Scrum Guide vom November 2020 maßgeblich. Darin sind die Autoren ganz eindeutig: Jedes Element des Rahmenwerkes Scrum dient einem Zweck und ist wichtig für den mit Scrum erzeugten Wert und die Ergebnisse. Veränderungen daran sind vermutlich nur Versuche, Missstände in der Organisation zu verschleiern, und machen Scrum möglicherweise nutzlos.
In diesem Kapitel soll es um die grundlegenden Elemente von Scrum gehen. Bei der Anwendung von Scrum entstehen darüber hinaus Handlungsmuster, Prozesse und Einsichten, die zu Scrum passen. Sie liegen aber außerhalb einer reinen Beschreibung von Scrum und sind deshalb nicht Bestandteil dieses Kapitels. In Kapitel 3 sowie in „Scrum in der Praxis“ beschreibe ich einige über die Definition von Scrum hinausgehende wichtige Praxiserfahrungen.
2.1Verantwortungen des Scrum Teams
Die kleinste Einheit, das Atom von Scrum, ist ein Scrum Team. Ein kleines Team von zehn oder weniger Menschen mit drei speziellen Verantwortungen: Developer, Product Owner und Scrum Master. Es gibt keine Untereinheit eines Scrum Teams und auch keine Hierarchien. Sollten mehr als zehn Menschen an dem Produkt arbeiten müssen, bilden sie mehrere Scrum Teams, die sich ein Produkt, ein Product Backlog und einen Product Owner teilen. Weitere Informationen zu diesem Fall finden Sie im ersten Beispiel im Kapitel „Scrum in der Praxis“.
Das ganze Scrum Team ist für alle mit dem Produkt zusammenhängenden Tätigkeiten verantwortlich. Beispiele dafür sind Entwicklung von Hard- und Software, alle Arten von Tests, Experimente, Marktforschung, Betrieb, Wartung oder das Management von Stakeholder-Erwartungen und Kundenzufriedenheit. Folgerichtig muss die Organisation das Scrum Team mit den passenden Skills ausstatten sowie der Vollmacht, um diese Arbeiten auszuführen.
Wenn Sie jetzt an Ihre Organisation denken und sagen: „Unmöglich! Das gibt es in keiner Organisation“, dann gebe ich Ihnen ein Gegenbeispiel: In einem kleinen Startup mit einer Handvoll Mitarbeiter ist das ohne Weiteres möglich. Es ist sogar der einzig sinnvolle Weg, weil es schlicht keine umgebende Organisation gibt, an die irgendetwas delegiert werden könnte. Ich habe in Startups mitgearbeitet und diesen Geist des Zupackens erlebt. Genau diesen Spirit wünschen wir uns im Scrum Team, um zu einem Hochleistungsteam zu kommen.
Dabei ist, gemäß dem Manifest für Agile Softwareentwicklung, die Arbeit so zu gestalten, dass das Team die Arbeitslast nachhaltig und lange tragen kann. Hochleistung entsteht hier nicht aus einer Überlast und 60- bis 80-Stunden-Wochen, sondern aus einem ständigen Arbeiten im Flow (Csíkszentmihályi, 1995).
Scrum Master
Scrum Master sind dienende Führungskräfte im Sinne des Begriffes „Servant Leadership“ von Robert K. Greenleaf (Greenleaf, 1977). Ein Scrum Master verantwortet die Einführung von Scrum in Theorie und Praxis in der Organisation und im Scrum Team. Insbesondere ist der Scrum Master verantwortlich für die Effektivität des Scrum Teams. Ein starkes Werkzeug, um daran zu arbeiten, sind die regelmäßigen Sprint Retrospectives. Aber die genügen nicht. Ein exzellenter Scrum Master ist ständig an der Seite seines Teams und dient ihm in unterschiedlichen Rollen: als Moderator, Scrum-Lehrer, Mentor und Coach, Konfliktnavigator, Dirigent der Zusammenarbeit und natürlich auch als Change Agent in der Organisation, um Hindernisse aus dem Weg zu räumen.
Ein häufiges tradiertes Missverständnis ist, dass der Scrum Master sich selbst überflüssig machen soll. Das stimmt nur, wenn man die Verantwortung des Scrum Masters auf die eines Scrum-Lehrers schrumpfen lässt: Nach einiger Zeit haben die anderen Mitglieder des Scrum Teams gelernt, wie Scrum funktioniert, und dann kann der Scrum Master weiterziehen zum nächsten Team.
Die folgende Grafik zeigt, wie sich die tägliche Arbeitszeit des Scrum Masters beispielhaft auf die breit gefächerten Verantwortungen aufteilt. Mit der Zeit ändern sich die Schwerpunkte, aber der Scrum Master ist zu keinem Zeitpunkt überflüssig.
Abb. 2: Aufteilung der Arbeitszeit des Scrum Masters auf seine Aufgaben
Ein Scrum Master ist wie …
die Feuerwehr. Keine Gemeinde der Welt wartet, bis es brennt, um erst dann eine Feuerwehr zu gründen. Ebenso dient der Scrum Master in all seinen Rollen zu dem Zeitpunkt, zu dem es nötig ist. Denn eine Verzögerung in der Konfliktnavigation oder in der Beseitigung eines Hindernisses kann extrem teuer sein.
der Trainer einer Fußballmannschaft. Damit zusammen hängt die Frage, wie viele Scrum Teams ein Scrum Master betreuen kann. Die Antwort hängt davon ab, in welcher Liga die Mannschaft spielen soll. Eine Hobby-Mannschaft kann von einem Trainer trainiert werden, der auch noch mitspielt. Und vielleicht trainiert dieser Trainer noch andere Mannschaften. Im Gegensatz dazu möchte Bayern München die Champions League gewinnen und ein paar andere Pokale auch noch. Diese Mannschaft würde niemals akzeptieren, dass ihr Trainer gleichzeitig noch die Mannschaft von Real Madrid trainiert.
Wir schaffen für Scrum Teams eine Umgebung, damit sie Hochleistungsteams werden. Sie sollen für unser Unternehmen die Champions League gewinnen. Es liegt auf der Hand, dass wir dann ihren Trainer nicht wie den einer Hobby-Mannschaft aufstellen sollten. Ein geflügeltes Wort von Michael James (Certified Scrum Trainer aus Seattle) lautet: „Ein guter Scrum Master kann zwei Scrum Teams betreuen. Ein exzellenter Scrum Master nur eins.“
Nicht zuletzt ist der Scrum Master auch der Coach des Product Owners. So kann der Scrum Master mit Moderation und aufgrund seiner Erfahrung mit agilen Techniken dabei helfen, ein gutes Produkt-Ziel zu definieren und das Product Backlog immer im Griff zu behalten. Das ist genauso wichtig wie empirische Ansätze der Produktplanung und das Unterstützen einer effektiven Zusammenarbeit des Scrum Teams mit den verschiedenen Stakeholdern.
Auch der Dienst an der Organisation ist eine wichtige Aufgabe des Scrum Masters: Sie muss trainiert, gecoacht und geführt werden bei dem Versuch, Scrum effektiv zu nutzen. Mitarbeiter und Stakeholder müssen verstehen, wie sie mit empirischen Ansätzen die Arbeit des Scrum Teams in der komplexen Situation unterstützen können.
Developer
Developer haben in jedem Sprint ihren Fokus auf dem Erzeugen des nächsten nutzbringenden Increments des Produkts. Abhängig von Produkt und Zielmarkt brauchen sie als Team ein breites Wissen und alle Fähigkeiten, um das Produkt zu liefern. Die Developer sind verantwortlich:
1.für den Arbeitsplan im Sprint – das Sprint Backlog – und seine tägliche Ausrichtung auf das Sprint-Ziel hin,
2.für die Produktqualität und die Erstellung und das Einhalten der Definition of Done (Details dazu finden Sie in Kapitel 2.3),
3.dafür, sich gegenseitig bei der Ehre als Profis zu packen und ihr Bestes zu geben.
Product Owner
Der Product Owner maximiert den Wert des durch die Arbeit des Scrum Teams erzeugten Produktes. Damit er diese Verantwortung gut wahrnehmen kann, ist es wichtig, dass die gesamte Organisation seine Entscheidungen respektiert.
Der Product Owner ist eine einzelne Person, kein Komitee. Stakeholder nehmen über den Product Owner Einfluss auf das Produkt – müssen aber, wie gesagt, seine Entscheidungen respektieren.
Test: Hat Ihr Product Owner genug Entscheidungsfreiheit?
In der Praxis machen Organisationen häufig Fehler bei der Berufung der Product Owner. In vielen Fällen sind diese nur in engen Grenzen befugt, Entscheidungen zum Produkt zu fällen. Darunter leidet die Entscheidungsgeschwindigkeit und damit die Reaktionsfähigkeit im Markt. Marktführer setzen sich vom Rest der Mitbewerber durch ihre hohe Entscheidungsgeschwindigkeit ab. Ein wochenlanges Betteln um Zustimmung bei Stakeholdern bremst hingegen selbst den fähigsten Product Owner aus. Eine einfache kleine Testfrage lautet: „Darf Ihr Product Owner entscheiden, das Produkt vom Markt zu nehmen und die Entwicklung zu beenden?“
Wenn Sie diese ultimative Frage zum Produkt mit „Ja!“ beantworten, dann arbeitet ein echter Product Owner an Ihrem Produkt. Dadurch sind die Erfolgschancen signifikant höher.
Pulsuz fraqment bitdi.
