scrum erfolgreich anwenden · kennen, die scrum formal anwenden, aber bei denen sich der erfolg...

Scrum erfolgreich anwendenMethoden und Technikenleistungsstarker Teams

Lutz Müller

Dieses Buch wird verkauft unterhttp://leanpub.com/scrum-erfolgreich-anwenden

Diese Version wurde veröffentlicht am 2018-12-17

Dies ist ein Leanpub-Buch. Leanpub bietet Autoren undVerlagen, mit Hilfe von Lean-Publishing, neueMöglichkeiten des Publizierens. Lean Publishingbedeutet die wiederholte Veröffentlichung neuerBeta-Versionen eines eBooks unter der Zuhilfenahmeschlanker Werkzeuge. Das Feedback der Erstleser hilftdem Autor bei der Finalisierung und der anschließendenVermarktung des Buches. Lean Publishing unterstütztden Autor darin ein Buch zu schreiben, das auch gelesenwird.

© 2018 Lutz Müller

http://leanpub.com/scrum-erfolgreich-anwenden

http://leanpub.com/

http://leanpub.com/manifesto

Inhaltsverzeichnis

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Warum dieses Buch? . . . . . . . . . . . . . . . . . . . 3

Die Notwendigkeit einer neuen Arbeitsweise . . . 5Globalisierung . . . . . . . . . . . . . . . . . . . . . . 5Digitalisierung . . . . . . . . . . . . . . . . . . . . . . 6Disruption . . . . . . . . . . . . . . . . . . . . . . . . 6Flexibilität des Marktes . . . . . . . . . . . . . . . . 7Agilität . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Agile Werte und Prinzipien . . . . . . . . . . . . . . . 9Die vier Werte des Agilen Manifests . . . . . . . . 10Die Prinzipien hinter dem Agilen Manifest . . . . 13

DerWorkflow von Scrum - Rollen, Ereignisse undArtefakte . . . . . . . . . . . . . . . . . . . . . . . . . 20Woher kommt die Bezeichnung Scrum? . . . . . . 21Die Rollen in Scrum . . . . . . . . . . . . . . . . . . . 22Die Scrum-Ereignisse . . . . . . . . . . . . . . . . . . 27Die Artefakte in Scrum . . . . . . . . . . . . . . . . . 43Der Workflow . . . . . . . . . . . . . . . . . . . . . . 47Die Werte von Scrum . . . . . . . . . . . . . . . . . . 49

Wann und wie wendet man Scrum erfolgreich an? 52Wann macht der Einsatz von Scrum Sinn? . . . . . 52

INHALTSVERZEICHNIS

Erfolgsfaktoren für Scrum . . . . . . . . . . . . . . . 56

Weitere Themen . . . . . . . . . . . . . . . . . . . . . . 61

Vorlagen zum Buch . . . . . . . . . . . . . . . . . . . . 62

Dein Feedback zum Buch . . . . . . . . . . . . . . . . 63

Über den Autor . . . . . . . . . . . . . . . . . . . . . . . 64Meine Mission . . . . . . . . . . . . . . . . . . . . . . 65

Urheberrecht . . . . . . . . . . . . . . . . . . . . . . . . 66

EinleitungVermutlich bist du Softwareentwickler, Tester, Scrum Mas-ter, Business-Analyst oder Product Owner. Vielleicht ar-beitest du in der Produktentwicklung oder im Manage-ment einer Firma, die agil arbeiten möchte. Oder du hastvon Scrum gehört und willst wissen, wie du und deineKollegen Scrum erfolgreich anwenden können. Herzli-chen Glückwunsch! Genau für dich schreibe ich diesesBuch. Neben der Theorie zu Scrum (die man kennenmuss) zeigt dieses Buch Methoden und Techniken, dieein Scrum-Team einsetzen sollte, um Scrum erfolgreichanwenden zu können. Ich zeige anhand von Beispielenund Erfahrungsberichten, wie du den Einsatz von Scrumin deinem Umfeld verbessern kannst.

HinweisIn diesem Buch kommen auch Themen vor,die nicht zu Scrum gehören. Es werden u.a.viele Praktiken aus Extreme Programming1 vor-gestellt, die dir und deinem Umfeld helfen,agil zu arbeiten.

Das Buch ist noch nicht komplett fertiggestellt. Es be-findet sich noch in der Entwicklung. Du gehörst zu denearly adoptern, d.h. du kannst das Buch schon lesen bevores fertiggestellt ist. Ich würde mich freuen, wenn du mirregelmäßig Feedback an

1Extreme Programming https://bit.ly/2rRXTDa

Einleitung 2

[email protected] sendest, damit die-ses Buch zu deinem Buch wird und du Scrum erfolgreichanwenden kannst.

Warum dieses Buch?Ich bin der festen Überzeugung und habe selbst die Er-fahrung gemacht, dass der Einsatz von Scrum in einerkomplexen Produktentwicklung ein richtig guter Weg ist,um Produkte kundengerecht zu entwickeln. Scrum wirdsehr häufig im Bereich IT eingesetzt und erlangt auch inanderen Bereichen außerhalb der IT immer mehr Popu-larität.In meiner Arbeit als Scrum Master lerne ich viele Teamskennen, die Scrum formal anwenden, aber bei denensich der Erfolg nicht wirklich einstellt: Einzelne Scrum-Meetings sind für die Kollegen langweilig, unproduktivund bieten keinen wirklichen Mehrwert. Es gibt wenigZusammenarbeit und wenig Kommunikation der Team-mitglieder. Anforderungen werden nicht aus Kundenper-spektive betrachtet. Es gibt weder Visionen noch Ziele, andenen sich Teams orientieren können. Mit diesem Buchmöchte ich Anderen helfen, Scrum erfolgreich einzufüh-ren bzw. Korrekturen vornehmen, um Scrum erfolgreichanwenden zu können. Da Scrum lediglich ein Rahmen-werk ist, müssen Teams diesen Rahmen selbst ausfüllen.Die in diesem Buch vorgestellten Methoden und Tech-niken haben mir mit meinen Teams geholfen, bessereProdukte für unsere Kunden zu entwickeln. Ich möchtediese Methoden und Techniken sowie meine praktischenErfahrungen mit dir teilen, damit du und dein Team er-folgreich Produkte entwickeln könnt. Damit ihr direktloslegen könnt, habe ich auf der Webseite2 zum Buch allein diesem Buch erwähnten Vorlagen verlinkt, die du dir

2Webseite zum Buch https://bit.ly/2NWpbo1

Warum dieses Buch? 4

kostenlos herunterladen kannst und sofort mit deinemTeam benutzen kannst. Dazu gehören Spickzettel, Tipps& Tricks, Vorlagen und Beispiele.

Die Notwendigkeit einerneuen ArbeitsweiseEigentlich wollte ich das Buch nicht mit Buzz-Wörternwie Globalisierung, Digitalisierung, Disruption oder Agilitätbeginnen. Das hat leider nicht geklappt. Man kommt umdiese Begriffe nicht herum, wenn man die nötigen Verän-derungen in der Arbeitswelt und in der Arbeitsweise vonMenschen beschreiben möchte.

Globalisierung

Die Globalisierung stellt Unternehmen und Organisatio-nen vor die Herausforderung zusätzlich auch mit interna-tionalen Firmen um Marktanteile konkurrieren zu müs-sen. Gleichzeitig ergeben sich aber auch neue Möglich-keiten, die eigenen Produkte auf einem viel größerenMarkt anzubieten. Die Globalisierung steigert den Wett-bewerbsdruck und verkürzt Innovations-, Technologie-und Produktlebenszyklen. Die Welt ist komplexer gewor-den und Unternehmen und Organisationen müssen die-sen Veränderungen gerecht werden und Lösungen fin-den.

Die Notwendigkeit einer neuen Arbeitsweise 6

Digitalisierung

Viele Produkte und Dienstleistungen können digital undam besten noch mobil bereitgestellt werden. Die tech-nischen Möglichkeiten generieren neue Bedürfnisse, wiezum Beispiel 24 Stunden tagtäglich Bankgeschäfte zuerledigen. Es ist kaum noch vorstellbar, wie Menschenfrüher ihre Überweisungen und Geldabhebungen aus-schließlich am Schalter der Bank erledigt haben. Um dieBedürfnisse der Kunden zu verstehen, braucht es Formenvon Arbeitsweisen, die schnelle Entscheidungen und kun-denorientiertes Denken und Handeln unterstützen.

Disruption

Disruptive Technologien sind Innovationen, die die Er-folgsserie einer bereits bestehenden Technologie, einesbestehenden Produkts oder einer bestehenden Dienst-leistung ersetzen oder diese vollständig vom Markt ver-drängen. Zu Beginn sind diese Technologien meist inneuen Märkten und am unteren Ende eines Markteszu finden. Diese neuen Märkte können im Verlauf einstarkes Wachstum aufweisen und bestehende Märkteund Produkte teilweise bzw. vollständig verdrängen. Neh-men wir das Beispiel Digitalkameras: Anfangs konntenDigitalkameras qualitativ nicht überzeugen. Die geringeAuflösung zu Beginn der Entwicklung stellte einen großenNachteil gegenüber der klassischen Fotografie dar. Inzwi-schen konnte die Bildqualität soweit verbessert werden,dass Digitalkameras analoge Kameras nahezu verdrängthaben.


Flexibilität des Marktes

Richard Foster und Sarah Kaplan beschreiben in ihremBuch Creative Destruction: Why Companies That Are Builtto Last Underperform the Market-And How to Success fullyTransform Them: Why Companies That Are Built How to Suc-cess fully Transform Them die verkürzte Lebensdauer vongroßen Unternehmen bedingt durch immer schnelleren,technologischen Fortschritt.

In der Zeit ab Anfang der 1990er bis Mitte der 2010er Jah-re war Nokia als weltweit bedeutender Mobiltelefonher-steller bekannt. Nahezu Jeder aus meinem Bekannten-und Freundeskreis wollte ein Nokia-Handy haben. Es wardamals kaum vorstellbar, dass diese Branche sich soschnell wandeln könnte.Lange wehrte sich Nokia gegen das iPhone-Konzept derTouchdisplays und der intuitiven Benutzerführung. Appleund Co. trieben die Revolution auf dem Smartphone-Markt voran, während Nokia weiterhin Handys mit Tasta-tur produzierte. Zu lange hatte Nokia die Strahlkraft dereigenen Marke überschätzt. Als der Konzern bereits inder Smartphone-Sparte abgehängt wurde, glaubte man,den Rückstand schnell wieder aufholen zu können.

Grundsätzlich sind falsche Einschätzungen eines Marktesnicht das größte Problem. Unternehmen, die schnell undflexibel auf Marktänderungen reagieren können, habeneinen entscheidenden Vorteil und können fehlerhafteAnnahmen besser kompensieren. Starre Unternehmens-strukturen und Silo-Denken verhindern Flexibilität. Star-ke hierarchische Strukturen und eineCommand&Control-Mentalität bremsen Mitarbeiter und Unternehmen aus.

Die vorgenannten Tatsachen können wir nicht ändern.


Wir können jedoch darauf reagieren und unsere Arbeits-weisen und Unternehmen anpassen.

Agilität

Die vorgenannten Gegebenheiten sind Treiber der Agili-tät. Damit Unternehmen mit diesen Herausforderungenumgehen können und weiterhin am Markt bestehen kön-nen, müssen sie agil handeln. Agilität (und Scrum als eineAusgestaltungsmöglichkeit davon) unterstützt Unterneh-men und Organisationen sich so zu entwickeln, um denAnforderungen an sich ändernde Märkte und Wünscheder Kunden gerecht zu werden.

Agile Werte undPrinzipienWer kennt das nicht? Um Aufgaben zu erledigen, mussman in vielen Unternehmen formale, aufwändige Pro-zesse einhalten, Genehmigungen einholen und umständ-liche Tools bedienen. Zusätzlich muss man Tätigkeitenund Ergebnisse in umfassenden Dokumentationen fest-gehalten. Bevor man jedoch mit dem Kunden zusam-menarbeitet, werden komplizierte Verträge geschlossen,die womöglich auch noch umfassende Vertragsstrafenenthalten. Ist dann einmal ein Plan gemacht, so wirddieser Plan durchgezogen auch wenn das an der einenoder anderen Stelle nunmehr wenig Sinn macht, da sichdie Umstände geändert haben. Kommt dir das bekanntvor? So will doch niemand arbeiten!

Glücklicherweise haben sich im Jahr 2001 im Februar17 ITler in Utah getroffen. Währen des Treffens wurdeeine Alternative zu schwerfälligen, dokumentationslasti-gen Softwareentwicklungsprozessen formuliert, das Agile‘Software Development’ Manifesto3. Dass das Manifest soweitreichende Veränderungen mit sich bringen würde,konnte vermutlich damals niemand ahnen. Es hat aufjeden Fall die Arbeitsweise und das Vorgehen in vielenIT-Projekten nachhaltig verändert. Immer häufiger findetdas Agile Manifest auch in Bereichen außerhalb der ITAnwendung.

3Agiles Manifest https://bit.ly/2GvWXsO

Agile Werte und Prinzipien 10

Scrum selbst beruht auf den agilen Werten und Prinzipi-en.

Die vier Werte des Agilen Manifests

Die Werte sind wie folgt beschrieben:

Wir erschließen bessere Wege, Software zu ent-wickeln, indem wir es selbst tun und anderendabei helfen. Durch diese Tätigkeit haben wirdiese Werte zu schätzen gelernt:

1. Individuen und Interaktionen mehr alsProzesse und Werkzeuge

2. Funktionierende Software mehr als um-fassende Dokumentation

3. Zusammenarbeit mit demKunden mehrals Vertragsverhandlung

4. Reagieren auf Veränderung mehr als dasBefolgen eines Plans

Es ist mir an dieser Stelle noch mal wichtig zu betonen,dass die Werte auf der rechten Seite weder falsch nochschlecht sind. Sie haben natürlich ihre Berechtigung. Aberdie Werte auf der linken Seite sind wichtiger.

Individuen und Interaktionen

Kennst du die Szene aus Asterix erobert Rom, wo Asterixund Obelix den Passierscheins A 38 aus der Präfektur, dem„Haus, das Verrückte macht“ besorgen müssen? So oderso ähnlich hat das vermutlich jeder von uns schon mal


erlebt, wenn man Aufgaben in Unternehmen erledigenmuss.Mit Individuen und Interaktionen mehr als Prozesse undWerkzeuge ist gemeint, dass Menschen, ihr Umgang mit-einander, ihre Kommunikation und ihre Zusammenarbeiteinen größeren Einfluss auf den Projekterfolg haben alsdie festgelegten Prozesse bzw. Werkzeuge. Man möchtedie Wichtigkeit der Menschen, die im Projekt arbeiten,hervorheben. Im Gegensatz dazu steht in klassischenVorgehensweisen der Prozess mit eng gefassten Hand-lungsspielräumen im Vordergrund.

Funktionierende Software

Scrum wird zur Entwicklung komplexer Produkte ange-wendet. Eine vollständige Dokumentation (Anforderun-gen und Konzeption) komplexer Produkte vor der Umset-zung ist nahezu unmöglich. Sowohl auf der technischenSeite als auch auf der Seite der Kundenwünsche sindviele Dinge zu Beginn unklar. Daher würde eine umfas-sende Dokumentation zu Projektbeginn so lange dau-ern, dass unter Umständen viele der Anforderungen beiBeginn der Realisierung schon wieder überholt wären.Deswegen ist das Ziel, sich auf funktionierende Softwarezu fokussieren und das komplexe Produkt empirisch zuentwickeln. Das heißt jedoch nicht, dass es gar keineDokumentation gibt.

Wir arbeiten agil und brauchen daher keineQuell code-Kom men ta re!

Alle Softwareentwickler, die jetzt denken sie müssen ih-ren Quellcode nicht mehr dokumentieren, liegen leiderfalsch. Gerade wenn man bedenkt, dass neue Entwickler


zum Team dazustoßen oder Projekte an andere Teamsübergeben werden, ist es durchaus sinnvoll Quellcodemit Kommentaren zu versehen. Im agilen Manifest stehtnirgends, dass man nicht mehr Quellcode kommentierenmuss!

Zusammenarbeit mit dem Kunden

Stell dir doch bitte folgende Situation vor: Ein Kundeund ein Auftragnehmer haben sich darauf verständigt,zusammenarbeiten zu wollen. Der Kunde möchte einProdukt entwickelt haben ist davon überzeugt, mit demAuftragnehmer einen kompetenten Partner zur Umset-zung gefunden zu haben. Der Auftragnehmer stellt seineExpertise zur Verfügung und möchte mit dem AuftragGeld verdienen. Soweit so gut.Sehr häufig passiert nun Folgendes: Noch bevor die Zu-sammenarbeit beginnt, wird ein komplexes Vertragskon-strukt inklusive Vertragsstrafen aufgesetzt. Das wirkt dochein wenig schizophren, oder? Auf der einen Seite möchteman zusammenarbeiten, auf der anderen Seite geht manvor der Zusammenarbeit vom Scheitern aus und legt dieStrafen für beide Seiten fest.Natürlich braucht es einen Vertrag zwischen Auftragge-ber und Auftragnehmer. Statt sich aber auch komplexeVertragskonstrukte zu fokussieren, zielt Zusammenarbeitmit dem Kunden mehr als Vertragsverhandlung darauf ab,dass der Kunde in die Zusammenarbeit eingebundenist (also auch Verantwortung übernimmt) und nicht nurseine Anforderungen “über den Zaun wirft”.


Reagieren auf Veränderung

Softwareprojekte und Projekte zur Produktentwicklungim Allgemeinem umspannen in der Regel große Zeiträu-me. Während der Entwicklung können sich viele Annah-men, die zu Projektbeginn ihre Gültigkeit hatte, schnellobsolet werden. Das Ziel von agilem Arbeiten (und damitauch Scrum) ist es, auf diese Veränderungen einzugehenund diese zu berücksichtigen. Gerade in der Kunden-Auftraggeber-Beziehung ist das ein wichtiger Aspekt. DieZusammenarbeit zwischen beiden Parteien sollte so er-folgen, dass man zu Projektbeginn bereits das Verständ-nis hat, dass Veränderungen sehr wahrscheinlich werdenund so der Plan relativ häufig angepasst werden muss.Deshalb macht es auch keinen Sinn einen detailliertenPlan für deinen langen Zeitraum aufzustellen, da Vieles,was zu Beginn unbekannt ist, sich erst nach und nachdurch Erfahrungen herauskristallisiert. Trotzdem gibt esauch beim agilen Arbeiten Planungstätigkeiten. Ein Planim agilen Kontext hilft allen Beteiligten ein Bild davon zuhaben, in welche Richtung man gehen möchte.

Die Prinzipien hinter dem AgilenManifest

Folgende 12 Prinzipien unterstützen die agile Software-entwicklung:


1. Unsere höchste Priorität ist es, denKunden durch frühe und kontinuierlicheAuslieferung wertvoller Software zufriedenzu stellen.

In diesem Prinzip stecken drei wichtige Aussagen: Ers-tens möchte man Software frühzeitig ausliefern, d.h. wirwarten mit der Auslieferung nicht bis alle Features fer-tiggestellt sind, sondern liefern ein erlebbares Produktmit einigen Features aus. Der zweite Aspekt des Prin-zips ist die kontinuierliche Auslieferung neuer Entwick-lungsstufen des Produktes. Dadurch bekommt man auchkontinuierlich Feedback vom Kunden und kann dieses inder nächsten Iteration berücksichtigen. Der dritte Aspektbezieht sich auf das Ausliefern wertvoller Software bzw.Produkte: Damit ist gemeint, dass eine neue Stufe desProduktes einen Nutzen bzw. einen Wert für den Kundenhat. Das Ausliefern von halbfertigen Features ist damitnicht gemeint.

2. Heiße Anforderungsänderungen selbstspät in der Entwicklung willkommen. AgileProzesse nutzen Veränderungen zumWettbewerbsvorteil des Kunden.

Während eines Projektes ist es sehr wahrscheinlich, dasssich Anforderungen ändern, gerade in komplexen Pro-jektumfeldern. Statt zu Beginn des Projektes alle Anfor-derungen feststellen zu wollen und dann umzusetzen,sollten Auftragnehmer und Kunde das Bewusstsein undVerständnis haben, dass man auf gewisse Änderungen(z.B. aus rechtlichen, marktbezogenen oder technischenGründen) eingeht und sich somit einen Wettbewerbsvor-


teil schafft.

3. Liefere funktionierende Softwareregelmäßig innerhalb weniger Wochen oderMonate und bevorzuge dabei die kürzereZeitspanne.

In klassischen Softwareentwicklungsprozessen wird zu-nächst geplant, entwickelt und erst am Ende wird das Pro-dukt ausgeliefert. Unter Umständen entsteht dann eingroßer Integrationsaufwand mit häufigen Fehlern undNachbesserungsarbeiten. Um das zu verhindern soll re-gelmäßig integriert und ausgeliefert werden. Die Auslie-ferung des Produktes muss “langweilig” werden, es sollalso keine große Sache mehr sein.

4. Fachexperten und Entwickler müssenwährend des Projektes täglichzusammenarbeiten.

Grundsätzlich ist es von großen Nutzen, wenn Businessund Entwicklung näher zusammenrücken. Dabei müs-sen beide Gruppen Verständnis füreinander aufbringenund versuchen, die andere Seite zu verstehen. Wenndas gelingt, entstehen wertvolle Produkte mit technischerExzellenz und hohem Nutzen für den Kunden.


5. Errichte Projekte rund ummotivierteIndividuen. Gib ihnen das Umfeld und dieUnterstützung, die sie benötigen undvertraue darauf, dass sie die Aufgabeerledigen.

Softwareentwicklung und Produktentwicklung sind ge-prägt von Inspiration und Kreativität. Um kreative Arbeitbestmöglich umzusetzen, benötigen Menschen Raum undMöglichkeiten kreative Lösungen zu erarbeiten. Dazu ge-hören unter anderem offene Kommunikation, eine ge-sunde Fehlerkultur, Verantwortung, Vertrauen sowie dieZweckmäßigkeit (Sinnhaftigkeit) von Aufgaben.

6. Die effizienteste und effektivsteMethode, Informationen an und innerhalbeines Entwicklungsteams zu übermitteln,ist im Gespräch von Angesicht zu Angesicht.

Das Prinzip klingt einleuchtend. Trotzdem passiert esimmer wieder, dass schnell zur E-Mail gegriffen wird,obwohl man die Kollegen auch direkt sprechen könnte.Aber was genau ist das Problem?1. Zeit: Bei vielen Dingen dauert es insgesamt viel längerdie E-Mail zu schreiben (Sender) und die E-Mail zu lesen(Empfänger). Im direkten Gespräch kann man die Infor-mationen viel schneller verteilen.2. Sender vs. Empfänger: Sehr oft passiert es, dass dieIntention des Senders beim Empfänger nicht genausoankommt, wie gewünscht. Bei einer Textkommunikationfehlt einfach die verbale Ebene, die den Inhalt in einenbestimmten Kontext setzt. Gerade in der Kommunika-tion von Menschen ist das ein sehr wichtiger Faktor.


Außerdem erkennt man an Mimik und Gestik, ob derGesprächspartner mich verstanden hat.

7. Funktionierende Software ist daswichtigste Fortschrittsmaß.

Nicht mit Konzepten, Designs oder Projektdokumentati-on verdient ein Unternehmen Geld, sondern mit einemlauffähigen Produkt bzw. einer funktionierenden Soft-ware. Ein lauffähiges Produkt kann ich am Markt testenund Feedback einholen. Das geht mit Konzepten bzw.Projektdokumentationen nicht.

8. Agile Prozesse fördern nachhaltigeEntwicklung. Die Auftraggeber, Entwicklerund Benutzer sollten ein gleichmäßigesTempo auf unbegrenzte Zeit halten können.

Eine Iteration in Scrum nennt man Sprint. Ein Sprint ansich ein Kurzstreckenlauf, bei dem man alle Kraft ein-setzt. Nach einem Sprint ist man erst mal erschöpft.Die Begriffe aus Scrum kommen aus dem Englischen.Leider geht an der einen oder anderen Stelle manchmalbei der Übersetzung die Intension verloren. Das gera-de beschriebene Szenario ist mit “Sprint” genau nichtgemeint. Besser wäre es, “Sprint” mit “kurze Iteration”zu übersetzen. Es geht nicht darum, dass Scrum-TeamsÜberstunden machen, sondern, dass es sich auf einekurze Iteration konzentriert. Das Scrum-Team muss alsofür sich eine nachhaltige Geschwindigkeit finden, sodasses dieses Tempo unbegrenzt halten kann.


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

Agilität bedeutet nicht, dass man Lösungen, Architektu-ren und Produkte “quick & dirty” erstellt. Architekturenund Lösungen müssen gewisse technische und design-spezifische Gegebenheiten haben (z.B. Änderbarkeit, Ein-fachheit), damit man agil arbeiten kann. Dazu gehörenauch Lösungen, die Gruppenarbeit und Zusammenarbeitan einem Produkt oder Teilen von Produkten möglich ma-chen. Gerade in der Softwareentwicklung müssen meh-rere Entwickler an der gleichen Codebasis gleichzeitigarbeiten können.

10. Einfachheit – die Kunst, die Menge nichtgetaner Arbeit zu maximieren – istessenziell.

Alles was nicht dem Zweck dient ist Verschwendung.Agiles Arbeiten bedeutet Verschwendung zu vermeiden.Gerade wenn in Unternehmen Scrum mit all seinen Mee-tings eingeführt wird, beschweren sich viele Mitarbeiterüber die vielen zusätzlichen Termine durch Scrum. Ge-nau das ist das Problem: Die Termine von Scrum wer-den zusätzlich durchgeführt. Vielmehr sollte man daraufschauen, ob die bisherigen Meetings wirklich noch nö-tig sind. Braucht man die bisherigen Status-Meetings,Abstimmungs-Termine und Gruppen-Meetings noch? Ver-mutlich nicht.


11. Die besten Architekturen,Anforderungen und Entwürfe entstehendurch selbstorganisierte Teams.

Der Grundgedanke hinter diesem Prinzip ist, dass manden Teams und Mitarbeitern ein Ziel vorgibt und ihnendie Freiheit lässt, das Ziel auf eigenem Wege zu erreichen.Der Prozess der dann einsetzt heißt Selbstorganisation.Dabei bringt sich sich jeder nach seinen Möglichkeitenein, um gemeinsam das Ziel zu erreichen. Es entwickeltsich eine Organisation, deren Sinn darin besteht, das Zielzu erreichen.

12. In regelmäßigen Abständen reflektiertdas Team, wie es effektiver werden kannund passt sein Verhalten entsprechend an.

Während in klassischen Projektumfeldern maximal amEnde eines Projektes eine Art “Lessons learned” durch-geführt wurde, ist das Ziel bei agilem Arbeiten, dass dasTeam bzw. die Organisation regelmäßig prüft, wie maneffektiver werden kann. Ganz wichtig ist der zweite Teildes Prinzips: Die Anpassung des Verhaltens. Dazu gehörtauch, dass Menschen die Art und Weise, wie sie arbeiten,ändern.

Der Workflow von Scrum- Rollen, Ereignisse undArtefakteLaut dem Scrum Guide4 ist Scrum ein Rahmenwerk, in-nerhalb dessen Menschen komplexe adaptive Aufgaben-stellungen angehen können und durch das sie in dieLage versetzt werden, produktiv und kreativ Produkte mithöchstmöglichem Wert auszuliefern.

Scrum ist:

• Leichtgewichtig• Einfach zu verstehen• Schwierig zu meistern

HinweisScrum ist keine Methode, kein Prozess undkeine Vorgehensweise! Es ist ein Rahmen-werk!

In vielen (Web)-Publikationen wird Scrum als Prozess,Methode oder Vorgehensweise beschrieben. Das ist je-doch nicht richtig. Scrum ist ein Rahmenwerk, das durchRahmenbedingungen gegeben ist. Die Ausgestaltung die-ses Rahmens bestimmt das Team selbst. Scrum gibt den

4Scrum Guide https://bit.ly/2IwJpPj

Der Workflow von Scrum - Rollen, Ereignisse und Artefakte 21

Entwicklungsprozess nicht vor, d.h. das Team entscheidetselbst, wie es von einer Idee zu einem auslieferbarenProdukt kommt. Genau das macht es schwierig Scrumerfolgreich anzuwenden. Glücklicherweise hast du diesesBuch in der Hand! Es wird dir helfen bewährte Methodenund Techniken kennenzulernen, die nötig sind, um Scrumzu meistern.

Woher kommt die BezeichnungScrum?

Der Begriff Scrum bezeichnet im Rugby-Sport einen be-stimmten Spielzug, bei dem die Spieler dicht aneinan-dergedrängt auf dem Spielfeld stehen. Was hat nun dieRauferei um den Ball mit dem Framework Scrum zu tun?Nach dem Ende des zweiten Weltkriegs wurde in Japandas Lean Management entwickelt, mit dem Ziel der Ver-meidung unproduktiver Tätigkeiten. Als prägendes Werkgilt in diesem Zusammenhang eine Veröffentlichung vonHirotaka Takeuchi und Ikujiro Nonaka im Harvard Busi-ness Review aus dem Jahre 1986 mit dem Titel The NewNew Product Development Game5. Die im Artikel vorge-stellten Vorgehensweisen nannten die Autoren “Rugby-Approach”:

In today’s fast-paced, fiercely competitive worldof commercial new product development, speedand flexibility are essential. Companies are in-creasingly realizing that the old, sequential ap-proach to developing new products simply won’tget the job done. Instead, companies in Japan

5The New New Product Development Game https://bit.ly/2GURhIQ


and the United States are using a holistic me-thod - as in rugby, the ball gets passed withinthe team as it moves as a unit up the field.

Zirka zehn Jahre später entwickelten Jeff Sutherland undKen Schwaber den Rugby-Approach zu einem Rahmen-werk für Softwareentwicklungs-Projekte weiter und be-nannten es in Scrum um:

We call the approach the SCRUM methodolo-gy (see Takeuchi and Nonaka, 1986), after theSCRUM in rugby – a tight formation of forwardswho bind together in specific positions when ascrumdown is called.

Die Rollen in Scrum

Ein Scrum-Team besteht aus dem Product Owner, demEntwicklungsteamund dem ScrumMaster. Das Scrum-Teamarbeitet selbstorganisiert, d.h. das Team entscheidet selbst,wie es die Arbeit am besten erledigt. Scrum-Teams sindinterdisziplinär (oder auch cross-funktional) aufgestellt,d.h. in dem Team sind alle Kompetenzen und Fähigkei-ten vorhanden, um die Arbeit zu erledigen, ohne dabeiabhängig von Personen zu sein, die nicht im Team sind.

HinweisAlle Mitglieder des Scrum-Teams sind gleich-berechtigt und arbeiten auf Augenhöhe. Alledrei Rollen sind hierarchisch auf derselbenEbene.


Der Product Owner

Die Aufgabe und Verantwortung des Product Owners(PO) liegt in der Maximierung des Wertes des Produktes.Er trägt die Hauptverantwortung für den geschäftlichenErfolg des Produktes. Der Product Owner ist eine einzelnePerson, keine Gruppe von Personen. Der Product Ownermanagt das Product-Backlog. Dazu gehören:

• die Formulierung der Einträge im Product-Backlog,• die Sortierung der Einträge im Product-Backlog,• die Transparenz des Product-Backlogs sicherzustel-

len und• die Sicherstellung, dass das Entwicklungsteam die

Einträge im Product-Backlog versteht.

HinweisDer Product Owner kann die oben genanntenTätigkeiten selbst durchführen oder das Ent-wicklungsteam damit beauftragen. Es ist einweit verbreiteter Mythos, dass der ProductOwner allein die Pflege des Product-Backlogsübernehmen muss. Er bleibt jedoch rechen-schaftspflichtig für das Product-Backlog.

Damit ein Product Owner erfolgreich arbeiten kann, musser ermächtigt sein, Entscheidungen zu treffen. Dazu be-nötigt er das Vertrauen des Unternehmens.

Das Entwicklungsteam

Das Entwicklungsteam besteht aus Profis, deren Aufgabedarin besteht, am Ende eines Sprints ein fertiges, potenti-


ell auslieferbares Produkt-Inkrement bereitzustellen. DasEntwicklungsteam muss also alle Aufgaben erledigen, dienötig sind, um die nächste Stufe des Produktes zu entwi-ckeln.

HinweisDas Entwicklungsteam hat eher die Bedeu-tung eines “Produkt-Entwicklungsteam”. DieMitglieder des Entwicklungsteams sollten sichals Produktentwickler verstehen. Dazu gehörtauch, dass man unter Umständen Aufgabenübernimmt, die nicht zu den eigenen Kern-kompetenzen gehören.

Das Entwicklungsteam zeichnet sich durch folgende Merk-male aus:

• Es arbeitet selbstorganisiert, d.h. es entscheidet selbst,wie es die Funktionalität für das Produkt umsetzt.

• Es ist interdisziplinär: Alle Fähigkeiten, die für dieEntwicklung des Produkt-Inkrements gebraucht wer-den, sind im Team vereint.

• Es hat mindestens drei und maximal neun Mitglie-der.

Auch wenn der Scrum Guide das nicht vorgibt, empfehleich Unternehmen die Teams so zusammenzustellen, dassein Mitarbeiter nur genau zu einem Scrum-Team gehörtund seine gesamte Arbeitszeit in diesem Scrum-Teamarbeitet. Es macht keinen Sinn zu 30% in einem Team undzu 70% in einem anderen Team zu arbeiten.


Der Scrum Master

Der Scrum Master ist hauptverantwortlich für die Umset-zung von Scrum. Dabei unterstützt er sowohl das Scrum-Team als auch Personen, die nicht im Scrum-Team sind.Er hilft allen Beteiligten die Scrum-Theorie sowie Prakti-ken, Regeln und Werte zu verstehen. Der Scrum Masterist ein Servant Leader, d.h. er fördert Scrum und die nöti-gen Veränderungen, um Scrum erfolgreich anwenden zukönnen, d.h. aber nicht, dass er den Beteiligten sagt, waszu tun ist. Vielmehr hinterfragt er Dinge, teilt Beobachtun-gen und zeigt Probleme auf. Er ist Moderator und Coach.Er beseitigt Hindernisse und stellt sicher, dass das Teameffektiv arbeiten kann.Zu den Aufgaben gehören unter anderem:

1. Unterstützung des Entwicklungsteams:

• Coaching des Teams zu Selbstorganisation und in-terdisziplinärem Arbeiten

• Beseitigung von Hindernissen• Durchführung der Scrum-Ereignisse

2. Unterstützung des Product Owners:

• Vermittlung von Methoden und Techniken für dieErstellung und Pflege des Product Backlogs

• Vermittlung von Methoden und Techniken für dieProduktplanung im empirischen Umfeld

• Schaffung eines Verständnisses von Agilität und de-ren Anwendung

3. Unterstützung der Organisation:


• Schulen und Coaching bei der Einführung von Scrum• Schaffung eines Verständnisses für die empirische

Produktentwicklung bei Kollegen und Mitarbeiternaußerhalb des Scrum-Teams

• Vorantreiben von Veränderungen, um Produkte bes-ser und schneller an den Markt zu bringen

• Zusammenarbeit mit anderen Scrum Mastern umdie Entwicklung der Organisation gemeinsam voran-zutreiben

Wie spielen diese drei Rollen miteinander?

Zusammenspiel der Rollen


Die Scrum-Ereignisse

Scrum enthält vorgegebene Ereignisse (Meetings), die füreine gewisse Regelmäßigkeit sorgen sollen. Dabei sollenEreignisse und Meetings, die nicht in Scrum definiertsind, möglichst minimiert werden oder bestenfalls entfal-len und durch die Scrum-Ereignisse ersetzt werden. DieScrum-Ereignisse sind time-boxed, d.h. sie haben eine ma-ximale Dauer. Wenn das Ziel des Meetings vor Ende dermaximalen Dauer erreicht wurde, dann kann das Meetingfrüher beendet werden, mit einer Ausnahme: Die Dauerdes Sprints ist festgelegt und wird weder verkürzt nochverlängert.

Der Sprint

Der Sprint ist ein Zeitraum von maximal einem Monat,in dem ein nutzbares, potentiell auslieferbares Produkt-Inkrement entwickelt werden soll. Es sind auch Zeiträumevon einer, zwei oder drei Wochen denkbar. Die Zeiträumefür die übrigen Ereignisse werden dann entsprechend an-gepasst. Die Sprintdauer wird einmalig festgelegt und istinnerhalb eins Entwicklungsvorhabens konstant. Direktnach dem Ende eines Sprints beginnt der nächste Sprint.Es gibt keine “Lücken”. Innerhalb eines Sprints findendie übrigen Scrum-Ereignisse Sprint Planning, Daily Scrum,Sprint Review und Sprint Retrospektive statt.Grundsätzlich sollten im Sprint keine Änderungen vor-genommen werden, die das Sprint-Ziel gefährden. Auchwenn gegen Ende des Sprints ersichtlich ist, dass mandas Sprint-Ziel nicht erreicht, sollten die Ansprüche andie Qualität nicht gemindert werden, nur um das Sprint-Ziel zu erreichen. Ergeben sich während des Sprints neue


Erkenntnisse, kann der Umfang der Anforderungen zwi-schen Product Owner und Entwicklungsteam geklärt undneu verhandelt werden.

Wann macht es Sinn die Sprintlänge zu ändern?

Nach der reinen Lehre ist die Sprintlänge immer gleich.Es gibt jedoch Ausnahmen, bei denen es Sinn macht, dieSprintlänge zu ändern:1. Lange UrlaubsperiodenGerade zu Weihnachten passiert es oft, dass das Sprin-tende und der Sprintbeginn in den Zeitraum zwischenWeihnachten und Neujahr fallen. Statt dogmatisch dar-auf zu bestehen, dass der Sprint dann enden muss, hates sich als praktisch erwiesen, die Länge des Sprints zuvergrößern und den Sprintwechsel (Sprintende/Sprintbe-ginn) auf die Zeit nach Neujahr zu verlegen. Gerade beieiner Sprintlänge von zwei Wochen empfiehlt es sich dieSprintlänge zu Weihnachten zu verdoppeln. Dann bleibtman im gleichen Rhythmus und hat nur einen Sprint-wechsel weniger.2. Wichtiger MeilensteinManchmal kann es Sinn machen einen Sprint um eineWoche zu verlängern, wenn ein wichtiger Meilenstein(z.B. eine Messe oder Produkt-Release) ansteht. Dann istes oft sinnvoller diese eine Woche gleich mit zu planenund einmalig einen längeren Sprint zu haben.

Ich persönlich bin kein Freund davon die Sprintlänge zuändern. Es gibt aber durchaus Situationen, in denen eineeinmalige Änderung der Sprintlänge Sinn macht. Geradebei erfahrenen Scrum-Teams stellt das in der Regel keinProblem dar. Wenn die Länge aber ständig geändert wird,sollte man hellhörig werden und die Ursache beleuchten.

Damit sich ein Scrum-Team weiterentwickeln kann, ist eswichtig auf Daten und Informationen aus der Vergangen-


heit zurückschauen zu können. Als Scrum Master erstelleich nach jedem Sprint eine Sprintübersicht für das Scrum-Team. Dabei wende ich nicht mehr als 15 Minuten zurErstellung auf.

Achtung!Die Sprintübersicht ist ausschließlich fürdas Scrum-Team vorgesehen und nicht alsReporting-Vorlage für das Management!

Die Vorlage und ein Beispiel zur Sprintübersicht findest duunter Vorlagen auf der Webseite zum Buch:https://www.scrum-erfolgreich-anwenden.de/vorlagen/

Das Sprint Planning

Ein Sprint beginnt mit dem Sprint Planning. Dabei wirddie Arbeit für den kommenden Sprint geplant. Am SprintPlanning nimmt das gesamte Scrum-Team teil. Für eineneinmonatigen Sprint beträgt die Dauer des Meetings ma-ximal acht Stunden. Wenn das Ziel des Meetings frühererreicht wurde, kann das Meeting auch früher beendetwerden.

Im Sprint Planning werden zwei Fragen beantwortet:1.WAS ist im Produkt-Inkrement für den Sprint enthalten?2. WIE wird die für die Lieferung des Produkt-Inkrementsnötige Arbeit erledigt?

Was ist im Produkt-Inkrement für den Sprintenthalten?

Im ersten Teil des Sprint Plannings stellt der Product Ow-ner die Product-Backlog-Einträge für den kommenden


Sprint vor. Das Entwicklungsteam stellt Fragen zu deneinzelnen Einträgen, sodass es versteht, WAS entwickeltwerden soll. Danach wählt das Entwicklungsteam ausden vorgestellten Product-Backlog-Einträgen so viele aus,wie es glaubt in dem Sprint zu schaffen. Dabei sollte dieLeistung aus den vergangenen Sprints sowie die Kapa-zität des Teams des kommenden Sprints berücksichtigtwerden.Die ausgewählten Product-Backlog-Einträge stellen dasSprint Backlog dar. Zum Schluss formuliert das Scrum-Team das Sprint-Ziel für den kommenden Sprint. DasSprint-Ziel leitet das Entwicklungsteam während des Sprintsund verdeutlicht, warum es das Produkt-Inkrement er-stellt.

Wie wird die für die Lieferung desProdukt-Inkrements nötige Arbeit erledigt?

Im zweiten Teil des Sprint Plannings erstellt das Entwick-lungsteam einen Plan, wie es die ausgewählten Product-Backlog-Einträge in den Zustand Done bringen kann, al-so fertigstellen kann. Die Art und Weise ist dabei nichtvorgegeben. In vielen Teams kommen Softwaretools wiez.B. Jira zum Einsatz. Ich selbst sehe solche Tools kritisch,denn oft passiert es, dass das Team sich dann von denVorgaben des Tools leiten lässt und lediglich Tasks (klei-nere Einheiten des jeweiligen Product-Backlog-Eintrags)erfassen. Allzu oft liegt in vielen Teams der Fokus imzweiten Teils des Sprint Plannings auf der Erstellung derTasks. Genau das sollte man vermeiden. Der zweite Teildes Sprint Plannings sollte den Charakter eines Work-shops haben. Dabei skizziert das Entwicklungsteam fürdie Product-Backlog-Einträge Lösungsstrategien. Ich star-te mit meinen Teams mit einem leeren Flipchart proProduct-Backlog-Eintrag. Dann wird zusammen eine Lö-


sung unter Berücksichtigung von Architektur, Design undden Vorgaben aus dem Product-Backlog-Eintrag erstellt.Zusätzlich kann man kann Dinge, die noch ungeklärt sind,mit einer Warnfarbe kennzeichnen. Eine solche Lösungs-strategie kann zum Beispiel so aussehen:

Lösungsstrategie einer User Story

Anschließend kann man dann einzelne Tasks von der Lö-sungsstrategie ableiten und im Sprint-Backlog eintragen.Dabei sollte man die Richtlinie berücksichtigen, dass einTask möglichst immer innerhalb eines Tages abgearbei-tet werden kann.Diese Art und Weise der Durchführung des zweiten Teilsdes Sprint Plannings hat mehrere Vorteile:

• Es entsteht ein zusammenhängender Plan für dieLösung

• Der zweite Teil des Sprint Plannings ist interaktiver


als reines Task-Schreiben• Ein Bild sagt mehr als 1000 Wörter: Visuelle Elemen-

te verstärken ein gemeinsames Bild der Lösung• Höheres Engagement aller Teammitglieder

Nach dem zweiten Teil des Sprint Plannings hat das Ent-wicklungsteam die Arbeit für die ersten Tage des Sprintsin kleinere Einheiten heruntergebrochen. Es ist durchausmöglich, dass man während des Sprints weitere Product-Backlog-Einträge herunterbrechen muss. Wichtig ist nur,dass nach dem zweiten Teil des Sprint Plannings füralle Product-Backlog-Einträge Lösungsstrategien entwi-ckelt wurden.

Am Ende des Sprint Plannings sollte das Entwicklungs-team in der Lage sein, dem Product Owner und demScrum Master zu erklären, wie es die geplante Arbeit um-setzen und das Produkt-Inkrement erstellen möchte. Miteiner visualisierten Lösungsstrategie geht das deutlicheinfacher als mit Tasks aus einem Softwaretool.

Wenn das Entwicklungsteam merkt, dass es sich zu vielArbeit in den Sprint genommen hat, kann es die Product-Backlog-Einträge mit dem Product Owner neu aushan-deln.Am Ende des Termins gibt das Entwicklungsteam einCommitment an den Product Owner ab, d.h. es verpflich-tet sich und zeigt den Willen das Sprint-Ziel zu erreichen.

Sprint-Ziel

Das Sprint-Ziel ist eine Zielsetzung, die durch die Abarbei-tung der Product-Backlog-Einträge erreicht werden kann.Es stellt eine Orientierung für das Entwicklungsteam dar,warum das Product Inkrement entwickelt werden soll.


Das Sprint-Ziel wird im Sprint Planning formuliert. Diefür den Sprint ausgewählten Product-Backlog-Einträgesollten möglichst eine zusammenhängende Funktionali-tät bilden, die mit dem Sprint-Ziel ausgedrückt werdenkönnen.

TippHängt das Sprint-Ziel zum Sprint Backlog, so-dass das Team täglich im Daily Scrum dasSprint-Ziel sieht und überprüfen kann, wie derFortschritt bezüglich des Sprint-Ziels ist!

Es fällt Teams immer wieder schwer, ein Sprint-Ziel zuformulieren. Dabei können jedoch folgende Arten vonSprint-Zielen helfen:

• Risiko adressieren• Annahme belegen bzw. widerlegen• Optimierungen• Fertigstellung und Auslieferung einer Funktionalität

Achtung!“Alle Sprint-Backlog-Einträge erledigen” istkein Sprint-Ziel!

Auf der Sprint-Ziel-Vorlage findest du eine einfache Vorla-ge mit Beispielen für das Sprint-Ziel zum Ausdrucken. DieVorlage findest du unter Vorlagen auf der Webseite zumBuch:https://www.scrum-erfolgreich-anwenden.de/

Agenda für das Sprint Planning


Folgende Agenda verwende ich üblicherweise in meinenSprint Plannings:

• Begrüßung und Erklärung des Ziels des Termins• Vorstellung der Product-Backlog-Einträge für den Sprint• Fragen des Entwicklungsteams zu Product-Backlog-

Einträgen• Schätzen der Product-Backlog-Einträge• Teamkapazität feststellen• Auswahl der Product-Backlog-Einträge für den Sprint• Formulierung des Sprint-Ziels

Auf dem Sprint Planning Spickzettel findest du eine kom-fortable Übersicht mit allen Informationen und der Agen-da zum Ausdrucken. Den Spickzettel findest du unterVorlagen auf der Webseite zum Buch:https://www.scrum-erfolgreich-anwenden.de/vorlagen/

Das Daily Scrum

Das Daily Scrum ist ein maximal 15-minütiges Meeting,in dem das Entwicklungsteam die Arbeit seit dem letztenDaily Scrum synchronisiert, die Arbeit für den Tag plantund den Fortschritt im Sprint hinsichtlich des Sprint-Zielsüberprüft. Das Daily Scrum findet an jedem Tag zur glei-chen Uhrzeit am gleichen Ort statt, idealerweise vor demSprint Backlog. Ich empfehle meinen Teams das Daily-Scrum recht früh am Tag durchzuführen, meist zwischen9:00 Uhr und 10:00 Uhr. So kann das Team nach derPlanung der Arbeit für den Tag direkt ans Werk gehen undden Plan umsetzen.

Es gibt verschiedene Arten, das Daily Scrum durchzufüh-ren. Im Scrum Guide wird empfohlen, dass jedes Team-mitglied die folgenden Fragen beantwortet:


• Was habe ich gestern erreicht, das dem Entwick-lungsteam hilft, das Sprint-Ziel zu erreichen?

• Was werde ich heute erledigen, um dem Entwick-lungsteam bei der Erreichung des Sprint-Ziels zuhelfen?

• Sehe ich irgendwelche Hindernisse (Impediments),die mich oder das Entwicklungsteam vom Erreichendes Ziels abhalten?

Bei dieser Vorgehensweise passiert es schnell, dass dasDaily Scrum zum Status-Reporting wird. Die Teammitglie-der kommen dann schnell in Versuchung zu erklären wassie alles gemacht haben und wie “produktiv” sie waren.Zusätzlich springt man dann von einem Product-Backlog-Eintrag zum nächsten ohne einen Überblick zu bekom-men, was eigentlich noch alles erledigt werden muss, umdas Sprint-Ziel zu erreichen.Genau das sollten wir vermeiden. Der Fokus im DailyScrum liegt nicht auf der individuellen Arbeit, sondern aufden Produkt Backlog Items, die im Sprint zu bearbeitensind. Dazu empfehle ich dir, das Format Walk the Boardmit deinem Team auszuprobieren:

Walk the Board

1. Ein Teammitglied übernimmt die Moderation. Wennman diese Methode einführt, ist es am Anfang sinn-voll den Scrum Master die Moderation überneh-men zu lassen, damit das Entwicklungsteam sich aufdie einzelnen Product Backlog Items konzentrierenkann. Später kann man abwechseln die Moderationan die Teammitglieder des Entwicklungsteams über-geben.

2. Der Moderator geht, beginnend von oben nach un-ten, jedes Product Backlog Item durch. Dabei wird


festgestellt, was für diese Product Backlog Item nochgetan werden muss, damit es abgeschlossen wer-den kann.

3. Anschließen werden das Product Backlog Item unddie zugehörigen Tasks von rechts nach links aktuali-siert, d.h. das Team prüft, welche Tasks und ProductBacklog Items erledigt, in Arbeit bzw. offen sind. Wennbereits genug Arbeit für den Tag verteilt ist, kannman an dieser Stelle aufhören. Man muss nicht alleTasks und Product Backlog Items durchgehen, wennman weiß, dass man diese nicht bis zum nächstenDaily Scrum abarbeiten kann.Bereits fertiggestellte Product Backlog Items mussman an dieser Stelle nicht mehr betrachten, sie sindja bereits abgeschlossen.

4. Abschließend überprüft das Team den Fortschritt imSprint. Hier hilft es das Team zu fragen, wie zuver-sichtlich es ist, dass das Sprint-Ziel erreicht wird. Esist wichtig, dass das Team dies verbalisiert, weil dannganz schnell und einfach unterschiedliche Ansichtenzum Tragen kommen.

Die Idee hinter dieser Methode ist, dass möglichst vieleTeammitglieder an einem Product Backlog Item arbeiten.Das stellt sicher, dass das Team nicht wahllos Aufgabenaus dem Sprint Backlog zur Bearbeitung auswählt, son-dern, dass das Team interdisziplinär und gemeinsam anwenigen Product Backlog Items arbeitet. Die Methodevermeidet Aussagen aus der Ich-Perspektive und fördertdas wir im Team, weil das Team grundsätzlich bei je-dem Product-Backlog-Eintrag die Frage beantwortet: Wasmüssen wir noch tun, damit das Product Backlog Itemerledigt ist?

Auf dem Daily Scrum Spickzettel findest du eine komfor-


table Übersicht mit allen Informationen und der Vorge-hensweise zum Ausdrucken.

Zusätzlich habe ich noch ein Dokument Daily Scrum: Tippsund Tricks erstellt, das dir und deinem Team hilft, dasDaily Scrum wertvoll und effektiv zu gestalten.

Den Spickzettel und die Tipps und Tricks findest du unterVorlagen auf der Webseite zum Buch:https://www.scrum-erfolgreich-anwenden.de/vorlagen/

Das Sprint Review

Am Ende eines Sprints findet das Sprint Review statt.Für einen einmonatigen Sprint dauert das Sprint Reviewmaximal vier Stunden. In diesem Meeting überprüft dasScrum-Team das Produkt-Inkrement und passt gegebe-nenfalls das Product Backlog an.

Das Sprint Review ist mehr als eine Demonstra-tion des Produktes!

Das Sprint Review wird sehr oft unterschätzt. Man findetfür das Sprint Review Bezeichnungen wie Sprint Demooder Demo Meeting. Das Sprint Review Meeting ist jedochmehr als das. In diesem Meeting geht es darum Feed-back zum Produkt-Inkrement sowie zu dem Produkt ansich zu bekommen. Deshalb ist es sinnvoll auch Kolle-gen außerhalb des Scrum-Teams einzuladen. Das könnenStakeholder aber auch Interessenten sowie Kunden sein.Das Feedback zum Produkt-Inkrement kann in Form vonneuen oder geänderten Einträgen im Product Backlogfestgehalten werden.

Der Fokus in diesem Termin liegt auf dem Produkt undden Maßnahmen hinsichtlich der Wertmaximierung des


Produktes. Oftmals dient das Sprint Review als Abnah-metermin für die erledigte Arbeit des Entwicklungsteams.Genau das ist das Sprint Review nicht! Daher ist es wichtigzu Beginn allen Teilnehmern das Ziel und den Hinter-grund für diesen Termin klar zu machen:

Das Sprint Review ist ein kollaborativer Termin,in dem das entstandene Produkt-Inkrement ausdem Sprint überprüft wird. Weiterhin wird einBlick auf die nächsten Schritte hinsichtlich derWertmaximierung des Produktes geworfen.

Die Demonstration des entwickelten Produkt-Inkrementsist lediglich ein Teil des Termins. Der Blick auf die nächs-ten Schritte in der Produktentwicklung und der Blick desBusiness auf das Produkt sollte den größten Anteil indem Termin ausmachen. Oftmals gibt es in Unternehmenweitere Termine, die sich genau damit beschäftigen. Dasist jedoch gar nicht nötig. Genau dafür ist das SprintReview gedacht.

Jeder Sprint kann der letzte Sprint sein. Der Pro-duct Owner entscheidet formal hinsichtlich derWirtschaftlichkeit der Weiterentwicklung des Pro-duktes.

Diese formalen Entscheidungen können sein:

• Weiterentwicklung des Produktes• Unterbrechung der Entwicklung des Produktes• Weitere Teams zur Produktentwicklung hinzufügen,

um schneller entwickeln zu können• Release des Produktes


Problem: Das Sprint Reviewwird zum AbnahmeterminUm das Problem zu umgehen, lasst den Pro-duct Owner schon während des Sprints fertig-gestellte Sprint Backlog Items abnehmen. Dashat den Vorteil, dass man eventuelle Korrek-turen noch vornehmen kann. Des Weiterenmuss man den Aspekt Abnahmenicht mehr imReview berücksichtigen.

Agenda für das Sprint Review

Folgende Agenda verwende ich üblicherweise in SprintReviews:

• Begrüßung und Erklärung des Ziels des Termins• Vorstellung der erledigten und nicht erledigten Sprint

Backlog Items• Demonstration des lauffähigen Produkt-Inkrements• Fragen und Feedback an das Entwicklungsteam zum

Produkt-Inkrement• Entscheidung, was mit nicht fertiggestellte Sprint

Backlog Items geschieht• Aktuelle Situation des Produktes (Marktbeobachtun-

gen, Trends und Einschätzungen)• Überblick über Budget, Zeitplanung und Release-

Termine

Auf dem Sprint Review Spickzettel findest du eine komfor-table Übersicht mit allen Informationen und der Agendazum Ausdrucken. Den Spickzettel findest du unter Vorla-gen auf der Webseite zum Buch:https://www.scrum-erfolgreich-anwenden.de/vorlagen/


Die Sprint Retrospektive

Das letzte Scrum-Ereignis eines Sprints ist die Sprint Re-trospektive. Für einen einmonatigen Sprint wird hier-für eine Obergrenze von drei Stunden angesetzt. In die-sem Termin blickt das Scrum-Team auf den/die letztenSprint(s) zurück und erarbeitet Maßnahmen zur Verbes-serung der Arbeitsweise des Scrum-Teams.

Ziel von Retrospektiven ist die kontinuierlicheVerbesserung der Arbeitsweise des Teams.

Regeln der Retrospektive

In meinen Retrospektiven vereinbare ich mit dem Teamfolgende beiden Regeln:

Oberste Direktive:

Egal was wir heute erkennen, wir sind fest da-von überzeugt, dass alle Beteiligten zu jedemZeitpunkt nach bestem Wissen, Gewissen undKenntnissen gehandelt haben.

Vegas-Regel:

Was hier im Raum mit den Teilnehmern ge-sprochen wird, bleibt in diesem Raum und beidiesen Teilnehmern.

Diese Regeln unterstützen eine offene und vertrauens-volle Atmosphäre. In jeder Retrospektive wiederhole ichzu Beginn diese Regeln, auch wenn die Teilnehmer dieRegeln schon aus vergangenen Terminen kennen.


In der agilen Community gilt das Buch Agile Retrospectives:Making Good Teams Great von Esther Derby und DianaLarsen als Standardlektüre über Retrospektiven. In die-sem Buch beschreiben die Autorinnen fünf Phasen einerRetrospektive. Ich wende diese Phasen auch sehr oft an.

Phasen der Sprint Retrospektive

Folgende Phasen verwende ich üblicherweise in SprintRetrospektiven:

1. Begrüßung: Zu Beginn der Retrospektive erklärt derScrum Master das Ziel des Termins sowie die Rahmenbe-dingungen und die Regeln.

2. Gesprächsklima schaffen: Nachdem der Rahmen ge-setzt ist, soll ein vertrauensvolles Gesprächsklima ge-schaffen werden. Die Teammitglieder sollten dabei denFokus aus ihrer täglichen Arbeit nehmen. Es empfiehltsich daher kurzzeitige Aktivitäten mit dem Team durch-zuführen, in denen jeder Teilnehmer etwas sagen muss.

TippLass’ jeden Teilnehmer bereits zu Beginndes Termins reden. Teammitglieder, die nichtzu Beginn des Termins sprechen, setzt still-schweigend voraus, dass sie auch im restli-chen Meeting nicht reden müssen und blei-ben still.

3. Daten sammeln: Im nächsten Schritt blickt das Teamauf den/die letzten Sprint(s) zurück. Dabei soll ein ge-meinsames Bild bzw. Verständnis entwickelt werden, wiedie Ereignisse und Gegebenheiten in der Vergangenheit


waren. Die Daten dazu sollen ohne Bewertung gesam-melt und erfasst werden.

4. Einsichten erzeugen:Nachdem das Team ein gemein-sames Bild geschaffen hat, werden die gesammelten Da-ten sondiert, analysiert und interpretiert. Dabei hilft esnach Mustern Ausschau zu halten und die Ursache fürGegebenheiten zu finden.

5. Entscheidungen treffen: Gegen Ende der Retrospek-tive liegt der Fokus darauf, dass das Team Maßnahmenidentifiziert, die es im nächsten Sprint umsetzen kann,um eine Verbesserung der Zusammenarbeit zu errei-chen. Dabei ist es sinnvoll sich auf eine (wenige) Maßnah-me(n) zu konzentrieren.

6. Abschluss: Am Ende der Retrospektive wiederholt derScrum Master die beschlossene(n) Maßnahme(n) zur Ver-besserung der Arbeitsweise des Teams.

TippFüge die Maßnahme(n) zum Sprint Backloghinzu. So ist/sind die Maßnahme(n) währenddes gesamten nächsten Sprints sichtbar.

Ich empfehle am Ende des Termins eine Retrospektiveder Retrospektive zu machen und zu identifizieren, wasgut lief und was kann verbessert werden.

Auf dem Sprint Retrospektive Spickzettel findest du einekomfortable Übersicht mit allen Informationen und denPhasen zum Ausdrucken. Den Spickzettel findest du un-ter Vorlagen auf der Webseite zum Buch:https://www.scrum-erfolgreich-anwenden.de/vorlagen/


Product Backlog Refinement

Das Product Backlog Refinement ist kein eigenständigesEreignis in Scrum, sondern eine permanente Aktivität. Da-bei sollte das Entwicklungsteam nicht mehr als 10% derKapazität des Entwicklungsteam verwenden. Im ProductBacklog Refinement wird das Product Backlog verfeinertund Details und Schätzungen zu den Product-Backlog-Einträgen hinzugefügt und die Reihenfolge der Product-Backlog-Einträge im Product Backlog angepasst. Es istnicht nötig, immer das gesamte Entwicklungsteam imRefinement dabei zu haben.

Die Artefakte in Scrum

Ergebnisse und Zwischenstände werden in Scrum durchArtefakte repräsentiert. In Scrum gibt es drei Artefakte:Das Product Backlog, das Sprint Backlog und das Produkt-Inkrement.

Das Product Backlog

Das Product Backlog ist eine geordnete Liste, die allesBekannte beinhaltet, was im Produkt enthalten sein soll.Ein Element dieser Liste nennt man Product-Backlog-Eintrag (englisch: Product Backlog Item). Die Form, Artund Weise der Einträge ist bei Scrum nicht vorgegeben.Das Product Backlog ist geordnet nach der Auslieferungder Product-Backlog-Einträge. Dabei stehen die Einträge,die als nächstes ausgeliefert werden, oben. Wenn derProduct Owner die Einträge ordnen möchte, um den


Wert des Produkts zu maximieren, muss er das gesamteBacklog berücksichtigen.

Warum ist das Product Backlog geordnet und nichtpriorisiert?

Stell dir vor, du willst ein Haus in den Tropen bauen. War-um baust du das Haus in den Tropen? Weil es dort sehroft regnet und du dich vor dem Regen schützen willst.Für ein Haus brauchst du Wände, Fenster und Türen.Und natürlich ein Dach. Die maximale Wertsteigerungbekommst du nur mit dem Dach.

TippWenn neue Einträge in das Product Backlogkommen, muss für die Ordnung immer dasgesamte Product Backlog berücksichtigt wer-den, um eine langfristige Wertsteigerung zuerreichen.

Dein Product Backlog erstellst du für dein gesamtes Haus.Dann ordnest du dein Product Backlog bezüglich derlangfristigen Wertsteigerung. Dadurch kann es sein, dassder Product-Backlog-Eintrag mit dem Bauen des Dacheserst später in die Auslieferung kommt, obwohl es daswichtigste Element in deinem Product-Backlog ist. DerEintrag steht also nicht ganz oben.

Das Product Backlog ist ein lebendes Artefakt, es ist dy-namisch. Höher eingeordnete Product-Backlog-Einträgesind generell klarer und weisen mehr Details auf alsniedrigere.


TippIdealerweise sollten im Product Backlog Ein-träge für die nächsten 2-3 Sprints so detailliertsein, dass man diese in den nächsten Sprintübernehmen könnte.

Das Sprint Backlog

Im ersten Teil des Sprint Plannings stellt der ProductOwner das Sprint-Ziel und die zugehörigen Einträge ausdem Product Backlog für den nächsten Sprint vor. DasEntwicklungsteam wählt davon so viele Einträge aus, wiees glaubt im Sprint zu schaffen. Gegebenenfalls gibt esAnpassungen am Sprint-Ziel bzw. den Einträgen für denSprint, sodass das gesamte Scrum-Team ein gemeinsa-mes Verständnis hat, welche Product-Backlog-Einträgeim Sprint bearbeitet werden und was das Sprint-Ziel ist.Diese ausgewählten Einträge kommen dann in das SprintBacklog. Im zweiten Teil des Sprint Plannings erarbeitetdas Entwicklungsteam einen Plan, wie es das Sprint-Zielerreichen möchte.

Das Sprint Backlog ist die Menge der für denSprint ausgewählten Product-Backlog-Einträge,ergänzt um einen Plan, um das Produkt-Inkrementzu liefern und das Sprint-Ziel zu erreichen.

Es gibt keine festgelegte Form, wie das Sprint Backlogauszusehen hat. Immer wieder gibt es Diskussionen, obman ein physisches Board, ein elektronisches Board oderbeides benutzen soll. Gerade für Scrum-Anfänger emp-fehle ich immer ein physisches Board mit Post-It Notes.


Weitere Details, wie so ein Board aussehen kann, gibt esim Kapitel Methoden erfolgreicher Scrum-Teams.

Das Produkt-Inkrement

Das Produkt-Inkrement ist ein erlebbares Artefakt, dassdie im Sprint fertiggestellte Arbeit, sowie die fertiggestell-te Arbeit aus vorangegangen Sprints enthält. Es ist dienächste Entwicklungsstufe des Produkts im Hinblick aufdie Produkt-Vision und unterstützt die Empirie am Endedes Sprints.

Das Produkt-Inkrement ist potentiell ausliefer-bar.

Über diese Formulierung gibt es viele Diskussionen inTeams und in agilen Communities.Was ist mit dieser Formulierung gemeint:

• Das Produkt-Inkrement fördert Feedback.• Das Produkt-Inkrement hilft dem Scrum-Team den

Fortschritt des Produktes im Hinblick auf die Produkt-Vision zu beurteilen.

• Das Produkt-Inkrement ermöglicht die Auslieferungdes Produktes, falls es gewünscht ist.

Man muss auf jeden Fall zwischen potentiell ausliefer-bar und auslieferbar unterscheiden:Bei sehr komplexen Produkten sind zum Teil zusätzlicheArbeiten für die Auslieferung an den Endkunden nötig.Potentiell auslieferbare Produkt-Inkremente können anTest-User, Testkunden und Stakeholder gegeben werden,


um Feedback zu bekommen und zum Beispiel eine Hy-pothese zu belegen, um schnell Feedback zu bekommen.Ausgehend von diesem Feedback und den Erfahrungenkönnen dann Änderungen am Produkt vorgenommenwerden. Genau das ist empirisches Vorgehen: Ein Vorge-hen, das auf Basis von Erfahrungen beruht. Für diesenFall ist es jedoch nicht nötig, Arbeiten für ein Releasedurchzuführen.

Es gibt natürlich Methoden und Techniken, um nahezunach jedem Sprint (oder sogar während des Sprints) Re-leases zum Endkunden auszuliefern. Darauf gehe ich inden Kapiteln Methoden erfolgreicher Scrum-Teams undTechniken leistungsstarker Entwicklungsteams ein.

Der Workflow

Den Workflow von Scrum kann man wie folgt visualisie-ren:


ScrumWorkflow

Impediments

Impediments sind Hindernisse, die das Entwicklungsteamin seiner Arbeit behindern, bzw. daran hindern, das Sprint-Ziel zu erreichen.

Tipps im Umgang mit Impediments

1. Mach die Hindernisse sichtbar, z.B. in einem Impe-diment Backlog.


Impediment Backlog

1. Der Scrum Master sollte nur die Impediments lö-sen, die das Entwicklungsteam nicht selbst lösenkann. Das fördert die Selbstorganisation des Ent-wicklungsteam.

2. Holt euch Hilfe außerhalb des Teams. In vielen Un-ternehmen haben mehrere Teams die gleichen Hin-dernisse. Hier kann es helfen, sich mit anderen Teamsauszutauschen und globale Impediments unterneh-mensweit zu adressieren und zu beseitigen.

Die Werte von Scrum

Seit Juli 2016 enthält der Scrum Guide auch die fünf Wertevon Scrum:


1. Commitment

Commitment kann man in diesem Zusammenhang ambesten mit Selbstverpflichtung übersetzen. Das Team unddas Management verpflichten sich, die nötigen Dinge undMaßnahmen anzugehen, damit das Ziel erreicht werdenkann. Das Team selbst versucht nicht nur das Sprint-Zielzu erreichen, sondern es hat und zeigt den Willen dieszu tun. Regelmäßige Überstunden gehören jedoch nichtdazu!

2. Fokus

Nur wer sich auf seine Aufgabe fokussiert, kann erfolg-reich auf ein Ziel hinarbeiten. Für das Team heißt das,es fokussiert sich auf das Sprint-Ziel (und es gibt einSprint-Ziel!). Arbeit, die nicht zur Erfüllung des Sprint-Zielsgehört, sollte möglichst vermieden bzw. anders verteiltwerden.

3. Offenheit

Die Entwicklung komplexer Produkte enthält zum großenTeil Wissensarbeit. Je offener man an eine Aufgabe geht,desto mehr Optionen ergeben sich. Das wiederum führtzu besseren Lösungen. Jeder Beteiligte sollte wissen, wasgerade das größte Problem ist damit jeder Einzelne zurLösung beitragen kann. Des Weiteren gehört dazu dieOffenheit gegenüber unbekannten Methoden, Technikenund Praktiken. Sei also offen für die nächsten Kapitel indiesem Buch.


4. Respekt

Respekt ist eine Voraussetzung für Offenheit. Nur wersich respektiert fühlt, wird auch zu den eigenen Schwä-chen stehen. Dazu gehört auch, dass man unterschiedli-che Meinungen zulässt und respektiert.

5. Mut

Es benötigt Mut im Team um Probleme anzusprechen,die Veränderungen hervorrufen sollen. Es benötigt aberauch Mut im Unternehmen bei der Veränderung derKultur in der Organisation, um besser zu werden.

Wann und wie wendetman Scrum erfolgreichan?Im ersten Teil des Kapitels zeige ich Situationen undUmgebungen auf, in denen Scrum die meisten Vorteilebietet und Anwendung finden sollte. Im zweiten Teil desKapitels gehe ich auf Faktoren für die erfolgreiche Anwen-dung von Scrum ein.

Wann macht der Einsatz von ScrumSinn?

Die Stacey-Matrix, nach Ralph Douglas Stacey, hilft bei derEntscheidung in welchen Umgebungen (Marktumgebun-gen, Produkten und Projekten) man welches Vorgehenverwenden sollte.

Wann und wie wendet man Scrum erfolgreich an? 53

Stacey-Matrix

Die y-Achse stellt die Anforderungen (das WAS) begin-nend von klaren bis hin zu unklaren Anforderungen dar.Die x-Achse stellt die Technik (das WIE) von klar bis unklardar.

Einfache Umgebungen

In einfachen Umgebungen sind die Anforderungen unddie Technik klar und bekannt. Dies ist dann der Fall, wenndas Unternehmen schon Routine im Lösen entsprechen-der Aufgaben hat. Das Unternehmen hat dann Standard-prozesse, auf die es zurückgreifen kann. In diesem Fallkann das Unternehmen zum Beispiel auf das klassischeWasserfall-Modell zurückgreifen, in dem die nächste Pha-se erst dann begonnen wird, wenn die derzeitige Phaseabgeschlossen ist. Eine Anwendung von Scrum bietet hier


wenig Vorteile.

Ein Beispiel aus dem täglichen Leben für ein einfachesProblem ist das Backen eines Kuchens nach einem Re-zept: Die Zutaten und die Zubereitungsschritte sind be-kannt. Man benötigt kein Expertenwissen und das Ergeb-nis ist vorhersehbar.

Komplizierte Umgebungen

In komplizierten Umgebungen ist das WAS und das WIEnicht ganz klar. Hier kann das Unternehmen die Situa-tion analysieren, in kleine Schritte runterbrechen undLösungsentscheidungen treffen. In komplizierten Umge-bungen kann es mehrere richtige Lösungen geben. Umkomplizierte Probleme zu lösen, benötigt man Experten-wissen. Das Wissen kann man sich dazu holen oder auf-bauen. In komplizierten Umgebungen kann man Scrumeinsetzen, muss man aber nicht.

Das Konstruieren eines Hauses ist ein kompliziertes Pro-blem. Man benötigt dazu Expertenwissen und es gibtmehrere Lösungen.

Komplexe Umgebungen

In komplexen Umgebungen und Situationen ist das WASund das WIE unklar und mehr unvorhersehbar als vor-hersehbar. Das betrifft sowohl die Technik als auch dieAnforderungen. Teams und Organisationen, die in einerkomplexen Umgebung arbeiten, müssen Sachverhalteprüfen, um das Problem zu erkunden. Die gewonnenenErkenntnisse müssen bewertet werden und basierendauf den Erkenntnissen müssen Anpassungen vorgenom-men werden. Das Arbeiten in komplexen Umgebungen


erfordert kreatives und innovatives Vorgehen. Scrum bie-tet in diesen Umgebungen die meisten Vorteile und solltehier Anwendung finden.Unternehmen müssen eine gesicherte Arbeitsumgebungfür Experimente errichten, damit Teams Informationenentdecken und Erfahrungen machen können. Das erfor-dert das Loslassen von Command & Control-Strukturenhin zu einer Führung von Mitarbeitern, die auf Wertenund Prinzipien beruht. Das Verständnis von Fehlern alsetwas Negatives muss geändert werden. Wenn Dingenicht funktionieren, jedoch wichtige Erkenntnisse gewon-nen werden, dann ist das ein Lernerfolg für Teams undfür Unternehmen.

Die Kindererziehung ist ein gutes Beispiel für eine kom-plexe Aufgabe. Eltern haben eine Vision, welche Eigen-schaften und Fähigkeiten ihr Kind in Zukunft haben sollte.Es gibt jedoch keine Möglichkeit sich Wissen anzueignen,dass dann dafür sorgt, dass das Kind sich genauso entwi-ckelt, wie man sich das wünscht. Die Eltern müssen “Ex-perimente” machen, um zum Beispiel dem Kind den ver-antwortungsvollen Umgang mit Geld beizubringen. Dafürgibt es kein Hausrezept. Die Eltern müssen Erfahrungensammeln wie das Kind mit Geld umgeht und beruhendauf diesen Erfahrungen Anpassungen vornehmen.

Chaotische Umgebungen

Chaotische Umgebungen sind gekennzeichnet durch einhohes Maß an Unvorhersehbarkeit bezüglich der Anfor-derungen und der Technologie. Grundsätzlich sollte mansolche Umgebungen im Business-Kontext vermeiden, daauch im Nachhinein die Ursache-Wirkung-Beziehung nichtwirklich verlässlich geklärt werden kann.


Erfolgsfaktoren für Scrum

Es gibt sowohl unternehmensbezogene als auch teambe-zogene Erfolgsfaktoren. Ohne diese Faktoren wird Scrumnicht zum gewünschten Erfolg führen. An dieser Stellemöchte ich die grundlegendsten Faktoren aufführen.

Unterstützung vomManagement

Oftmals glaubt das Management bei der Einführung vonagilem Arbeiten, dass die Teams schneller arbeiten. Demist aber nicht so. Mit agilem Arbeiten werden Teams undOrganisationen in die Lage versetzt, Produkte schneller anden Markt zu bringen bzw. schneller aufMarktänderungenreagieren zu können. Die Mitglieder des Entwicklungs-teams werden nicht einfach schneller entwickeln, nur weilman Scrum anwendet.

Wie kann das Management Scrum-Teams unterstüt-zen?

1. VertrauenOhne Vertrauen kann man nicht erfolgreich zusammen-arbeiten, egal ob man agil oder klassisch aufgestellt ist.Im Grunde hat ein Unternehmen und damit auch dasManagement jedem einzelnen Mitarbeiter ja bereits perse das Vertrauen ausgesprochen, in dem es diese Mitar-beiter angestellt hat. Dieses Vertrauen muss sich auch inder täglichen Zusammenarbeit widerspiegeln.

2. Agiles ManagementDas Management kann selbst mit gutem Beispiel voran-gehen und selbst agil arbeiten und so die nötige Ver-änderung vorleben. Zugleich bekommt es einen Einblickin die Probleme und Herausforderungen, mit denen die


Teams konfrontiert werden. Führung sollte auf Wertenund Prinzipien beruhen und nicht auf Prozessen oderHierarchien.

3. Lokale Entscheidungen fördernSelbstorganisation bedeutet auch Entscheidungen zu tref-fen. Das Management sollte die Teams in die Lage verset-zen, Entscheidungen selbst zu treffen und zwar dort, woes nötig ist. Die Teams sind Experten und genau so sollteman sie auch behandeln.

4. Mittleres Management abholenDas mittlere Management kann die treibende Kraft fürund gegen eine erfolgreiche Umsetzung von agilem Ar-beiten bzw. Scrum sein. Manager müssen verstehen, dassin agilen Umgebungen ihre Aufgabe nicht das Managenvon Menschen, sondern das Managen von Prozessen ist.Der Manager als Führungskraft im agilen Kontext musssich als Agile Leader also als Führungskraft für Agilitätverstehen. Dazu gehören Aufgaben wie

• Formulierung von Zielen (in Abstimmung mit Unter-nehmenszielen)

• Rahmenbedingungen schaffen und organisatorischeWiderstände beseitigen

• Prozesse kontinuierlich verbessern (im Team undüber die Teamgrenzen hinweg)

• Transparente Kommunikation im Team und überTeamgrenzen hinweg vorleben

5.ManagementderOrganisation, nicht derMenschenDer Fokus des Managements (vor allem des mittlerenManagements) sollte darauf liegen, den Teams Arbeits-umgebungen und Prozesse an die Hand zu geben, mitdenen die Teams selbstorganisiert und unbürokratisch


arbeiten können. Dabei sollen Komplexität in der Orga-nisation und unnötige Bürokratie abgebaut werden.

Wille zur Veränderung

In den meisten Unternehmen hat das klassische Arbeiteneine lange Tradition. Prozesse, Denkweisen und Verhal-tensmuster entwickelten sich in vielen Jahrzehnten undes benötigt einen starken Willen und Ausdauer inner-halb der Organisation, um die bestehenden Prozesseund vor allen Denkweisen aufzubrechen. Scrum ist nichtdie Lösung für schwerfällige Unternehmen. Scrum zeigtlediglich Probleme auf, die Unternehmen haben. Es liegtan jeder Organisation selbst, wie man damit umgeht undwie man die Probleme löst. Die Mitarbeiter müssen ver-stehen, dass auch sie ihre Gewohnheiten und Verhaltens-muster anpassen müssen, um den Herausforderungender Märkte gerecht zu werden.

Gemeinsame Werte und Ziele

Führung von Mitarbeitern sollte auf gemeinsamen Wer-ten und Prinzipien beruhen. Ausgehend davon benöti-gen Management und Teams gemeinsame Ziele. Anhandvon diesen Zielen sollten Maßnahmen gemeinsam ge-troffen werden, um diese Ziele zu erreichen. Nichts an-deres macht ein Scrum-Team im Sprint-Planning: Ausge-hend vom Sprint-Ziel plant es die Arbeit für den nächstenSprint.Der Fokus sollte generell auf Zielen liegen, die den Team-Charakter stärken. Individuelle Ziele für einzelne Ange-stellte sind kontraproduktiv und ein Störfaktor für denerfolgreichen Einsatz von Scrum.


Training der Mitarbeiter

Ein bekannter Witz aus der Business-Welt:

Two managers are talking about training theiremployees. The first asks, “Yeah, but what if wetrain them, and they just leave?” The secondresponds, “What if we don’t train them, andthey stay?”

Obwohl das Agile Manifest 2001 verfasst wurde, kommtdas agile Arbeiten erst seit ein paar Jahren in vielenUnternehmen an. Mittlerweile (2018) kann man es alsMainstream bezeichnen. Dennoch gibt es einen hohenBedarf an Weiterbildung, um Unternehmen und derenMitarbeiter für die neue Art zu arbeiten, fit zu machen.Aus meiner Sicht gehört stetiges Lernen zu agilem Arbei-ten dazu und Unternehmen sollten regelmäßig ihre Mit-arbeiter schulen, wenn sie die am besten qualifiziertenAngestellten haben möchten. Das müssen nicht immerteure Zertifizierungskurse sein. In der täglichen Arbeitkann man immer wieder (gerade in Retrospektiven undCommunities of Practice) nicht nur Wissen, sondern vorallem auch Unternehmenskultur vermitteln.

Anwendung von agilen Methoden undTechniken

Da Scrum lediglich ein Rahmenwerk ist, gibt es auchnicht vor, WIE die Teammitglieder miteinander arbeitensollen. Für das WIE gibt es auch keine allgemeingülti-gen Vorgaben, die in jedem Unternehmen gleichermaßenzum Erfolg führen. Es gibt jedoch bewährte Methoden


und Techniken, die Scrum-Teams und Organisationenhelfen, bessere Zusammenarbeit zu fördern. Ich bin derfesten Überzeugung, dass erst agile Methoden und Tech-niken eine erfolgreiche Umsetzung von Scrum möglichmachen. Dabei muss jedes Team für sich entscheiden,welche dieser Methoden und Techniken Sinn machen.

In den Kapiteln Methoden erfolgreicher Scrum-Teamsund Techniken leistungsstarker Entwicklungsteams stelleich einige Methoden und Techniken vor, die mir undmeinen Teams geholfen haben, Scrum erfolgreich anzu-wenden.

Weitere ThemenDu liest gerade die Leseprobe des Buches Scrum erfolg-reich anwenden. Folgende weiteren Themen bekommstdu mit der Vollversion des Buches:

Scrum aus der Business-Sicht

Wie beginne ich mit Scrum?

Methoden erfolgreicher Scrum-Teams

Techniken leistungsstarkerEntwicklungsteams

Skalierung von Scrum

Scrum ausserhalb der IT

Weitere Informationen zum Buch findest du hier:https://www.scrum-erfolgreich-anwenden.de

Vorlagen zum BuchDas Buch lesen ist gut, Scrum erfolgreich anwenden istbesser. Daher habe ich auf der Webseite6 zu diesem Buchverschiedene Vorlagen zum Download f�r dich und deinTeam bereitgestellt. Diese Spickzettel, Tipps & Tricks so-wie Vorlagen und Beispielen sollen dir helfen, deinenArbeitsalltag mit Scrum einfacher zu gestalten und er-folgreiche Produkte f�r zufriedene Kunden zu entwickeln.Teile gern mit Kollegen und Freunden diese Vorlagen.

6Webseite zum Buch http://bit.ly/2NWpbo1

Dein Feedback zum BuchWenn dir das Buch gefallen hat, bitte ich dich das Buchweiterzuempfehlen. Vermutlich kennst du mindestens 3Personen und deinem privaten oder beruflichen Umfeld,die auch von den Informationen aus diesem Buch pro-fitieren würden. Schreib ihnen einfach direkt eine Nach-richt oder E-Mail, es dauert maximal eine Minute. Gernkannst du diesen Text verwenden:

Schau dir bitte das Buch “Scrum erfolgreich an-wenden” von Lutz Müller an. Mir hat es sehrgut gefallen und ich denke es ist auch für dichinteressant:https://www.scrum-erfolgreich-anwenden.de

Vielen Dank für deine Unterstützung! Falls du weitereFragen oder Anmerkungen hast, schicke mir bitte eine E-Mail [email protected].

Über den AutorMeine Name ist Lutz Müller. Ich unterstütze Teams undOrganisationen als Scrum Master und Agile Coach.

Ich begann 2005 meine berufliche Laufbahn als Software-Entwickler im Bereich Web-Entwicklung. Später speziali-sierte ich mich im Bereich iOS- und Android-Entwicklung.Zu dieser Zeit habe ich in vielen klassischen Wasserfall-Projekten gearbeitet, die von geringer Zusammenarbeit,Silo-Denken und Command & Control Strukturen geprägtwaren.

Seit 2012 arbeite ich als Freiberufler und bin recht schnellmit agilem Arbeiten als Software-Entwickler in Berüh-rung gekommen. Die Idee von selbstorganisierten Teamsund Zusammenarbeit auf Augenhöhe hat bei mir die Lei-denschaft für Scrum entfacht. Seit 2014 unterstütze ichTeams und Organisationen als Scrum Master und AgileCoach. Durch meine Erfahrungen als Software-Entwicklerkann ich mich in Entwicklungsteams hineinversetzen undverstehe die Sorgen und Probleme von Entwicklern beider Arbeit mit Scrum. Meine früheren Erfahrungen alsfreiberuflicher Auftragnehmer für Software-Projekte hel-fen mir in meinen Teams kundenorientiertes Arbeiten zuetablieren und Produkte zu entwickeln, die Kunden undMitarbeiter begeistern.

Über den Autor 65

Meine Mission

Respekt. Offenheit. Zweckmäßigkeit.Meine Mission ist es, Teams und Organisatio-nen hin zu einer nachhaltigen, kollaborativenund lernförderlichen Arbeitsumgebung zu füh-ren, in der Produkte geschaffen werden, dieKunden und Mitarbeiter begeistern.

Lutz Müller

UrheberrechtAlle Informationen und Materialien habe ich nach bestemWissen und Gewissen und ohne Gewähr geschriebenund zusammengestellt. Trotzdem haben sich vielleichtFehler eingeschlichen. Ich übernehme keine Garantie füreventuelle Schäden, die durch das Buch entstanden sind.

Alle Inhalte dieses Buches, insbesondere Texte, Fotogra-fien und Grafiken, sind urheberrechtlich geschützt. DasUrheberrecht liegt, soweit nicht ausdrücklich anders ge-kennzeichnet, bei mir.

Schreib mir gern eine Nachricht [email protected]

scrum erfolgreich anwenden · kennen, die scrum formal anwenden, aber bei denen sich der erfolg...

Documents