dl.dasscrumteam.com · 2020-01-28 · 1 Der Scrum Guide KenSchwaberundJeffSutherland...

[email protected]

DasScrumTeam AGBahnhofstraße 216304 Zug / Switzerland

Lesestoff und Nachschlagewerkfür den Start mit Scrum

READERDER

3 - 9 Sprints für 1. Auslieferung

6 Wochen bis 18 M

onate

Backlog Vorbereitung

und Schätzung

~ 1 Woche

Aufräumen und Vorbereitung

der Arbeitsumgebung

~ 1 Woche

Scrum Training 1 - 3 Tage

Sprint 5 - 20 Arbeitstage (fix)

Retrospective

~1,5 - 3 Stunden

Review ~1 Stunde / Sprint-Woche

Planning I : Was ~1 Stunde / Sprint-Woche

Planning II : Wie

~1 Stunde / Sprint-WocheBacklog

Refinement

max. 10% vom

Sprint z.B.

time-boxed;

1 Stunde / WocheDaily Scrum 15 Minuten, täglich

Kick-Off 1,5 - 3 Stunden

Scrum

Projektablaufplan

Peter Beck, Kai Simons

DasScrumTeam.com

Product Owner, Development-

Team und Stakeholder

Development-Team, Product

Owner und Stakeholder auf

Einladung durch Dev-Team

2 Scrum Reader – DasScrumTeam

Inhaltsverzeichnis

5Kapitel 1

Der Scrum Guidevon Ken Schwaber und Jeff Sutherland

37Kapitel 2

Sieben Praktiken für die effektive Scrum-Imple-mentierungvon Peter Beck

47Kapitel 3

Neun Übungen für erfolgreiche Retrospektivenvon Andreas Schliep

67Kapitel 4

Scrum Coachingvon Peter Beck und Andreas Schliep

71Kapitel 5

ScALeD – Scaled Agile and Lean Development

79Kapitel 6

Impressum

1 Der Scrum GuideKen Schwaber und Jeff Sutherland

Übersetzung der Version aus November 2017

Zweck des Scrum Guide

Scrum ist ein Rahmenwerk zur Entwicklung, Auslieferung und Er-haltung komplexer Produkte. Dieser Leitfaden beinhaltet die Defi-nition von Scrum. Diese Definition besteht aus den Scrum Rollen,Ereignissen, Artefakten sowie den Regeln, die sie miteinander ver-binden. Ken Schwaber und Jeff Sutherland haben Scrum entwickelt;der Scrum Guide wird von ihnen verfasst und veröffentlicht. Gemein-sam stehen sie hinter dem Scrum Guide.

Definition von Scrum

Scrum (n): Ein Rahmenwerk, innerhalb dessen Menschen komplexeadaptive Aufgabenstellungen angehen können, und durch das sie indie Lage versetzt werden, produktiv und kreativ Produkte mit höchst-möglichem Wert auszuliefern.

Scrum ist:

• Leichtgewichtig

• Einfach zu verstehen

• Schwierig zu meistern

1 Der Scrum Guide

Scrum wird seit den frühen 1990er Jahren als Prozessrahmenwerkzum Management der Arbeit an komplexen Produkten verwendet.Scrum ist weder ein Prozess, noch eine Technik oder vollständige Me-thode. Vielmehr ist es ein Rahmenwerk, innerhalb dessen verschie-dene Prozesse und Techniken zum Einsatz gebracht werden können.Scrum macht die relative Wirksamkeit Ihres Produktmanagementsund Ihrer Arbeitstechniken sichtbar, damit Sie fortlaufend das Pro-dukt, das Team und die Arbeitsumgebung verbessern können.

Das Scrum-Rahmenwerk besteht aus Scrum-Teams und den zu ih-nen gehörenden Rollen, Ereignissen, Artefakten und Regeln. JedeKomponente innerhalb des Rahmenwerks dient einem bestimmtenZweck und ist unentbehrlich für den Einsatz von Scrum und dessenErfolg.

Durch die Regeln von Scrum werden die Beziehungen und Wech-selwirkungen zwischen den Rollen, Ereignissen und Artefakten be-stimmt. Die Regeln von Scrum sind im Hauptteil dieses Dokumentesdargestellt.

Bestimmte Taktiken zur Nutzung von Scrum variieren und sind ananderer Stelle beschrieben

Anwendungen von Scrum

Scrum wurde ursprünglich dazu entwickelt, um Produkte zu mana-gen und zu entwickeln. Seit den frühen 1990er Jahren wird Scrumweltweit ausgiebig genutzt zur:

1. Erforschung und Identifizierung rentabler Märkte, Technologien und Produkt-fähigkeiten;

2. Entwicklung von Produkten und Erweiterungen;

3. Auslieferung von Produkten und Erweiterungen, regelmäßig undmehrmals täg-lich;


Anwendungen von Scrum

4. Entwicklung und Aufrechterhaltung von Cloud-Umgebungen (online, sicher,on-demand) und anderer Produktivumgebungen; sowie,

5. Erhaltung und Erneuerung von Produkten.

Scrum wird verwendet, um Software, Hardware, Embedded Software,Netzwerke von interagierenden Funktionen und autonome Fahrzeugezu entwickeln. Scrum wird aber auch in Schulen, Regierungs- undMarketingprojekten genutzt, zur Verwaltung von Organisationen undder Entwicklung von fast allem, was wir in unserem täglichen Lebenals Einzelpersonen und als Gesellschaften verwenden.

Scrum bewährt sich täglich im Umgang mit Komplexität, da Tech-nologie-, Markt- und Umweltkomplexitäten und deren Interaktionenrapide zugenommen haben.

Scrum hat sich bei iterativem und inkrementellem Wissenstransferals besonders effektiv erwiesen. Scrum wird heute häufig für Pro-dukte, Dienstleistungen und das Management der übergeordnetenOrganisation verwendet.

Der Kern von Scrum ist ein kleines Team von Menschen. DiesesTeam ist sehr flexibel und anpassungsfähig. Diese Stärken wirkenweiter zwischen mehreren und vielen Teams und sogar Netzwerkenvon Teams, die die Arbeit und Ergebnisse von Tausenden von Men-schen entwickeln, ausliefern, betreiben und erhalten. Sie arbeitenüber durchdachte Entwicklungsarchitekturen und Zielumgebungenfür Auslieferungen zusammen.

Wenn die Wörter „entwickeln“ und „Entwicklung“ im Scrum Guideverwendet werden, beziehen sie sich auf komplexe Arbeit, wie z.B.die oben beschriebenen Typen.

Scrum Reader – DasScrumTeam 7

1 Der Scrum Guide

Scrum: Theorie

Scrum basiert auf der Theorie empirischer Prozesssteuerung oderkurz „Empirie“. Empirie bedeutet, dass Wissen aus Erfahrung ge-wonnen wird und Entscheidungen auf Basis des Bekannten getroffenwerden. Scrum verfolgt einen iterativen, inkrementellen Ansatz, umPrognosesicherheit zu optimieren und Risiken zu kontrollieren.

Drei Säulen tragen jede empirische Prozesssteuerung: Transparenz,Überprüfung [Inspection] und Anpassung [Adaptation].

Transparenz

Die wesentlichen Aspekte des Prozesses müssen für diejenigen sicht-bar sein, die für das Ergebnis verantwortlich sind. Transparenz erfor-dert, dass diese Aspekte nach einem gemeinsamen Standard defi-niert werden, damit die Betrachter ein gemeinsames Verständnis desGesehenen teilen.

Dies umfasst beispielsweise:

• Eine gemeinsame Prozesssprache, die von allen Teilnehmern geteilt wird.

• Die Personen, die das Produktinkrement produzieren und inspizieren, müssenalle ein gemeinsames Verständnis von „fertig“ [„Done“] teilen.

Überprüfung

Scrum-Anwender müssen die Scrum-Artefakte und den Fortschrittregelmäßig in Bezug auf die Erreichung des Sprint-Ziels überprüfen,um unerwünschte Abweichungen zu erkennen. Ihre Untersuchun-gen sollten nicht so häufig erfolgen, dass sie die Arbeit behindern.Den größten Nutzen bringen Überprüfungen, wenn sie gewissenhaft


Scrum: Werte

durch kompetente Prüfer dort vorgenommen werden, wo die Arbeitverrichtet wird.

Anpassung

Wenn ein Prüfer feststellt, dass Aspekte des Prozesses von den ak-zeptablen Grenzwerten abweichen und dass das resultierende Pro-dukt so nicht akzeptabel sein wird, müssen der Prozess oder daszu bearbeitende Material angepasst werden. Die Anpassung muss[dann] so schnell wie möglich vorgenommen werden, um weitere Ab-weichungen zu minimieren.

Scrum schreibt vier formale Ereignisse für Überprüfung und Anpas-sung vor. Diese werden im Abschnitt Scrum-Ereignisse beschrieben:

• Sprint Planning

• Daily Scrum

• Sprint Review

• Sprint Retrospektive

Scrum: Werte

Wenn die Werte Selbstverpflichtung, Mut, Fokus, Offenheit und Re-spekt durch das Scrum-Team verkörpert und gelebt werden, werdendie Scrum-Säulen Transparenz, Überprüfung und Anpassung leben-dig und bauen bei allen Beteiligten Vertrauen zueinander auf. DieMitglieder des Scrum-Teams lernen und erforschen diese Werte, in-dem sie mit den Scrum-Ereignissen, Rollen und Artefakten arbeiten.

Der erfolgreiche Einsatz von Scrum beruht darauf, dass alle Betei-ligten kompetenter bei der Erfüllung dieser fünf Werte werden. Sie


1 Der Scrum Guide

verpflichten sich persönlich dazu, die Ziele des Scrum-Teams zu er-reichen. Die Mitglieder des Scrum-Teams haben den Mut, das Rich-tige zu tun und an schwierigen Problemen zu arbeiten. Jeder fokus-siert sich auf die Arbeit im Sprint und die Ziele des Scrum-Teams.Das Scrum-Team und seine Stakeholder sind sich einig, offen mit al-len Belangen ihrer Arbeit und den damit verbundenen Herausforde-rungen umzugehen. Mitglieder von Scrum-Teams respektieren sichgegenseitig als fähige, eigenverantwortliche Individuen.


Das Scrum-Team

Das Scrum-Team

Ein Scrum-Team besteht aus dem Pro-duct Owner, dem Entwicklungsteam,sowie dem Scrum Master. Scrum-Teams sind selbstorganisierend undinterdisziplinär. SelbstorganisierendeTeams entscheiden selbst, wie sie ih-re Arbeit am besten erledigen, anstattdieses durch andere Personen außer-halb des Teams vorgegeben zu bekom-men. Interdisziplinäre Teams verfügen über alle Kompetenzen, dieerforderlich sind, um die Arbeit zu erledigen, ohne dabei von Per-sonen außerhalb des Teams abhängig zu sein. Das Team-Modell inScrum wurde konzipiert, um Flexibilität, Kreativität und Produktivi-tät zu optimieren. Es hat sich herausgestellt, dass ein Scrum-Teamfür alle eingangs aufgeführten Anwendungsfälle und jegliche kom-plexe Arbeit in zunehmenden Maße effektiv ist.

Scrum-Teams liefern Produkte iterativ und inkrementell und maxi-mieren somit die Gelegenheiten für Feedback. Die inkrementelleAuslieferung eines „fertigen“ [Done] Produkts sorgt dafür, dass stetseine potentiell nützliche Version des Produkts zur Verfügung steht.

Der Product Owner

Der Product Owner ist dafür verantwortlich, den Wert desProduktes zu maximieren, das aus der Arbeit des Entwick-lungsteams entsteht. Wie dies geschieht, kann je nach Or-ganisation, Scrum-Team und Einzelpersonen stark variie-ren.


1 Der Scrum Guide

Der Product Owner ist die einzige Person, die für das Ma-nagement des Product Backlogs verantwortlich ist. DasProduct-Backlog-Management umfasst:

• Die Product-Backlog-Einträge klar zu formulieren;

• Die Einträge im Product Backlog so zu sortieren, dass Ziele und Missionenoptimal erreicht werden können;

• Den Wert der Arbeit zu optimieren, die das Entwicklungsteam erledigt;

• Sicherzustellen, dass das Product Backlog sichtbar, transparent und für alleklar ist sowie zeigt, woran das Scrum-Team als nächstes arbeiten wird; und

• Sicherzustellen, dass das Entwicklungsteam die Product-Backlog-Einträge imerforderlichen Maße versteht.

Der Product Owner kann die oben genannten Arbeiten selbst durch-führen oder sie durch das Entwicklungsteam erledigen lassen. DerProduct Owner bleibt jedoch immer rechenschaftspflichtig.

Der Product Owner ist eine einzelne Person, kein Komitee. Er kannzwar die Wünsche eines Komitees im Product Backlog wiedergeben,aber diejenigen, die einen Eintrag des Product Backlogs in seinerPriorität verändern möchten, müssen sich an den Product Ownerwenden.

Damit der Product Owner erfolgreich sein kann, muss die gesamteOrganisation seine Entscheidungen respektieren. Die Entscheidun-gen des Product Owners sind in Inhalt und Reihenfolge des ProductBacklogs sichtbar. Niemand darf das Entwicklungsteam zwingen, an-dere Anforderungen zu bearbeiten.

Das Entwicklungsteam

Das Entwicklungsteam besteht aus Profis, die am Ende eines jedenSprints ein fertiges [„Done“] Inkrement übergeben, welches poten-


Das Scrum-Team

ziell auslieferbar ist. Im Sprint Review muss ein fertiges Inkrementvorhanden sein. Nur Mitglieder der Entwicklungsteams erstellen dasProduktinkrement.

Entwicklungsteams sind von der Organisation sostrukturiert und befähigt, dass sie ihre eigene Ar-beit selbst organisieren und managen. Die darausresultierende Synergie optimiert die Gesamteffizi-enz und -Effektivität des Entwicklungsteams.

Entwicklungsteams weisen die folgenden Eigen-schaften auf:

• Sie sind selbstorganisierend. Niemand (nicht einmal der Scrum Master) sagtdem Entwicklungsteam, wie es aus dem Product Backlog potentiell ausliefer-bare Funktionalität erzeugen soll.

• Entwicklungsteams sind interdisziplinär. Sie haben als Team alle Fähigkeiten,die notwendig sind, um ein Produktinkrement zu erstellen.

• Scrum kennt für Mitglieder des Entwicklungsteams keine Titel. Dies ist unab-hängig von der Arbeit, die diese Personen erledigen.

• Scrum kennt keine weiteren Unterteilungen innerhalb des Entwicklungsteams,ungeachtet der verschiedenen Themenfelder, mit denen das Team sich befasst,also z.B. „Test“, „Architektur“,„Betrieb“ oder „Analyse“.

• Einzelne Mitglieder des Entwicklungsteams können zwar spezialisierte Fähig-keiten oder Spezialgebiete haben, aber die Rechenschaftspflicht obliegt demTeam als Ganzem.

Größe des Entwicklungsteams

Die optimale Größe des Entwicklungsteams ist klein genug, um flinkzu bleiben und groß genug, um bedeutende Arbeit innerhalb eines


1 Der Scrum Guide

Sprints erledigen zu können. Weniger als drei Mitglieder des Ent-wicklungsteams reduzieren die Interaktion und führen zu geringerenProduktivitätssteigerungen [als bei größeren Teams]. Kleinere Ent-wicklungsteams können eventuell kein potentiell auslieferbares Pro-duktinkrement liefern, da sie möglicherweise nicht über alle benö-tigten Fähigkeiten verfügen. Mehr als neun Mitglieder erfordern zuviel Koordination. Große Entwicklungsteams erzeugen eine zu hoheKomplexität, als dass ein empirischer Prozess nützlich wäre. ProductOwner und Scrum Master zählen nicht zu dieser Zahl dazu, sofernsie nicht ebenso die Arbeit aus dem Sprint Backlog erledigen.

Der Scrum Master

Der Scrum Master ist dafür verantwortlich, Scrum entspre-chend des Scrum Guides zu fördern und zu unterstützen.Scrum Master tun dies, indem sie allen Beteiligten helfen,die Scrum-Theorie, Praktiken, Regeln und Werte zu verste-hen.

Der Scrum Master ist ein „Servant Leader“ für das Scrum-Team. Der Scrum Master hilft denjenigen, die kein Teil des

Scrum-Teams sind, zu verstehen, welche ihrer Interaktionen mit demTeam sich hilfreich auswirken und welche nicht. Der Scrum Masterhilft dabei, die Zusammenarbeit so zu optimieren, dass der durchdas Scrum-Team generierte Wert maximiert wird.

Der Dienst des Scrum Masters für den Product Owner

Der Scrum Master dient dem Product Owner auf verschiedene Arten,unter anderem durch das:

• Sicherstellen, dass Ziele, Umfang und Produktdomäne von allen im Scrum-Team so gut wie möglich verstanden werden;


Das Scrum-Team

• Vermitteln von Techniken für eine effektive Verwaltung des Product Backlogs;

• Vermitteln eines Verständnisses für die Notwendigkeit klarer, prägnanter Pro-duct Backlog Einträge im Scrum-Team;

• Schaffen eines Verständnisses für Produktplanung in einem empirischen Ar-beitsumfeld;

• Sicherstellen, dass der Product Owner weiß, wie er das Product Backlog soanordnet, dass es den größten Wert erzeugt;

• Vermitteln des richtigen Verständnisses von Agilität und ihrer Anwendung;

• Unterstützen bei der Durchführung von Scrum-Ereignissen bei Bedarf oder aufAnfrage.

Der Dienst des Scrum Masters für das Entwicklungsteam

Der Scrum Master dient dem Entwicklungsteam auf verschiedeneArten, unter anderem durch das:

• Coachen des Entwicklungsteams hin zu Selbstorganisation und funktionsüber-greifender Teamarbeit;

• Unterstützung des Entwicklungsteams bei der Schaffung hochwertiger Pro-dukte;

• Beseitigen von Hindernissen, die das Entwicklungsteam aufhalten;

• Unterstützen bei der Durchführung von Scrum-Ereignissen bei Bedarf oder aufAnfrage;

• Coachen des Entwicklungsteams in Organisationen, in denen Scrum noch nichtvollständig angenommen und verstanden wird.


1 Der Scrum Guide

Der Dienst des Scrum Masters an der Organisation

Der Scrum Master dient der Organisation auf verschiedene Arten,unter anderem durch das:

• Leiten und Coachen der Organisation bei der Einführung von Scrum;

• Planen von Scrum-Implementierungen innerhalb der Organisation;

• Unterstützen von Kollegen und Stakeholdern, Scrum und empirische Produkt-entwicklung zu verstehen und umzusetzen;

• Auslösen von Veränderungen zur Produktivitätssteigerung des Teams;

• Zusammenarbeitenmit anderen ScrumMastern, um die Effektivität von Scrum-Implementierungen innerhalb der Organisation zu verbessern.

Scrum-Ereignisse

In Scrum werden vorgeschriebene Ereignisse verwendet, um eineRegelmäßigkeit herzustellen und die Notwendigkeit anderer, nichtin Scrum definierter, Besprechungen zu minimieren. Alle Ereignis-se sind befristet [time boxed], so dass jedes Ereignis eine maximaleDauer hat. Die Dauer eines Sprints steht zu seinem Beginn fest unddarf weder gekürzt noch verlängert werden. Die anderen Ereignissedürfen beendet werden, sobald sie ihren Zweck erfüllt haben. Diesstellt sicher, dass nur so viel Zeit wie nötig aufgewendet und Ver-schwendung vermieden wird.

Mit Ausnahme des Sprints als Container für alle anderen Ereignisseist jedes Scrum-Ereignis eine formale Gelegenheit zur Überprüfungund Anpassung. Diese Ereignisse sind genau dazu gedacht, an denkritischen Stellen Transparenz und Überprüfung zu ermöglichen. DasWeglassen irgendeines dieser Ereignisse führt zu verringerter Trans-


Scrum-Ereignisse

parenz und ist eine verpasste Gelegenheit den gegenwärtigen Standzu erfassen [Inspect] und darauf zu reagieren [Adapt].

Der Sprint

Das Herz von Scrum ist der Sprint, ein Zeitraum [Time Box] von ma-ximal einem Monat, innerhalb dessen ein fertiges [„Done“], nutzba-res und potenziell auslieferbares Produktinkrement hergestellt wird.Alle Sprints innerhalb eines Entwicklungsvorhabens sollten die glei-che Dauer haben. Der neue Sprint startet sofort nach Abschluss desvorherigen Sprints.

Ein Sprint beinhaltet und umfasst dasSprint Planning, die Daily Scrums, dieEntwicklungsarbeit, das Sprint Reviewund die Sprint Retrospektive.

Jeder Sprint kann als ein Projekt miteinem Zeithorizont von maximal ei-nem Monat gesehen werden. Wie miteinem Projekt will man mit einemSprint etwas Bestimmtes erreichen.Jeder Sprint hat einen definierten Leis-tungsumfang, einen Entwurf und einenflexiblen Plan, welche Umsetzung, Ar-beit und Ergebnis in die richtige Richtung führen.

Während des Sprints:

• werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden,

• wird der Qualitätsanspruch nicht geschmälert, und

• der Anforderungsumfang kann zwischen Product Owner und Entwicklungs-team geklärt und neu ausgehandelt werden, wenn sich neue Erkenntnisse er-geben haben.


1 Der Scrum Guide

Jeder Sprint kann als ein Projekt mit einem Zeithorizont von maximaleinem Monat gesehen werden. Wie mit einem Projekt will man miteinem Sprint etwas Bestimmtes erreichen. Jeder Sprint hat ein Ziel,was gebaut werden soll, einen Entwurf und einen flexiblen Plan, derdie Umsetzung, die Arbeit und das resultierende Produktinkrementin die richtige Richtung lenkt.

Sprints sind auf einen Kalendermonat beschränkt. Wenn der Zeitho-rizont eines Sprints zu groß gewählt wird, kann sich die Definition desErgebnisses ändern, die Komplexität ansteigen und das Risiko er-höhen. Sprints ermöglichen Vorhersagbarkeit, indem sie mindestenseinmal im Monat Überprüfung und Anpassungen des Fortschritts zueinem bestimmten Sprint-Ziel sicherstellen. Sprints reduzieren dazunoch das Risiko auf die Kosten eines Monats.

Einen Sprint abbrechen

Ein Sprint kann vorzeitig, d.h. vor dem Ablauf seiner Time Box, ab-gebrochen werden. Dazu ist nur der Product Owner berechtigt, auchwenn er oder sie den Abbruch auf Anraten der Stakeholder, des Ent-wicklungsteams oder des Scrum Masters vornimmt.

Ein Sprint würde dann abgebrochen werden, wenn das Sprint-Zielobsolet wird. Das kann vorkommen, wenn das Unternehmen seineZielrichtung wechselt, oder sich andere Markt- oder technologischeRahmenbedingungen ändern. In der Regel sollte ein Sprint dann ab-gebrochen werden, wenn die Fortführung unter den gegenwärtigenUmständen keinen Sinn mehr macht. Allerdings ist ein Abbruch beider kurzen Dauer der Sprints selten sinnvoll.

Wenn ein Sprint abgebrochen wird, werden alle abgeschlossenen und„Done“ Product-Backlog-Einträge begutachtet. Wenn ein Teil der Ar-beit potenziell auslieferbar ist, wird sie vom Product Owner meistensabgenommen. Alle unvollständigen Product-Backlog-Einträge wer-den neu geschätzt und wieder in das Product Backlog aufgenom-


Scrum-Ereignisse

men. Die bislang daran geleistete Arbeit verliert schnell an Wert,daher müssen diese Einträge häufiger neu geschätzt werden.

Sprint-Abbrüche verbrauchen Ressourcen, da sich alle Teammitglie-der zum Starten eines neuen Sprints in einem Sprint Planning um-organisieren. Sprint-Abbrüche sind zudem oft schmerzhaft für dasScrum-Team; sie sind eher unüblich.

Sprint Planning

Im Sprint Planning wird die Arbeit für den kommenden Sprint ge-plant. Dieser Plan entsteht durch die gemeinschaftliche Arbeit desgesamten Scrum-Teams.

Das Sprint Planning ist für einen einmonatigen Sprint auf maximal8 Stunden befristet [Time Box]. Bei kürzeren Sprints wendet mannormalerweise weniger Zeit auf. Der Scrum Master sorgt dafür, dassdas Ereignis stattfindet und die Teilnehmer dessen Zweck verstehen.Er bringt dem Scrum-Team bei, das Ereignis innerhalb der Frist er-folgreich abzuschließen.

Das Sprint Planning beantwortet die folgenden Fragen:

• Was ist in dem Produkt-Inkrement des kommenden Sprints enthalten?

• Wie wird die für die Lieferung des Produkt-Inkrements erforderliche Arbeit er-reicht?

Punkt 1: Was kann in diesem Sprint fertiggestellt werden?

Das Entwicklungsteam erstellt eine Prognose über die Funktionalität,die im Sprint entwickelt werden soll. Der Product Owner beschreibtdas Ziel, das mit dem Sprint erreicht werden soll, und die Product-Backlog-Einträge, welche – wenn sie in dem Sprint abgeschlossen


1 Der Scrum Guide

werden – das Ziel erfüllen. Das ganze Scrum-Team erarbeitet ge-meinsam ein Verständnis über die Arbeitsinhalte des Sprints.

Als Eingangsgrößen für das Mee-ting dienen das Product Backlog, dasneueste Produktinkrement, die veran-schlagte Kapazität des Entwicklungs-teams im Sprint sowie die bisheri-ge Leistung desselben. Ausschließ-lich das Entwicklungsteam bestimmtdie Anzahl der ausgewählten Product-Backlog-Einträge für den kommendenSprint. Nur es selbst kann beurteilen,

was im kommenden Sprint machbar ist.

Während des Sprint Plannings erarbeitet das Scrum-Team gemein-sam ein Sprint-Ziel. Das Sprint-Ziel bildet die Messlatte, die durchdie Implementierung der Product-Backlog-Einträge im Sprint erreichtwird; es leitet das Entwicklungsteam in der Frage, warum es diesesProduktinkrement erstellt.

Punkt 2: Wie wird die ausgewählte Arbeit erledigt?

Nach der Vereinbarung des Sprint-Ziels und der Auswahl der Product-Backlog-Einträge für den Sprint ent-scheidet das Entwicklungsteam, wie esdas Produktinkrement erstellen möch-te, damit die Funktionalität in ei-nen „Done“-Zustand gebracht werdenkann. Als Sprint Backlog bezeichnetman die Auswahl der Product-Backlog-Einträge für den jeweiligen Sprint plus

den Umsetzungsplan des Entwicklungsteams.


Scrum-Ereignisse

Das Entwicklungsteam beginnt normalerweise mit dem Entwurf desSystems und den Tätigkeiten, die notwendig sind, um ein funkti-onsfähiges Produktinkrement zu erstellen. Die Arbeiten können sichin der Größe oder dem geschätzten Aufwand unterscheiden. Auf je-den Fall sollte das Entwicklungsteam genug Arbeit planen, um zuprognostizieren, was es im kommenden Sprint schaffen zu könnenglaubt. Die für die ersten Sprint-Tage geplanten Arbeiten sind nachAbschluss des Meetings in kleinere Einheiten – oft von einem Tagoder weniger – zerlegt. Das Entwicklungsteam organisiert selbst, wiees die Arbeiten im Sprint Backlog angeht, sowohl im Sprint Planningals auch im Sprint selbst.

Der Product Owner kann dabei helfen, die ausgewählten Product-Backlog-Einträge zu klären und ggf. Kompromisse einzugehen. Wenndas Entwicklungsteam herausfindet, dass es sich zu viel oder zuwenig Arbeit vorgenommen hat, kann es die ausgewählten Product-Backlog-Einträge neu mit dem Product Owner aushandeln. Das Ent-wicklungsteam kann auch andere Teilnehmer zu dem Meeting einla-den, um technische oder fachliche Unterstützung zu erhalten.

Am Ende des Sprint Plannings sollte das Entwicklungsteam in derLage sein, Product Owner und Scrum Master zu schildern, wie es alsselbstorganisiertes Team an der Erreichung des Sprint-Ziels und derErstellung des gewünschten Produktinkrements arbeiten möchte.


1 Der Scrum Guide

Sprint-Ziel

Das Sprint-Ziel ist ein übergeordneter Zweck fürden Sprint, der durch die Implementierung derProduct-Backlog-Einträge erreicht werden kann.Es gibt dem Entwicklungsteam Orientierung,warum sie dieses Produktinkrement bauen. DasSprint-Ziel wird während des Sprint Planningerarbeitet. Das Sprint-Ziel bietet dem Entwick-lungsteam eine gewisse Flexibilität in Bezug aufdie im Sprint zu implementierende Funktionali-

tät. Die ausgewählten Product-Backlog-Einträge bilden eine zusam-menhängende Funktionalität, die als Sprint-Ziel angesehen werdenkann. Das Sprint-Ziel kann aber auch jedes andere verbindende Ele-ment sein, welches das Entwicklungsteam – statt in verschiedeneRichtungen zu laufen – zur Zusammenarbeit motiviert.

Bei seiner Arbeit behält das Entwicklungsteam sein Sprint-Ziel vorAugen. Um dieses zu erreichen, implementiert es die entsprechendeFunktionalität und Technologie. Falls es sich zeigt, dass der Arbeits-umfang von den ursprünglichen Erwartungen abweicht, handelt dasEntwicklungsteam gemeinsam mit dem Product Owner eine Ände-rung des Sprint-Backlog-Umfangs für den laufenden Sprint aus.

Daily Scrum

Das Daily Scrum ist eine Time Box von 15 Minuten für das Entwick-lungsteam. Das Daily Scrum findet an jedem Tag des Sprints statt.Das Entwicklungsteam plant dabei die Arbeit für die nächsten 24Stunden. Es überprüft die Arbeitsergebnisse seit dem letzten DailyScrum und prognostiziert die im Sprint bevorstehende Arbeit, umdie Zusammenarbeit und Leistung des Teams zu optimieren. Um dieKomplexität zu reduzieren, wird das Daily Scrum an jedem Tag zurgleichen Uhrzeit am gleichen Ort abgehalten.


Scrum-Ereignisse

Das Entwicklungsteam überprüft im Daily Scrum seinen Fortschrittin Richtung des Sprint-Ziels und den Trend bei der Abarbeitung derSprint Backlog-Einträge. Das Daily Scrum erhöht die Wahrscheinlich-keit, dass das Entwicklungsteam sein Sprint-Ziel erreicht. Das Ent-wicklungsteam sollte Tag für Tag im Blick haben, wie es als selbstor-ganisiertes Team zusammenarbeiten möchte, um das Sprint-Ziel zuerreichen und das erwartete Inkrement zum Sprintende zu liefern.

Die Struktur des Ereignisses wird vom Entwicklungsteam festgelegtund kann auf unterschiedliche Weise durchgeführt werden, soferndie Erreichung des Sprint-Ziels im Fokus steht. Einige Entwicklungs-teams verwenden Fragen, andere konzentrieren sich eher auf Diskus-sionen. Hier ist ein Beispiel, was verwendet werden könnte:

• Was habe ich gestern getan, das dem Entwicklungsteam geholfen hat, dasSprint-Ziel zu erreichen?

• Was werde ich heute erledigen, um dem Entwicklungsteam beim Erreichen desSprint-Ziels zu helfen?

• Sehe ich irgendein Hindernis, das mich oder das Entwicklungsteam daran hin-dert, das Sprint-Ziel zu erreichen?

Das Entwicklungsteamoder einzelne Mitglie-der treffen sich häufigdirekt nach dem DailyScrum für detaillierte-re Diskussionen, Anpas-sungen oder Umplanun-gen der Arbeit im Sprint.

Während der Scrum Master dafür sorgt, dass ein Daily Scrum statt-findet, ist das Entwicklungsteam für die Durchführung zuständig.Hierzu bringt der Scrum Master dem Entwicklungsteam bei, wie esdie 15-minütige Time Box des Daily Scrums einhalten kann.


1 Der Scrum Guide

Das Daily Scrum ist ein internes Ereignis für das Entwicklungsteam.Falls andere Personen anwesend sind, stellt der ScrumMaster sicher,dass sie das Meeting nicht stören.

Daily Scrums verbessern die Kommunikation, machen andere Mee-tings überflüssig, identifizieren zu beseitigende Hindernisse, fokus-sieren und fördern die schnelle Entscheidungsfindung und erhöhenden Wissensstand des Entwicklungsteams. Das Daily Scrum ist einentscheidendes Meeting zur Überprüfung und Anpassung.

Sprint Review

Am Ende eines Sprints wird ein Sprint Reviewabgehalten, um das Produktinkrement zu über-prüfen und das Product Backlog bei Bedarf an-zupassen. Während des Sprint Reviews beschäf-tigen sich das Scrum-Team und die Stakehol-der gemeinsammit den Ergebnissen des Sprints.Zusammen mit eventuellen Änderungen am Pro-duct Backlog während des Sprints bieten diese

die Basis für die gemeinsame Arbeit an möglichen neuen, den Wertdes Produkts steigernden Punkten. Beim Sprint Review handelt essich um ein informelles Meeting, keinen Statusreport. Die Vorfüh-rung des Inkrements ist als Anregung für Feedback und die Basis fürdie Zusammenarbeit gedacht.

Für einen einmonatigen Sprint wird für dieses Meeting eine Ober-grenze [Time Box] von vier Stunden angesetzt. Für kürzere Sprintswird in der Regel ein kürzerer Zeitrahmen veranschlagt. Der ScrumMaster stellt sicher, dass das Event stattfindet und die Teilnehmerseinen Zweck verstehen. Der Scrum Master bringt allen Beteiligtenbei, das Event innerhalb der Frist [Time Box] durchzuführen.


Scrum-Ereignisse

Das Sprint Review beinhaltet die folgenden Elemente:

• Die Teilnehmer, bestehend aus dem Scrum-Team und wichtigen Stakeholdern,die vom Product Owner eingeladen werden.

• Der Product Owner erklärt, welche Product-Backlog-Einträge fertig [„Done“]sind, und welche nicht.

• Das Entwicklungsteam stellt dar, was während des Sprints gut lief, welcheProbleme aufgetaucht sind, und wie es diese Probleme gelöst hat.

• Das Entwicklungsteam führt die fertige Arbeit vor, und beantwortet Fragen zudem Inkrement.

• Der Product Owner stellt den aktuellen Stand des Product Backlogs dar. Ergibt bei Bedarf eine aktualisierte Vorhersage von wahrscheinlichen Ziel- undLieferterminen auf der Basis des Entwicklungsfortschritts.

• Alle Teilnehmer erarbeiten gemeinsam, was als nächstes zu tun ist, so dassdas Sprint Review wertvollen Input für die kommenden Sprint Plannings liefert.

• Es erfolgt eine Begutachtung, ob sich durch die Marktsituation oder denmögli-chen Produkteinsatz neue Erkenntnisse über die wertvollsten nächsten Schritteergeben haben.

• Anschließend werden Zeitplan, Budget, die potentiellen Eigenschaften sowiedie Markterwartungen für das nächste zu erwartende Produkt-Release über-prüft.

Das Ergebnis des Sprint Reviews ist ein überarbeitetes Product Back-log, das die möglichen Product-Backlog-Einträge für den kommen-den Sprint enthält. Das Product Backlog kann auch umfassend um-gearbeitet werden, um neue Chancen zu nutzen.


1 Der Scrum Guide

Sprint Retrospektive

Die Sprint Retrospektive bietet dem Scrum-Team die Gelegenheit, sich selbst zu überprüfenund einen Verbesserungsplan für den kommen-den Sprint zu erstellen.

Sie findet zwischen dem Sprint Review und demnächsten Sprint Planning statt. Für einen einmo-natigen Sprint wird hierfür eine Obergrenze vondrei Stunden angesetzt. Bei kürzeren Sprints ist

das Meeting in der Regel kürzer. Der Scrum Master sorgt dafür, dassdas Meeting stattfindet und alle Teilnehmer dessen Zweck verstehen.

Der Scrum Master sorgt dafür, dass das Meeting konstruktiv und pro-duktiv ist. Der Scrum Master lehrt alle, die Time Box einzuhalten.Aufgrund seiner Verantwortung für den Scrum-Prozess nimmt derScrum Master als gleichberechtigtes Mitglied an der Sprint Retro-spektive teil.

Die Sprint Retrospektive wird durchgeführt, um

• zu überprüfen wie der vergangene Sprint in Bezug auf die beteiligten Personen,Beziehungen, Prozesse und Werkzeuge verlief;

• die wichtigsten gut gelaufenen Elemente und mögliche Verbesserungen zuidentifizieren und in eine Reihenfolge zu bringen; und

• einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise des Scrum-Teams zu erstellen.

Der Scrum Master bestärkt das Scrum-Team darin, seine Entwick-lungsprozesse und -praktiken innerhalb des Scrum Prozessrahmen-werks zu verbessern, um im kommenden Sprint effektiver und be-friedigender arbeiten zu können. In jeder Sprint Retrospektive erar-beitet das Scrum-Team Wege zur Verbesserung der Produktqualitätdurch die entsprechende Anpassung der Prozesse oder der Definiti-


Scrum Artefakte

on of Done, sofern diese Änderungen angemessen sind und nicht imWiderspruch mit Produkt- oder Unternehmensstandards stehen.

Zum Ende der Sprint Retrospektive sollte das Scrum-Team Verbes-serungen für den kommenden Sprint identifiziert haben. Die Umset-zung dieser Verbesserungen im nächsten Sprint ist die Anpassungs-leistung zur Selbstüberprüfung des Scrum-Teams. Auch wenn jeder-zeit Verbesserungen eingeführt werden können, bietet die Sprint Re-trospektive eine formelle Gelegenheit, sich auf die Überprüfung undAnpassung zu fokussieren.

Scrum Artefakte

Die Artefakte von Scrum repräsentieren Arbeit oder Wert, um Trans-parenz sowie Möglichkeiten zur Überprüfung und Anpassung zu schaf-fen. Die in Scrum definierten Artefakte wurden speziell so entworfen,dass sie die Transparenz der wesentlichen Informationen maximie-ren, um für alle ein gleiches Verständnis über das Artefakt zu schaf-fen.

Product Backlog

Das Product Backlog isteine geordnete Liste vonallem, von dem bekanntist, dass es im Produktenthalten sein soll. Esdient als einzige Anfor-derungsquelle für alle Änderungen am Produkt. Der Product Ownerist für das Product Backlog, seine Inhalte, den Zugriff darauf unddie Reihenfolge der Einträge verantwortlich.


1 Der Scrum Guide

Ein Product Backlog ist niemals vollständig. Während seiner erstenEntwicklungsschritte zeigt es die anfangs bekannten und am bestenverstandenen Anforderungen auf. Das Product Backlog entwickeltsich mit dem Produkt und dessen Einsatz weiter. Es ist dynamisch; espasst sich konstant an, um für das Produkt klar herauszustellen, wases braucht, um seiner Aufgabe angemessen zu sein, im Wettbewerbzu bestehen und den erforderlichen Nutzen zu bieten. Sofern einProdukt existiert, gibt es auch das dazugehörige Product Backlog.

Im Product Backlog werden alle Features, Funktionalitäten, Verbes-serungen und Fehlerbehebungen aufgelistet, die die Änderungen andem Produkt in zukünftigen Releases ausmachen. Ein Product-Back-log-Eintrag enthält als Attribute eine Beschreibung, die Reihenfolge,die Schätzung und den Wert. Product-Backlog-Einträge enthalten oftTestbeschreibungen, die ihre Vollständigkeit nachweisen, wenn siefertig [„Done“] sind.

Das Product Backlog entwickelt sich mit dem Einsatz eines Produk-tes, dessen Wertsteigerung sowie durch das Feedback des Markteszu einer längeren, ausführlicheren Liste. Anforderungen werden nieaufhören, sich zu ändern. Daher ist das Product Backlog ein leben-des Artefakt. Änderungen an den Geschäftsanforderungen, Markt-bedingungen oder der Technologie können Änderungen am ProductBacklog nach sich ziehen.

Häufig arbeiten mehrere Scrum-Teams gemeinsam an einem Pro-dukt. Dann wird ein einziges Product Backlog benutzt, um die an-stehende Arbeit am Produkt zu beschreiben. In diesem Fall kannein Gruppierungsattribut für die Product-Backlog-Einträge verwen-det werden.

Als Verfeinerung [Refinement] des Product Backlogs wird der Vor-gang angesehen, in dem Details zu Einträgen hinzugefügt, Schätzun-gen erstellt, oder die Reihenfolge der Einträge im Product Backlogbestimmt werden. Die Verfeinerung ist ein kontinuierlicher Prozess,in dem der Product Owner und das Entwicklungsteam gemeinsamdie Product-Backlog-Einträge detaillieren. Bei der Verfeinerung des


Scrum Artefakte

Product Backlogs werden die Einträge begutachtet und revidiert. DasScrum-Team bestimmt, wann und wie diese Verfeinerungsarbeit er-folgt. Sie sollte normalerweise nicht mehr als 10% der Kapazität desEntwicklungsteams beanspruchen. Der Product Owner kann jedochjederzeit die Einträge im Product Backlog aktualisieren oder aktua-lisieren lassen.

Höher eingeordnete Product-Backlog-Einträge sind generell klarerund weisen mehr Details auf als niedrigere. Präzisere Schätzungenentstehen auf der Basis von größerer Klarheit und Detailtiefe – jeniedriger der Rang, desto weniger Details sind bekannt. Die Product-Backlog-Einträge, mit denen sich das Entwicklungsteam im kom-menden Sprint beschäftigen soll, werden so weit verfeinert, dass je-der von ihnen innerhalb des Sprints fertiggestellt werden kann. DieProduct-Backlog-Einträge, für die das der Fall ist, werden als bereit[„Ready“] für die Auswahl durch das Entwicklungsteam in einemSprint Planning angesehen. Ein Product-Backlog-Eintrag entwickeltdiesen Transparenzgrad in der Regel durch die oben beschriebenenVerfeinerungs-Aktivitäten.

Das Entwicklungsteam ist für alle Schätzungen verantwortlich. DerProduct Owner kann das Entwicklungsteam dahingehend beeinflus-sen, dass er ihm beim Verständnis der Einträge hilft oder Kompro-misse eingeht. Die endgültige Schätzung erfolgt immer von denen,die auch die Arbeit erledigen werden.

Überwachung der Zielerreichung

Die verbleibende Arbeit zur Erreichung eines Ziels kann jederzeitaufsummiert werden. Der Product Owner vermerkt diese gesamte ver-bleibende Arbeit mindestens zu jedem Sprint Review. Er vergleichtdiesen Betrag mit der verbleibenden Arbeit in früheren Sprint Re-views, um den Fortschritt der Arbeiten im Verhältnis zur restlichenZeit zu begutachten. Diese Information wird allen Stakeholdern prä-sentiert.


1 Der Scrum Guide

Zur Fortschrittsprognose werden diverse Planungspraktiken einge-setzt, wie Burndown- oder Burnupdiagramme. Diese haben sich alsnützlich erwiesen, allerdings schmälern sie nicht die Bedeutung desempirischen Vorgehens. In komplexen Umgebungen lassen sich zu-künftige Ereignisse nicht vorherbestimmen. Nur was bereits gesche-hen ist, gibt Anhaltspunkte für die zukunftsgerichtete Entscheidungs-findung.

Sprint Backlog

Das Sprint Backlog ist die Menge der für denSprint ausgewählten Product-Backlog-Einträge,ergänzt um einen Plan, um das Produktinkre-ment zu liefern und das Sprint-Ziel zu erreichen.Das Sprint Backlog ist eine Prognose des Ent-wicklungsteams darüber, welche Funktionalitätim nächsten Inkrement enthalten sein wird, so-

wie über die erforderliche Arbeit, um diese Funktionalität in einemfertigen [„Done“] Inkrement zu liefern.

Das Sprint Backlog macht die gesamte Arbeit sichtbar, die das Ent-wicklungsteam für notwendig erachtet, um das Sprint-Ziel zu errei-chen. Um kontinuierliche Verbesserungen zu gewährleisten, umfasstes mindestens eine wichtige Prozessverbesserung, die in der vorhe-rigen Retrospektive identifiziert wurde.

Das Sprint Backlog ist ein ausreichend detaillierter Plan, um denFortschritt innerhalb des Sprints im Daily Scrum erkennen zu kön-nen. Das Entwicklungsteam passt das Sprint Backlog während desSprints an; das Sprint Backlog entwickelt sich so während des Sprints.Diese Entwicklung erfolgt, während das Entwicklungsteam den Planabarbeitet und mehr über die noch benötigten Schritte zur Errei-chung des Sprint-Ziels lernt.


Scrum Artefakte

Wenn weitere Arbeiten erforderlich sind, werden sie vom Entwick-lungsteam zum Sprint Backlog hinzugefügt. Wenn eine Arbeit durch-geführt wird oder abgeschlossen wurde, wird die Schätzung der ver-bleibenden Arbeit aktualisiert. Wenn sich Bestandteile des Plans alsunnötig erweisen, werden sie entfernt. Nur das Entwicklungsteamkann sein Sprint Backlog während des Sprints ändern. Das SprintBacklog ist ein hochgradig sichtbares Echtzeit-Abbild der Arbeit, diedas Entwicklungsteam plant, während des Sprints zu erreichen. Esgehört einzig und allein dem Entwicklungsteam.

Überwachung des Sprint-Fortschritts

Zu jedem Zeitpunkt im Sprint kann die gesamte verbleibende Arbeitan den Sprint-Backlog-Einträgen aufsummiert werden. Das Entwick-lungsteam verfolgt diese gesamte Restarbeit mindestens zu jedemDaily Scrum, um die Wahrscheinlichkeit, das Sprint-Ziel zu errei-chen, sichtbar zu machen. Durch die Nachverfolgung der verbleiben-den Arbeit während des Sprints kann das Entwicklungsteam seinenFortschritt steuern.


1 Der Scrum Guide

Inkrement

Das Inkrement ist das Ergebnis aus allen in einemSprint fertiggestellten Product-Backlog-Einträgenund dem Resultat der Inkremente aller früherenSprints. Am Ende eines Sprints muss das neue In-krement fertig [„Done“] sein; das heißt es muss ineinem verwendbaren Zustand sein und die Defini-

tion of Done des Teams erfüllen. Ein Inkrement ist ein Gegenstandinspizierbarer, fertiger [„Done“] Arbeit, der die Empirie am Ende desSprints unterstützt. Das Inkrement ist ein Schritt in Richtung einerVision oder eines Ziels. Es muss auch dann im einsatzfähigen Zu-stand sein, wenn der Product Owner es aktuell noch gar nicht aus-liefern will.

Transparenz der Artefakte

Scrum basiert auf Transparenz. Entscheidungen zur Wertoptimierungund Risikokontrolle werden auf der Basis des festgestellten Zustandsder Artefakte vorgenommen. Diese Entscheidungen haben in demMaß eine solide Basis, in dem die Transparenz der Artefakte um-fassend ist. Bei einer unvollständigen Transparenz können Entschei-dungen auf Sand gebaut sein, Wert kann gemindert und das Risikoerhöht werden.

Der Scrum Master muss mit dem Product Owner, dem Entwicklungs-team und anderen Beteiligten herausfinden, ob die Artefakte wirk-lich vollkommen transparent sind. Es gibt Methoden für den Um-gang mit fehlender Transparenz; der Scrum Master muss jedem da-bei helfen, die bestmöglichen Praktiken zu finden und anzuwenden,wenn vollständige Transparenz nicht gewährleistet werden kann. EinScrum Master spürt mangelnde Transparenz durch die Überprüfungder Artefakte, die Erkennung von Mustern, intensives Zuhören, und


Transparenz der Artefakte

die Erkennung von Abweichungen zwischen den erwarteten und dentatsächlichen Resultaten auf.

Die Aufgabe des Scrum Masters ist es, mit dem Scrum-Team undder Organisation an der Verbesserung der Transparenz der Artefaktezu arbeiten. Diese Arbeit bedeutet zumeist Lernen, Überzeugen undVerändern. Transparenz fällt einem nicht in den Schoß, sie ist einWeg, den es zu beschreiten gilt.

Definition of „Done“

Es müssen alle verstehen, was „Done“ bedeu-tet, sobald ein Product-Backlog-Eintrag oder einProdukt-Inkrement als „Done“ bezeichnet wird.Obwohl sich dies erheblich von Scrum-Team zuScrum-Team unterscheiden kann, müssen alleTeammitglieder ein gemeinsames Verständnis da-von haben wann Arbeit fertig ist, um Transparenzzu gewährleisten. Dies erfolgt durch die Definitionof Done des Scrum-Teams und wird dazu verwen-det festzustellen, wann die Arbeit an einem Produktinkrement fertigist.

Die gleiche Definition leitet das Entwicklungsteam bei der Entschei-dung, wie viele Product-Backlog-Einträge es während des Sprint Plan-nings selektieren kann. Der Zweck eines jeden Sprints ist es, Inkre-mente potentiell auslieferbarer Funktionalität zu liefern, die der ak-tuellen Definition of Done des Scrum-Teams entsprechen.

Entwicklungsteams liefern jeden Sprint ein Inkrement an Produkt-funktionalität. Dieses Inkrement ist vollständig verwendbar, so dassder Product Owner sich jederzeit dazu entscheiden kann, es zu re-leasen. Wenn die Definition of Done für ein Inkrement Teil der Kon-ventionen, Standards oder Richtlinien der Entwicklungsorganisationist, müssen alle Scrum-Teams diese als Minimalziel befolgen.


1 Der Scrum Guide

Wenn „Done“ für ein Inkrement nicht Teil der Konvention der Ent-wicklungsorganisation ist, muss das Entwicklungsteam des Scrum-Teams eine für das Produkt geeignete Definition of Done formulieren[Anm. d. Übers.: Das heißt nicht, dass Product Owner und ScrumMaster nicht eingebunden werden]. Wenn es mehrere Scrum-Teamsgibt, die am selben System- oder Produktrelease arbeiten, müssenalle Entwicklungsteams aller Scrum-Teams gemeinsam eine Defini-tion of Done erstellen.

Jedes Inkrement ist additiv zu allen früheren Inkrementen und gründ-lich getestet, um sicherzustellen, dass alle Inkremente gemeinsamfunktionieren.

Von gereiften Scrum-Teams wird erwartet, dass sie ihre jeweilige Defi-nition of Done erweitern, um strengere Kriterien für eine höhere Qua-lität sicherzustellen. Neue Einträge in der Definition of Done könnendazu führen, dass noch zu erledigende Arbeit in früheren „Done“Produktinkrementen aufgedeckt wird. Jedes einzelne Produkt oderSystem sollte eine Definition of Done haben, welche den Standardfür jegliche daran durchgeführte Arbeit darstellt.

Schlussbemerkung

Scrum ist kostenlos und wird in Form dieses Guides angeboten. DieRollen, Artefakte, Ereignisse und Regeln von Scrum sind unverän-derlich. Es ist zwar möglich, nur Teile von Scrum einzusetzen – dasErgebnis ist dann aber nicht Scrum. Scrum existiert nur in seinerGesamtheit und funktioniert sehr gut als Container für andere Tech-niken, Methoden und Praktiken.

Danksagungen


Schlussbemerkung

Menschen

Von den tausenden Menschen, die zu Scrum beigetragen haben, soll-ten wir diejenigen besonders hervorheben, die für Scrum in seinenAnfängen von besonderer Bedeutung waren. Jeff Sutherland arbei-tete mit Jeff McKenna sowie John Scumniotales, und Ken Schwaberarbeitete mit Mike Smith sowie Chris Martin – und alle arbeitetenzusammen. Viele weitere haben in den folgenden Jahren einen Bei-trag geleistet. Ohne deren Hilfe wäre Scrum nicht so ausgefeilt, wiees heute ist.

Historie

Ken Schwaber und Jeff Sutherland haben Scrum gemeinsam zumersten Mal auf der OOPSLA Konferenz 1995 präsentiert. Diese Prä-sentation dokumentierte im Kern die Erkenntnisse, die Ken und Jeffin den vorher vergangenen Jahren bei der Anwendung von Scrumgewonnen hatten.

Die Geschichte von Scrum wird an anderer Stelle beschrieben. ZurWürdigung der ersten Orte, an denen Scrum ausprobiert und ver-feinert wurde, möchten wir hier Individual, Inc., Newspage, FidelityInvestments und IDX (heute GE Medical) hervorheben.

Der Scrum Guide dokumentiert Scrum, so wie es seit über 20 Jah-ren von Jeff Sutherland und Ken Schwaber konzipiert und weiterent-wickelt wird. Andere Quellen liefern Ihnen Modelle, Prozesse undEinsichten, die das Rahmenwerk von Scrum ergänzen. Damit lassensich die Produktivität, der Wert, die Kreativität und der Stolz auf dasErreichte beständig erhöhen.


1 Der Scrum Guide

Übersetzung

Dieser Guide wurde von der englischen Originalversion, bereitgestelltvon Ken Schwaber und Jeff Sutherland, übersetzt. Beigetragen zurÜbersetzung haben:

2011 Dominik Maximini, Andreas Schliep, Ulf Schneider, Wolfgang Wiedenroth

2013 Jan Gretschuskin, Dominik Maximini, Pascal Naujoks, Sabrina Roos, AndreasSchliep, Wolfgang Wiedenroth

2017 Jan Gretschuskin, Ralph Jocham, Dominik Maximini, Stefan Mieth, Wolf DieterMoggert, Pascal Naujoks, Urs Reupke, Andreas Schliep, Harald Schlindwein,Boris Steiner

Lizenz

©2017 Ken Schwaber and Jeff Sutherland. Offered for license underthe Attribution Share-Alike license of Creative Commons, accessi-ble at http://creativecommons.org/licenses/by-sa/4.0/legalcode and al-so described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agreethat you have read and agree to be bound by the terms of the Attri-bution Share-Alike license of Creative Commons.


2 Sieben Praktiken für dieeffektiveScrum-Implementierung

Peter Beck

In diesem Text lernst Du: Warum Scrum die besten Prinzipienfür effektives Change Management bietet // Wie Scrum die Or-ganisation herausfordert // Die wichtigsten Erfolgsfaktoren fürdie Implementierung von Scrum // Zwischen etwas zu verste-hen, und es umsetzen können, liegen oft Welten. Sie verste-hen Scrum vielleicht schon ziemlich gut und haben ihr erstesScrum-Projekt erfolgreich abgeschlossen. Jetzt fragen Sie sich“Wie bringe ich Scrum in meine Organisation ein?”

Dieser Artikel wurde zunächst auf der Online-Plattform für Agi-les Management, P–A–M (www.p-a-m.org) veröffentlicht.

Jede Organisation ist einzigartig, daher wirst Du keine “Standardlö-sung” finden. Ihr müsst Deinen Scrum-Implementierungsansatz aufdie speziellen Bedürfnisse eurer Organisation anpassen. Zum Glückgibt es heute einen umfangreichen Schatz an Kenntnissen und Er-fahrungen über Scrum-Implementierungen — und anscheinend sindeinige Praktiken essentieller als andere für eine effektive und erfolg-reiche Scrum-Einführung.

Diese sieben Praktiken für eine effektive Scrum-Implementierunggeben euch immer noch nicht die Lösung für alle Probleme an dieHand. Einige davon sind für eure Organisation vielleicht wichtigerals andere. Andere spezifische und für eure Organisation bedeut-same Praktiken fehlen wahrscheinlich. Dennoch kann diese Auflis-tung euch Vorteile beim Start mit Scrum verschaffen — dem erstenScrum-Prinzip gemäß: “Liefere frühzeitig und regelmäßig”. Ermittle,

2 Sieben Praktiken für die effektive Scrum-Implementierung

welche dieser Praktiken euch weiterhelfen und Mehrwert für eure Or-ganisation erbringen. Lasst Praktiken aus — oder erarbeitet eigene,bessere.

Folge den Prinzipien

Die beste Ausgangsbasis für die Weiterentwicklung von Scrum istScrum selbst. Alle Maßnahmen, die ihr für die Einführung von Scrumin eurer Organisation benötigt, sollten den Scrum-Prinzipien folgen:

• Liefere frühzeitig und regelmäßig

• Überprüfe und adjustiere

• Baue ermächtigte, selbstorganisierte Teams auf

• Sei transparent und offen

• Nutze Time-Boxen für alle Aktivitäten

Scrum wurde entwickelt, um die Entwicklung komplexer Systemezu unterstützen. Organisationen sind komplex; die Implementierungvon Scrum in traditionellen Umfeldern ist sogar noch komplexer. DiePlanung und Umsetzung von organisatorischen Änderungen mit demScrum-Rahmenwerk garantiert euch die kontinuierliche Lieferung.Ihr gewinnt an Vertrauen innerhalb eures Umfeldes, weil der neueAnsatz Resultate bringt. Zudem sendet ihr die richtigen Signale aus:“Wir vertrauen auf und nutzen den neuen Ansatz, und wir sehen,dass er funktioniert.”


Beginnt mit einem dringenden und wichtigen Projekt

Beginnt mit einem dringenden undwichtigen Projekt

Wir setzen Scrum nicht zum Selbstzweck ein, sondern um ein besse-res Produkt auf effizientere Weise zu liefern. Scrum sollte uns dabeihelfen, Projektziele in kürzerer Zeit mit weniger Kosten zu erreichen.Die Frage ist nicht, “was können wir für Scrum machen”, sondern“Was kann Scrum für uns machen?”. Was fehlt, wo ist ein Fehlschlagam schmerzvollsten, wo sehen wir den höchsten Wert für unsere Or-ganisation? Das sind die Ansprüche, die ihr an ein Pilotprojekt mitScrum stellen solltet.

Die Scrum-Implementierung und das Projekt profitieren voneinan-der. Wenn das Projekt bedeutsam genug ist, ist die Umsetzung dererforderlichen Organisationsänderungen wesentlich erleichtert. Dassteigert den Wert des Projekts, nicht des Vorgehensmodells.

Ihr macht euch vielleicht jetzt Gedanken über Risiken. Was passiert,wenn wir scheitern? Natürlich ist jedes Projekt mit Risiken behaftet,die identifiziert und gemildert werden müssen. Aber Scrum hilft euchdabei, indem es kontinuierlich dazu beiträgt, Risiken aufzuzeigen.So werdet ihr auf jeden Fall frühzeitig herausfinden, ob das Projektvom Scheitern bedroht ist – was euer Vertrauen in Scrum eher nochbestärken wird. Es wird transparent, ob euer Projektziel im zeitlichenoder finanziellen Rahmen liegt. Die Wahrheit ist manchmal hart. Ihrmüsst nur Sorge dafür tragen, dass niemand diese Tatsache fehlin-terpretiert und versucht, Scrum als Sündenbock zu nutzen.



Arbeite mit den richtigen Menschen – nimmdie Pioniere

Es ist kein Geheimnis, dass der Erfolg eines Projekts maßgeblichdavon abhängt, die richtigen Leute an Bord zu haben. Insbesonderebei Ihren ersten Scrum-Projekten solltet ihr dafür sorgen, dass ihragile Pioniere an Bord habt, die:

• willens sind, alte Gewohnheiten abzulegen,

• willens sind, neue Techniken zu lernen und zu benutzen,

• willens sind, Regeln zu brechen,

• begeistert von Scrum und Agile sind,

• sich 100% dem Team zugehörig fühlen

Natürlich sollten eure ausgewählten Teammitglieder das bestmögli-che Wissen in ihrem Arbeitsbereich haben. Dies betrifft sowohl tech-nisches als auch betriebswirtschaftliches Wissen. Allerdings ist einGroßteil dieses Wissens nicht entscheidend für komplexe Projekte– andernfalls wären sie nicht komplex. Daher sollten Sie vorhan-denes Wissen nicht überbewerten. Euer Team muss durch bisherunerforschte Bereiche gehen. Dazu kommt, dass es nun im Mittel-punkt steht: Werden Scrum und das Team gewinnen oder verlieren?Ihr müsst auf vielen Ebenen gleichzeitig spielen. Es gibt natürlicheSchwierigkeiten in eurem Projekt und versteckte Kräfte, die gegeneuer neues Vorgehen arbeiten. Spielt dieses Spiel nicht ohne dieBesten.

Ein sehr guter Weg, die Besten zu finden, ist dass ihr euch undeuer Projekt finden lasst. Bewerbt einfach das neue Vorgehen undstellt dar, dass ihr nach Pionieren sucht. Gebt zum Beispiel einen 4-stündigen Scrum-Einführungsworkshop und stellt sicher, dass jederin Ihrer Organisation die Möglichkeit hat, daran teilzunehmen. Fragt


Arbeitet mit einem Sponsor

am Ende, wer gerne morgen mit diesem Vorgehen anfangen würde.Schon habt ihr Kandidaten.

Wenn euer erstes Scrum-Projekt vorbei ist, werden die Pioniere trotz-dem noch gebraucht. Diese sollten ihr Wissen an den Rest der Orga-nisation weitergeben. Vielleicht sind einige einem Scrum-Einführungs-oder Verbesserungsteam mit der Absicht beigetreten, Scrum in dergesamten Organisation einzuführen oder schwierige organisatorischeVeränderungen durchzuführen. Andere werden den nächsten Scrum-Teams beitreten.

Arbeitet mit einem Sponsor

Der Erfolg jeder Scrum-Einführung wird am Ende seinen Meister inseinem Sponsor finden. Der Sponsor ist jemand, der stark in die Or-ganisation eingebunden ist, große Entscheidungskompetenz hat unddie Führungsstrategie beeinflusst. In den meisten Fällen ist dies derCEO, CTO oder jemand, der diesen sehr nahe ist.

Einige Organisationen können nicht mit einem solch mächtigen Spon-sor starten. Allerdings wird Scrum die Führungsetage sehr früh nachdem Start der ersten Scrum-Teams herausfordern. In dem Fall, dassdu nicht in einer mächtigen Position bist, versuche, eine gute Per-son dafür zu finden, sie dafür vorzubereiten, Sponsor der Scrum-Einführung zu werden.

Der Sponsor ist für Priorisierung und Entscheidungen über notwendi-ge Verbesserungen und Änderungen der Schwierigkeit zuständig. Esist ein guter Weg, diesen Sponsor zum Product Owner eines Scrum-Einführungs- oder Verbesserungsteams zumachen. Dieses Team über-nimmt die Aufgabe, die organisatorischen Änderungen mithilfe vonScrum mit voller Unterstützung des Sponsors durchzuführen. Zu-sammen mit dem Sponsor entwickelt dieses Team eine Strategie fürdie Einführung von Scrum in der Organisation. Es sollte außerdem



eine Scrum-Einführungs- und Verbesserungs-Architektur entwickeltwerden, die sich an den Bedürfnissen der Organisation orientiert.Das folgende Bild reduziert solch eine Struktur auf ein einzelnesBild. Denk daran: jede Organisation ist anders. Daher benötigt je-de Organisation ihren spezifischen Aufbau. Vergiss außerdem nicht,euer Vorgehen zu untersuchen und anzupassen.

Improvement Charter and Vision

Strategic Improvement

Backlog / Kanban

Team and Produkt Backlogs

Sponsor / Executive Management Participation Overall Retrospective

Go and SeeReplenishment Improvement Kanban

ScrumMaster / Coaches Communities (Team Representatives)

Overall Retrospective

Scrum Teams Team Retrospectives

Organisation Impediments

Cross Team Impediments

Team ImpedimentsAgile

Tra

nsiti

on A

rchi

tect

ure

Bezieht das mittlere Management ein

Normalerweise kommt der größte Widerstand gegen Scrum aus demmittleren Management, da diese Gruppe Verlust am meisten fürch-tet. Und sie haben Recht, da Scrum dahin tendiert, die Hierarchieabzuflachen. Menschen immittleren Management werden ihre Diens-te, Verantwortungen und Führungsmethoden drastisch ändern müs-sen.

Durch das Einbeziehen dieser Gruppe in die Wandlung in eine hoch-effiziente Scrum-Organisation kannst du Widerstand in Unterstüt-zung wandeln. Und wieder: Frag dich, wer in den Prozess einbezo-gen wird und wer dem Fortschritt im Weg steht. Das Abflachen der


Trainiert eure Mitarbeiter und bietet Unterstützung an

Hierarchie bedeutet nicht zwangsläufig die Verringerung der Mitar-beiterzahl, aber es ist eine Tatsache, dass einige die Organisationverlassen und neue Mitarbeiter kommen werden.

Bereitet eure Organisation darauf vor, dass jede Veränderung eineMöglichkeit ist – sogar für jene, welche dadurch die Organisationverlassen.

Trainiert eure Mitarbeiter und bietetUnterstützung an

Wir kennen das vom Sport: Ohne Training sollten wir nicht zum Spielgehen. Das trifft auf dieses neue Spiel – Scrum – zu. Wir müssenMuskeln und Reflexe trainieren, die selten oder nie zuvor benutztwurden. Andererseits sind andere Muskeln gut entwickelt und hin-dern uns daran, uns passend zu den neuen Spielregeln zu bewegen.

Erklärt den Mitarbeitern die neuen Regeln, bevor ihr die Einführungvon Scrum beginnt. Gebt bewährte Methoden weiter, damit die rich-tigen Muskeln und Reflexes bereit sind für den ersten Sprint. Es istwichtig, dass jeder Stakeholder zumindest mit den Scrum-Regelnvertraut ist. Andernfalls könnt ihr sicher sein, dass jemand diesebricht. Spezielles Training für spezifische Rollen ist dabei wenigerwichtig und kann später angeboten werden.

Bei Scrum wird früh geliefert. Nach einem kurzen Training solltet ihrfür den Start bereit sein. Jedoch sind viele Dinge noch unklar unddie wirklich großen Fragen treten während der ersten Sprints auf.Ihr solltet euren Teams Unterstützung und Hilfe anbieten. Führungdurch einen Scrum-erfahrenen Mitarbeiter oder Coach erhöhen dasVertrauen, das nötig ist, um mit Scrum zu beginnen und lässt zu,dass das Team sich auf die wirkliche Herausforderung konzentriert:das Projekt.



Ja, du weißt es bereits: jede Organisation ist anders, jede Organisati-on benötigt einen speziellen Trainingsplan. Und ja, du musst diesenPlan auch anpassen, aber du findest hier ein Beispiel:

Coaching

Coaching

Coaching

Product Owner

ScrumMaster

Development Team

ManagementIntro

duct

ion

Mana

gem

ent

Scru

m R

eadi

ness

Wor

ksho

p

Sprint 1

Kick

-off

Scru

m

stee

ring

grou

p

Scru

m

Work

shop

HR,

Lin

e Mgm

t.

Work

shop

Sc

rum

PM

Certified ScrumMaster

Training

Certified Product Owner

Training

Scrum Team

Training

Clean-up

Coaching Scrum Implementation

Agile Facilitation Training

Agile Planning and Estimation

XP / Agile Engineering

Practices

Sprint 2 Sprint 3

Richtiges Marketing

Scrum hilft euch, großartige Produkte zu entwickeln und gute Pro-dukte sind die beste Werbung, die ihr haben könnt. Aber wenn eurepotenziellen Kunden nicht verstehen, dass ihr ein gutes Produkt an-bietet, werden sie auch nichts kaufen. Daher benötigt ihr auch gutesMarketing.

Dieselbe Logik trifft auch auf eure Scrum-Einführung zu. Die besteWerbung ist es, erfolgreich zu sein. Allerdings müsst ihr auch dar-über nachdenken, wie ihr euren Erfolg in der Organisation verkau-fen könnt. Ihr müsst Widerstand und Angst überwinden. Dies jedoch


Richtiges Marketing

nicht nur mit Argumenten. Ihr müsst vielmehr darüber nachdenken,wie ihr eure Argumente präsentiert, zum richtigen Zeitpunkt mit derrichtigen Sprache den richtigen Personen vorbringen.

Transparenz und Offenheit bedeuten nicht, dass ihr jedem wahllosalles erzählen solltet. Denkt darüber nach, wer eure Nachricht ‘kon-sumiert’. Denkt über seinen Wohlfühlbereich nach und wie ihr ihnherausfordern können, ohne eine Blockade zu erschaffen.

Hier ist eine einfache, von Marketing-Experten geliehene Technik,um Hindernisse in akzeptierbare Lösungen zu wandeln:

• Findet die spezifische Situation, in der das Hindernis beobachtet wurde (nie-mand kann Fakten leugnen)

• Interpretiert (das bedeutet, ihr könnt falsch liegen, aber Fakt ist Fakt)

• Bietet zwei Lösungen an: A und B (der Trick ist, dass man entweder A oder Bwählen kann, aber nicht keins von beiden)


3 Neun Übungen fürerfolgreiche Retrospektiven

Andreas Schliep

Hier geht es um Die besondere Bedeutung der Retrospektive //Eine Reihe von Übungen zum Ausprobieren und Modifizieren //Wege, die Zusammenarbeit im Team zu verbessern // Eintönigkeits-Gegenmittel

Dieser Beitrag basiert auf Materialien der berufsbegleitendenScrumMaster-Ausbildung – www.scrummaster-ausbildung.de

Die Retrospektive ist die Kür des Scrum Masters. Während die an-deren Mitglieder des Scrum Teams schon nach kurzer Zeit gut durchdie Planungen, Abstimmungen und Reviews kommen, erfordert dieRetrospektive stets eine speziell vorbereitete Moderation. Die hierdargestellten Übungen haben wir in unserer Praxis als Scrum Mas-ter und Coach in den verschiedensten Teamkonstellationen und Si-tuationen eingesetzt. Natürlich gibt es noch viel mehr Übungen zuentdecken. Dazu empfehlen wir zur Vertiefung diese Lektüre:

• Esther Derby und Diana Larsen: Agile Retrospectives

• Marc Löffler: Retrospektiven in der Praxis

• Corinna Baldauf: Retr-O-Mat – www.plans-for-retrospectives.com

Einsatz der Übungen

Die meisten der hier dargestellten Übungen lassen sich als kleine, ei-genständige Retrospektiven durchführen oder zu einer größeren Re-

3 Neun Übungen für erfolgreiche Retrospektiven

trospektive zusammenstellen. Dabei hilft eine Zuordnung der Übun-gen zu den bei Derby und Larsen beschriebenen Schritten:

Übung Bühnebereite

n

Inform

ationensammeln

Einsichten

gewinnen

Aktio

nenplanen

Abschluss

Was lief gut... X XZeitleisteSeestern X X XEmotionale Trendlinie X XForscher, Shopper, ... XTeamhistogramm X XTeamradar X X XLob und Dank X XHilfreich, behindern... X X X


Übung: Was lief gut / was können wir verbessern

Übung: Was lief gut / was können wirverbessern

Englisch: What went well / what could be improvedQuelle: Ken Schwaber, Agile Project Management with ScrumDauer: 20–60 Minuten

Material

• Flipchart oder Pinnwand

• Haftnotizen oder Moderationskarten

• Moderationsmarker

Vorbereitung

Der ScrumMaster organisiert einen Meetingraum und stellt das Flip-chart bzw. die Pinnwand bereit. Die Arbeitsfläche wird in zwei Sek-tionen unterteilt, die jeweils die Überschriften „Was lief gut“ und„Was können wir verbessern“ erhalten. Einige ScrumMaster verwen-den auch einfach Smileys.

Für jeden Teilnehmer wird ein Stapel Haftnotizen oder Moderations-karten sowie ein Moderationsmarker oder sonstiger dicker Stift be-reitgelegt.

Ablauf

1. Bitte die Teilnehmer, an den letzten Sprint zurückzudenken.



2. Die Teilnehmer sollen jeweils je Notiz / Karte etwas schreiben, was aus ihrerSicht im vergangenen Sprint gut gelaufen ist oder verbessert werden könnte.

3. Die Notizen oder Karten werden auf der Arbeitsfläche gesammelt. Dabei werdensie gleich in die entsprechenden Sektionen einsortiert.

4. Schreibe auf ein weiteres Flipchart, was verbessert werden sollte.

Varianten

1. Die Teilnehmer sammeln zunächst nur die Dinge, die gut gelaufen sind. Diesewerden an der Arbeitsfläche angebracht und kurz besprochen. Dann erfolgt einweiteres Brainstorming mit den zu verbessernden Dingen.

2. Jeder Teilnehmer stellt seine Karten beim Anbringen an der Arbeitsfläche selbstvor.

3. Man kann auch mehr als zwei Kategorien nehmen, zum Beispiel: „try“, „keep“und „drop“ ( Übung: Seestern)

4. Nach der Sammlung werden die verbesserungswürdigen Themen von den Teil-nehmern per Dot-Voting priorisiert.

Zu beachten

Diese Übung führt schon zu recht brauchbaren Resultaten, nutzt sichaber nach einer Reihe von Wiederholungen schnell ab. Als Elementeiner längeren Retrospektive findet sich diese Übung nach der Be-trachtung der Zeitleiste wieder.


Übung: Zeitleiste

Übung: Zeitleiste

Englisch: Retrospective TimelineQuelle: Norman Kerth, Project RetrospectivesDauer: 45 Minuten

Material:

• Flipchart, Pinnwand oder großes Plakat



Vorbereitung

Der ScrumMaster organisiert einen Meetingraum und stellt das Flip-chart bzw. die Pinnwand bereit. Auf der Arbeitsfläche wird ein waage-rechter Pfeil gezeichnet. Der Anfang des Pfeils wird mit dem Sprint-Start oder einem anderen signifikanten Datum beschriftet. Das Endedes Pfeils wird dementsprechend mit dem Sprint-Review beschriftet.

Ablauf




2. Die Teilnehmer sollen je Notiz / Karte ein Ereignis des letzten Sprints schreiben.Das Ereignis sollte eine Bedeutung für das Teammitglied oder Team haben.Dabei sollte möglichst auf eine Wertung verzichtet werden.

3. Wenn die individuelle Sammlung abgeschlossen ist, bringen die Teilnehmer dieEreignisse an der Zeitleiste an. Dabei erläutert jeder Teilnehmer seine Kartenkurz.

4. Während der Vorstellung werden Dinge, die man verbessern könnte, Rätsel,aber auch brauchbare Vorgehensweisen separat gesammelt.

Varianten

• Die Zeitleiste wird in der Mitte eines Flipcharts gezeichnet. Positive Ereignissewerden oberhalb der Leiste, negative darunter gesammelt. Dadurch entstehtein emotionales Seismogramm des vergangenen Sprints.

• Beim Anbringen der Ereignisse wird noch nicht gesprochen. Wenn alle Ereig-nisse angebracht sind, geht der Moderator in der zeitlichen Reihenfolge durchden Zeitstrahl und fragt die Teilnehmer nach ihrer Einschätzung der jeweiligenBeobachtungen.


Übung: Seestern

Übung: Seestern

Englisch: Retrospective StarfishQuelle: Patrick Kua, BlogDauer: 45 Minuten

Material






Vorbereitung

Der ScrumMaster organisiert einen Meetingraum und stellt das Flip-chart bzw. die Pinnwand bereit. Auf der Arbeitsfläche wird ein „See-stern“ – siehe Abbildung - gezeichnet. Die dadurch entstehendenSegmente werden mit „mehr“, „weniger“, „anfangen“, „aufhören“und „???“ beschriftet.

Ablauf


2. Die Teilnehmer sollen sich zu den jeweiligen Segmenten Dinge überlegen, vondenen sie „mehr“/„weniger“ wollen, mit denen sie „anfangen“ oder „aufhö-ren“ wollen, und die ihnen Rätsel bereiten.

3. Die einzelnen Punkte werden auf Notizen / Karten geschrieben – ein Punkt proKarte – und in den Segmenten auf der Arbeitsfläche gesammelt.

4. Je nach Anzahl und Aufwand der identifizierten Punkte erfolgt eine Abstim-mung - zum Beispiel durch Punktwertung - über die als erstes zu änderndenoder abzustimmenden Themen.

Varianten

• Der Moderator kann auch die englischen Beschriftungen verwenden: „more of“,„less of“, „start doing“, „stop doing“ und „puzzles“.


Übung: Emotionale Trendlinie

Übung: Emotionale Trendlinie

Englisch: Emotions SeismographQuelle: Norman Kerth, Project RetrospectivesDauer: 10 Minuten

Material


• Moderationsmarker, am besten farbig sortiert

Vorbereitung

Der ScrumMaster organisiert einen Meetingraum und stellt das Flip-chart bzw. die Pinnwand bereit. Auf dieser Arbeitsfläche wird wie bei



der Zeitleiste ein Pfeil gezeichnet, der mit den Eckdaten des letztenSprints beschriftet wird. Zusätzlich wird der Pfeil noch weiter in Wo-chen oder Arbeitstage unterteilt, um die Übersicht zu erhöhen. Überund unter dem Pfeil sollte in etwa gleich viel Platz gelassen werden.

Ablauf


2. Jeder Teilnehmer erhält einen Moderationsmarker.

3. Die Teilnehmer sollen über den Verlauf des ganzen Sprints einzeichnen, wie gutsie sich zu dem jeweiligen Zeitpunkt gefühlt haben.

4. Wenn alle Teilnehmer ihre individuelle Linie gezeichnet haben, zeichnest duden Trend des Sprints als besonders gekennzeichnete Linie nach.

5. Besprecht den Lauf des Sprints. Dabei sind einige Datenpunkte besonders in-teressant:

a. Tiefpunkte, an denen sich die meisten Linienverläufe im unteren Bereichtreffen.

b. Höhepunkte, an denen sich die meisten Linienverläufe im oberen Bereichtreffen.

c. Kontrastpunkte, an denen die Beurteilungen der Teilnehmer besondersdeutlich voneinander abweichen.

Varianten

• Die emotionale Trendlinie lässt sich gut mit der Übung: Zeitleiste kombinieren.


Übung: Forscher, Shopper, Urlauber und Gefangener

Übung: Forscher, Shopper, Urlauber undGefangener

Englisch: ESVP – Explorer, Shopper, Vacationer, PrisonerQuelle: Esther Derby, Diana Larsen: Agile RetrospectivesDauer: 10–15 Minuten

Material

• Flipchart für ein Histogramm

• Haftnotizen oder Moderationskarten für die Abstimmung


Vorbereitung

Der ScrumMaster organisiert einen Meetingraum und stellt das Flip-chart bzw. die Pinnwand bereit.

Ablauf

1. Erkläre den Ablauf.

2. Zeige das Flipchart mit den 4 Begriffen und definiere sie:

• Forscher wollen alle möglichen neuen Ideen und Einsichten entdecken.

• Shopper schauen sich alle vorhandene Information an und freuen sichüber eine nützliche neue Idee.

• Urlauber interessieren sich nicht für die Retrospektive, sind aber glück-lich über die Pause von der täglichen Routine.



• Gefangene fühlen sich zur Retrospektive gezwungen und würden lieberetwas anderes tun.

3. Verteile die „Wahlzettel“ und lass jeden einen Buchstaben F, S, U oder G geheimdarauf schreiben.

4. Mache die Auswertung öffentlich und achte dabei darauf, dass niemand er-kennen kann, von wem welcher Zettel war.

5. Frage die Gruppe: „Was denkt ihr über das Ergebnis?“ Leite eine kurze Diskus-sion darüber, wie diese Einstellungen das Ergebnis der Retrospektive beein-flussen werden.

6. Frage zum Abschluss: „Passen diese Kategorien zu unserer Einstellung zurtäglichen Arbeit?“


Übung: Teamhistogramm mit Perspektivenwechsel

Übung: Teamhistogramm mitPerspektivenwechsel

Englisch: Satisfaction HistogramQuelle: Esther Derby, Diana Larsen: Agile RetrospectivesDauer: 20 Minuten

Material

• Flipchart für ein Histogramm

• Vorbereitetes Flipchart mit den 5 Stufen

• Haftnotizen oder Moderationskarten für die Abstimmung




Vorbereitung

Der ScrumMaster organisiert einen Meetingraum und stellt die Flip-charts bzw. die Pinnwände mit den fünf Stufen bereit.

5. Ich denke, wir sind das beste Team der Welt! Wir arbeiten superzusammen!

4. Ich bin froh, Teil des Teams zu sein, und zufrieden mit unsererZusammenarbeit.

3. Ich bin einigermaßen zufrieden. Wir arbeiten meistens ganzgut zusammen.

2. In manchen Momenten bin ich zufrieden. Aber nicht oft genug.

1. Ich bin unglücklich und unzufrieden mit unserer Zusammen-arbeit.

Ablauf

1. Erläutere den Ablauf.

2. Für eine Abstimmung zu der Frage „Wie zufrieden seid Ihr mit Eurer Leistungals Team?“ erläuterst Du die folgenden 5 Stufen anhand eines vorbereitetenFlipcharts.

3. Sammle die Abstimmungskarten mit den Zahlen der Teilnehmer geheim einund sorge bei der Auswertung dafür, dass niemand die Werte Personen zuord-nen kann.

4. Moderiere das Gespräch über das Ergebnis.


Übung: Team Radar

Übung: Team Radar

Englisch: Team RadarQuelle: Esther Derby, Diana Larsen: Agile RetrospectivesDauer: 15–20 Minuten

Überblick

Diese Übung hilft dem Team sichtbar zu machen wie gut sie in be-stimmten Feldern wie z.B. Treue zu Ihren Teamwerten, Entwicklungs-praktiken oder Kommunikation untereinander sind.

Material

• Flipchart oder Pinnwand mit einem leeren Radar Chart – die Achsen könnenschon beschriftet sein.





Vorbereitung

Der Scrum Master organisiert einen Meetingraum und stellt das Flip-chart bzw. die Pinnwand bereit.

Ablauf

1. Du erläuterst den Ablauf mit den Worten: „Wir stimmen darin überein, dassdiese Felder wichtig für unsere Arbeit sind. Lasst uns herausfinden, wie gutwir dabei auf einer Skala von null bis zehn sind. Null bedeutet

’gar nicht‘ und

zehn bedeutet ‘besser geht es nicht‘“.

2. Bitte jedes Teammitglied, nach vorne zu kommen und einen Klebepunkt aufeinen Wert einer Achse zu setzen.

3. Moderiere eine kurze Diskussion darüber, wie diese Felder die tägliche Arbeitbeeinflussen.

4. Bewahre das fertige Diagramm auf. Mache die selbe Aktivität ein paar Ite-rationen später wieder und vergleiche zusammen mit dem Team die beidenErgebnisse.

Varianten

• Um eine gegenseitige Beeinflussung beim Kleben der Punkte auszuschließen,können die Zahlenwerte auch geheim auf Kärtchen geschrieben werden. Dumalst dann als Moderator nur den Mittelwert an die Achse.

• Für ein größeres Set an Achsen teilst Du einen Fragebogen aus und wertest dasErgebnis nach der Retrospektive mit Hilfe von Excel aus. Das Ergebnis darauswird dann Thema der nächsten Retrospektive sein.


Übung: Lob und Dank

Übung: Lob und Dank

Englisch: (Offer) AppreciationsQuelle: Norman Kerth: Project Retrospectives

Esther Derby, Diana Larsen: Agile RetrospectivesDauer: 5–30 Minuten

Überblick

Erlaube allen Teilnehmern der Retrospektive, sich bei der Gruppeoder einzelnen zu bedanken. Das gibt zum Ende eine positive Grund-stimmung.

Material

• Nichts

Vorbereitung

Die Gruppe sitzt im Stuhlkreis oder steht im Kreis ohne Tisch oderein anderes Hindernis in der Mitte.

Ablauf

1. Führe in die Aktivität durch einen Satz wie z.B. „Jetzt wo wir zum Ende kommen,nutzen wir die Gelegenheit nochmal wahrzunehmen wie andere zum Gelingender Retrospektive beigetragen haben und sprechen unseren Dank dafür aus.“



2. Demonstriere das Formatmit einem Teammitglied. Auch wenn es eine Demons-tration ist, wähle eine Person, der Du ehrlich dankbar bist. Sage den Namenund dann „Ich danke dir für...“ Fülle die Lücke mit etwas über die Person, oderetwas, das sie oder er getan hat. Ein Beispiel wäre: „Andreas, ich danke Dir fürdeine Hilfe beim Verstehen, wie wertvoll gute innere Qualität für unser Produktist.“

3. Setze Dich wieder. Warte. Irgendjemand wird als nächster seinen Dank aus-sprechen. Wenn die Abstände zwischen den Danksagungen länger werden,warte. Lasse die Stille zu. Manche Menschen brauchen Zeit, um sich einenRuck zu geben.

4. Beende die Übung, wenn mehr als eine Minute verstreicht, ohne dass jemandspricht.

Varianten

• Die Übung kann um weitere Abfragen ergänzt werden. Wir verwenden diesenAustausch gerne als „Temperature Reading“:

– Lob und Dank

– Fragen und Antworten

– Beschwerden mit Verbesserungsvorschlägen

– Neue Erkenntnisse und Informationen

– Hoffnungen und Wünsche


Übung: Hilfreich, Behindernd, Hypothesen

Übung: Hilfreich, Behindernd, Hypothesen

Englisch: Helped, Hindered, HypothesisQuelle: Esther Derby, Diana Larsen: Agile RetrospectivesDauer: 5–-10 Minuten

Überblick

Der Retrospektiven-Moderator sammelt Feedback von den Teilneh-mern ein. Ziel ist es herauszufinden was mehr und was wenig hilf-reich beim Lernen war. Daraus entstehen auch neue Ideen für fol-gende Retrospektiven.

Material

• 3 vorbereitete Flipcharts mit Überschiften: „Hilfreich“, „Behindernd“, „Hypo-thesen“

• Haftnotizen


Vorbereitung

Hänge die 3 Flipcharts auf.

Ablauf

1. Zeige die 3 Flipcharts und erkläre: „Bitte helft mir ein besserer RetrospektivenModerator zu werden. Gebt mir Feedback zu dieser Retrospektive. Diese drei



Flipcharts sind für Dinge, die Euch beim Lernprozess geholfen haben, für Dingedie Euch dabei behindert oder gestört haben, und das dritte ist für Ideen, wasich anders machen könnte, um die nächste Retrospektive für Euch effektiver zugestalten. Bitte benutzt die Post-its, um Euer Feedback für mich zu schreiben.Wer möchte, kann seine Initialen in eine Ecke das Zettels schreiben, falls icheine Rückfrage dazu habe.“

2. Gib der Gruppe Zeit, die Zettel zu schreiben und aufzuhängen.

3. Beende die Übung mit einem Dank an die Gruppe.

Zu beachten

Neben der Verbesserung für Dich und Deine Retrospektiven offenbartdie Übung unter Umständen auch Informationen über die (unter-schiedlichen?) Ziele und Vorstellungen der einzelnen Teammitgliederund dient damit auch der Reflektion für die Gruppe selber.


4 Scrum CoachingPeter Beck und Andreas Schliep

Die Stärke von Scrum ist dessen Einfachheit. Diese Einfachheit täuschtaber häufig über die tatsächlichen Anforderungen bei der Einführunghinweg, da die Grundprinzipien von Scrum darauf abzielen, stetigVeränderungen in der Organisation zu bewirken. Insbesondere bei derEinführung von Scrum sind diese Veränderungen sehr komplex. Ver-antwortungen verlagern sich, Teams formieren sich um, Arbeitswei-sen werden angepasst und Führungsaufgaben müssen neu überdachtwerden. Für einige steht die positive Energie der Aufbruchsstimmungim Vordergrund, für andere sind es Unsicherheit und Angst. Beidessind notwendige Strömungen bei Veränderungen in einer funktionie-renden Organisation und müssen verstanden und genutzt werden.

Die Komplexität einer Scrum-Einführung bedarf eines breiten Spek-trums differenzierter Maßnahmen, die wir alle erfolgreich erprobt ha-ben. Unsere Beobachtung hat dabei gezeigt, dass diese sich in einan-der aufbauenden Ebenen einordnen lassen. Diese Ebenen sind nichtstreng voneinander getrennt, helfen aber die Maßnahmen besser zuverstehen und einzuordnen.

Abholung

Training

Transfer

Ausgleich

Wachstum

Ziele

Prozess

AuftragErfolge

4 Scrum Coaching

Prozess

Eine Scrum-Einführung ist ein komplexes Vorhaben. Also genau dasrichtige Einsatzgebiet für Scrum. Kein Wunder also, dass wir Scrumverwenden, um Scrum einzuführen. Je nach Situation, Bedarf undNotwendigkeit gewichten wir gemeinsam mit unserem Kunden dieMaßnahmen jeder Ebene. Die Maßnahmen werden in regelmäßigenAbständen geplant, durchgeführt und verifiziert. Natürlich lernenund verbessern wir den Prozess auch bei einer Scrum-Einführungdurch Retrospektiven. Je nach Größe und Komplexität empfehlenwir ein multidisziplinäres Team, zusammengesetzt aus externen Trai-nern, Coaches und Mitarbeitern der Organisation, um die Einführungvon Scrum zu begleiten.

Nicht selten beginnen wir den Prozess mit einer Team- oder Projekt-Retrospektive oder mit der Analyse der Ist-Situation. Mit dem Auf-traggeber werden Ziele definiert und daraus geeignete Maßnahmenabgeleitet, welche in einer Coaching-Iteration umgesetzt werden sol-len. Der Erfolg und die Wirkung der Maßnahmen wird am Ende ei-ner jeder Coaching-Iteration evaluiert. Die gewonnenen Erkenntnissefließen dann in die Planung der nächsten Iteration mit ein.

Uns liegt besonders das Verhältnis von Auftraggeber und Coaches amHerzen. Letztendlich liegt hier der Kern des Erfolges jedes Coaching-Vorhabens. Klare, messbare Ziele bei Auftragsvergabe, Anpassung anden tatsächlichen Bedarf und ein von Anfang an festgelegtes Aus-trittszenario garantieren, dass die Organisation selbst Verantwortungfür die Verbesserungen übernimmt und erfolgreich weiterführt.

Abholung

Es gibt viele Motivationen Scrum einzuführen. Bei der Abholung öff-nen wir den breiten Bogen der Wünsche, Erwartungen, Hoffnungen


Training

und Befürchtungen, um sie in den Prozess einfließen zu lassen.Außerdem definieren wir gemeinsame Ziele, die wir später bei derEvaluierung als Realitätscheck verwenden. Vorträge, Großgruppen-Veranstaltungen aber auch Einzelgespräche sind entsprechende Maß-nahmen, um ein realistisches Bild der Ausgangslage, ein Verständnisüber das Veränderungspotenzial und eine gemeinsame Zielsetzungzu erarbeiten.

Training

Die Scrum Trainings schaffen eine gemeinsame Wissensbasis in denTeams und untermauern das Rollenverständnis von ScrumMaster,Product Owner und Team. Neue Methoden, Techniken werden ein-geübt und im “Rückenmark” gespeichert. Altes wird über Bord ge-worden und erfolgreich “verlernt”. Das Scrum Team Jumpstart Trai-ning bildet oft die Grundlage und wir empfehlen, dass das gesamteScrum Team an einem solchen Training teilnimmt. Natürlich kön-nen die Teilnehmer bei uns den Certified ScrumMaster oder Certi-fied Product Owner erwerben. Weiterführende und rollenspezifischeKurse runden das Angebot ab.

Transfer

Nach den Trainings unterstützen wir als Coaches den Transfer desGelernten in die tägliche Praxis. Wir begleiten Ihre Teams mit ei-ner Mischung aus systemischer Grundhaltung, fachlicher Beratungund Trainingselementen. Ziel ist dabei, dass die Mitarbeiter selbstdie Verantwortung für den Transfer übernehmen. Nur dann kann ge-währleistet werden, dass die vereinbarten Veränderungen tatsäch-lich gelebt werden. Typische Transfermaßnamen sind der “Scrumbei uns”-Workshop oder die ScrumMaster-Gruppe.


4 Scrum Coaching

Ausgleich

Scrum-Einführungen decken oft Lücken in Organisationen auf, die“von innen heraus” nicht geschlossen werden können. Wir legen vielWert darauf, dass diese Lücken nicht “implizit” kompensiert wer-den. Die Kompensation dieser Lücken würde Probleme verdeckenund so den Lernprozess behindern. Gleichzeitig ist der Ausgleichvon Lücken mit qualifizierten ScrumMastern, Moderatoren und Pro-jektmitarbeiten aber notwendig um Vertrauen in den neuen Ansatzaufzubauen, Erfolge zu feiern und die Befruchtung mit neuen Ideenvon Außen zuzulassen. Ausgleich findet in Mentoring- und Interims-funktionen statt, welche immer explizit als solche angeboten werden.Dabei übernehmen wir im ersten Schritt die entsprechende Aufgabe,überlassen im zweiten Schritt den Kandidaten immer mehr Aufga-ben, um dann im dritten Schritt nur noch bei Bedarf als Unterstützerund Berater zur Verfügung zu stehen.

Wachstum

Scrum nützt am meisten, wenn die ganze Organisation mitzieht.Aus diesem Grund ist es hilfreich, diesen Wandel von Anfang an imEinführungsprozess vorzusehen. Zum Beispiel durch das Einrichtenvon Multiplikatoren-Gruppen und internen Informationsangeboten.So können Ängste und Widerstände schon im Vorfeld abgefedert wer-den. Dieser Wachstumsprozess muss im Senior-Management veran-kert werden. Eine Maßnahme ist dabei die Bildung einer Steuerungs-oder Supportgruppe.


5 ScALeD – Scaled Agile andLean Development

ScALeD Principles

Agile Produktentwicklung hat sich für die Entwicklung in komple-xen Umgebungen bewährt und verbreitet sich immer stärker. In derAnfangszeit wurden agile Prinzipien und Methoden vornehmlich beikleineren Vorhaben eingesetzt. Mit der Zeit wurden mehr und mehrgrößere Entwicklungsvorhaben agil entwickelt. Dabei werden die Her-ausforderungen vielfältiger und individueller für die Organisation –es wird noch deutlicher, dass vorgefertigte Rezepte nicht ausreichen.Deshalb ist es notwendig, die Prinzipien und Grundlagen zu betrach-ten, um eine eigene Lösung für die Skalierung von Agilität abzulei-ten. Wir sind der Meinung, dass für die agile Skalierung keine neueMethode und auch kein zusätzliches Framework notwendig ist. Indiesem Sinne sind die vorgestellten Prinzipien auch nicht als neu zuverstehen. Wir haben lediglich das unter Skalierungsgesichtspunktenformuliert, was immer schon agiles Gedankengut war. Entsprechendnehmen wir hier auch keine weitreichenden Eigentumsrechte in An-spruch. Der Text kann ganz oder teilweise reproduziert werden, wennauf die Webseite http://scaledprinciples.org verwiesen wird.

Begeisterte Kunden

Begeisterte Kunden sind der Garant für jedes Unternehmen, lang-fristig zu wachsen. Die Aufgabe der Produktentwicklung ist es, dieGrundlage für dieses Wachstum zu schaffen.

5 ScALeD – Scaled Agile and Lean Development

Definiere, was Wert bedeutet und schafft

Das gemeinsame Verständnis über die wertschöpfenden Elementemuss gerade in einer skalierten Produktorganisation bei allen Mit-arbeitern vorhanden sein. Leitbilder helfen dabei, die strategischenZiele zu erreichen. Ein klares Wertverständnis gibt gemeinsame Ori-entierung.

Produziere kleine, lieferbare Inkremente

Inkremente bauen aufeinander auf und beinhalten stets den Nut-zen und die Funktionalität der vorherigen Inkremente. Daher eignensie sich ausgezeichnet zur Herstellung und Messung von Mehrwert.Ein lieferbares Inkrement eines Produktes hat somit qualitativ alleEigenschaften, die man zur Auslieferung braucht, wobei die Produkt-organisation Stück für Stück die fehlenden funktionalen und nicht-funktionalen Eigenschaften ergänzt. Im Idealfall kann der Wert einesInkrements sofort in Nutzen für den Kunden umgesetzt werden. Dochauch wenn das nicht möglich ist, bieten kleine, lieferbare Inkremen-te die Basis für die kontinuierliche Verbesserung des Produkts, sieminimieren Risiken und reduzieren Komplexität.

Zufriedene produktive Mitarbeiter

In der Produktentwicklung stellen Mitarbeiter das größte Potenzi-al für Verbesserungen dar. Zufriedene Mitarbeiter sorgen für höhe-re Produktivität. Deshalb ist es wichtig, eine Arbeitsumgebung zuschaffen, die eine hohe Mitarbeiterzufriedenheit sicherstellt.


Globale Optimierung

Bilde eigenständige, funktionsübergreifende Teams

Teams sind die effektivste Form zur Organisation komplexer Arbeit.Die Grundsätze der Interaktion von Individuen innerhalb eines Teamsgelten auch auf der Ebene mehrerer Teams. Teams müssen in der La-ge sein, sich untereinander eigenständig und ohne künstliche Hin-dernisse zu verständigen. Die Aufgabe des Unternehmens ist es, diedafür erforderlichen Ziele, Strukturen, Freiräume und Unterstützungbereitzustellen.

Bevollmächtige und befähige die Mitarbeiter

Mitarbeiter brauchen nicht nur technische Fertigkeiten, sondern auchdie Fähigkeit zum autonomen Arbeiten und gegenseitigen Führen.Nur dann können Teams die Freiheiten, die ihnen gegeben werden,auch sinnvoll zum Wohle der Organisation und des Kunden nutzen.Sie brauchen auch die Bevollmächtigung, eigenständig und selbst-organisiert zu arbeiten.

Globale Optimierung

Bei der agilen Skalierung ist eine Aufteilung des Produktes in (mög-lichst lose gekoppelte) Komponenten unumgänglich. Eine rein lokaleOptimierung der Komponenten führt in der Regel auf der Ebene derGesamt-Wertschöpfungskette zu einer Sub-Optimierung. Daher musssichergestellt werden, dass immer die Gesamt-Wertschöpfungsketteim Blick behalten wird.



Schaffe Transparenz in alle Richtungen

Alle Mitwirkenden haben Einblick in alle Informationen, die sie be-nötigen, um sinnvolle Entscheidungen zur Optimierung der Gesamt-situation zu treffen. Das betrifft insbesondere die Ziele, Gegebenhei-ten, Entscheidungen und den aktuellen Stand. Dabei reicht es nichtaus, diese Informationen bloß zu sammeln oder statisch bereitzu-stellen. Der dynamische Austausch von relevanten Informationen isteine der Grundvoraussetzungen für kontinuierliche Verbesserung.

Bevorzuge den persönlichen Kontakt

Der persönliche, direkte Kontakt bietet die höchste Bandbreite fürden Austausch von Wissen, Fertigkeiten, Zielen, Bedürfnissen, Be-denken. Oftmals werden implizite Informationen erst im direktenKontakt sichtbar. Persönlicher Kontakt ist nicht nur innerhalb einesTeams wichtig, sondern auch zwischen Teams und mit dem Rest derOrganisation.

Schaffe Flow & Rhythmus

Flow und Rhythmus über die gesamte Wertschöpfungskette sind ei-ne wichtige Voraussetzung für hochperformante Teams. Diese florie-ren auf der Basis von klaren Zielen, intensiver Synchronisation undschnellen (oder vermiedenen) Übergaben.

Unterstützende Führung

Führungskräfte haben in einer agilen Umgebung eine wichtige Rol-le als Lehrer und Enabler. Als Führungskraft dient man dabei dem


Unterstützende Führung

Unternehmen und den Mitarbeitern, indem man jeweils das Besteunternimmt, um den Erfolg – die Wertschöpfung – des Gesamtunter-nehmens zu unterstützen.

Setze Ziele und Rahmenbedingungen

Führungskräfte setzen Ziele und Rahmenbedingungen. Sie schaffenFreiraum für das agile Arbeiten, indem bürokratische Hürden be-seitigt, starre Strukturen aufgelöst und die Mitarbeiter sukzessiveermächtigt werden. Als Führungskraft dient man dabei dem Unter-nehmen und den Mitarbeitern, indem man jeweils das Beste unter-nimmt, um den Erfolg – die Wertschöpfung – des Gesamtunterneh-mens zu unterstützen.

Dezentralisiere Kontrollstrukturen

Selbstorganisation und Eigenverantwortung funktionieren nicht nurinnerhalb eines Entwicklungsteams, sondern auch zwischen den Teams.Lange Entscheidungswege verbrauchen wertvolle Entwicklungszeit.Daher muss ein Großteil der Entscheidungen dort getroffen werdenkönnen, wo die Arbeit erledigt wird. Für die Koordination mehre-rer Teams ist keine hierarchische Steuerungsinstanz notwendig. Siefolgt stattdessen den Prinzipien der Transparenz, der direkten Kom-munikation, der globalen Optimierung der Wertschöpfung und derÜberprüfung und Anpassung.

Kultiviere den Wandel und wandle die Kultur

Bei der Transition eines Unternehmens – bei der Einführung und demAusbau agiler Denk- und Vorgehensweisen – sollte allen Beteiligtendie Philosophie, wesentliche Zielsetzungen und die eigene Rolle bei



diesem Wandel klar sein. Die Aufgabe der strategischen Führung isthierbei, mit gutem Beispiel voran zu gehen, und den Kulturwandelsomit beständig voranzubringen.

Kontinuierliche Verbesserung

Ein Kernelement von Agilität ist die kontinuierliche Verbesserung,welche auf allen Ebenen und in allen Bereichen der Organisationstattfindet. Kontinuierliche Verbesserung lässt sich durch wiederhol-te Inspektion und Anpassung herstellen. Die Ergebnisse aus der In-spektion sollten kurze Wege gehen und die Anpassungen schnell um-gesetzt werden.

Überprüfe das Produkt und passe es an

Die häufige Inspektion des Gesamtproduktes und die Adaption derweiteren Planung ermöglichen eine schnelle Anpassung an aktuelleund geänderte Bedürfnisse der Kunden. Dies muss auch und geradein skalierten Umgebungen gewährleistet sein.

Überprüfe den Entwicklungsprozess und passe ihn an

So wie der Prozess innerhalb des Teams den Teammitgliedern gehört,gehört der teamübergreifende Prozess den Teams selbst. Die Teamsreflektieren gemeinsam, was in ihrer Zusammenarbeit gut und weni-ger gut funktioniert, leiten daraus passende Verbesserungsmaßnah-men ab und setzen diese um.


Kontinuierliche Verbesserung

Überprüfe die Organisation und passe sie an

Verbesserung einer agilen Organisation ist nicht eine einmalige Um-stellung, sondern ein iterativer Prozess. Vom ersten Tag der Einfüh-rung an werden regelmässig Überprüfungs- und Anpassungsschrittevorgenommen. Dafür wird der aktuelle Zustand überprüft, neue Ge-legenheiten und Herausforderungen identifziert und Verbesserungs-ziele bewertet und eingeordnet.

AutorenPeter Beck, Markus Gärtner, Christoph Mathis, Stefan Roock,

Andreas Schliep


6 Impressum

DasScrumTeam AGBahnhofstrasse 21

6304 ZugSchweiz

[email protected]

https://www.dasscrumteam.com/

mailto:[email protected]

dl.dasscrumteam.com · 2020-01-28 · 1 Der Scrum Guide KenSchwaberundJeffSutherland...

Documents

Transcript of dl.dasscrumteam.com · 2020-01-28 · 1 Der Scrum Guide KenSchwaberundJeffSutherland...