· scrum teams sind, zu verstehen, welche ihrer interaktio-nen mit dem team sich hilfreich...

+41.43.508.0987

[email protected]

www.DasScrumTeam.com

DasScrumTeam AG

Bahnhofstraße 21

6304 Zug / Switzerland

Lesestoff und Nachschlagewerk

fü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

35Kapitel 2

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

45Kapitel 3

Neun Übungen für erfolgreiche Retrospektivenvon Andreas Schliep

65Kapitel 4

Scrum Coachingvon Peter Beck und Andreas Schliep

69Kapitel 5

ScALeD – Scaled Agile and Lean Development

77Kapitel 6

Impressum

1 Der Scrum GuideKen Schwaber und Jeff Sutherland

Übersetzung der Version aus Juli 2016

Zielsetzung des Scrum Guide

Scrum ist ein Rahmenwerk zur Entwicklung und Erhaltung komple-xer Produkte. Dieser Leitfaden beinhaltet die Definition von Scrum.Diese Definition besteht aus den Scrum Rollen, Ereignissen, Artefak-ten sowie den Regeln, die sie miteinander verbinden. Ken Schwaberund Jeff Sutherland haben Scrum entwickelt; der Scrum Guide wirdvon ihnen verfasst und veröffentlicht. Beide stehen gemeinsam hin-ter 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 demhöchstmöglichen Wert auszuliefern.

Scrum ist:

• Leichtgewichtig

• Einfach zu verstehen

• Schwierig zu meistern

1 Der Scrum Guide

Scrum wird seit den frühen 1990er Jahren als Prozessrahmenwerkbei der Entwicklung komplexer Produkte verwendet. Es ist weder einProzess noch eine Technik zur Erstellung von Produkten, sondern istvielmehr als Rahmenwerk zu verstehen, innerhalb dessen verschie-dene Prozesse und Techniken zum Einsatz gebracht werden können.Scrum macht die relative Wirksamkeit Ihres Produktmanagementsund Entwicklungsvorgehens sichtbar, so dass Sie sich verbessernkönnen.

Das Scrum Rahmenwerk besteht aus Scrum Teams und den mit ih-nen verbundenen Rollen, Ereignissen, Artefakten und Regeln. JedeKomponente des Rahmenwerks dient einem spezifischen Zweck undist unentbehrlich für den Einsatz von Scrum und dessen Erfolg.

Durch die Regeln von Scrum werden die Beziehungen und Wech-selwirkungen zwischen den Ereignissen, Rollen und Artefakten be-stimmt. Die Regeln von Scrum sind in diesem Dokument beschrie-ben.

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

Scrum: Theorie

Scrum basiert auf der Theorie empirischer Prozesssteuerung oderkurz Ëmpirie”. Empirie bedeutet, dass Wissen aus Erfahrung gewon-nen wird und Entscheidungen auf Basis des Bekannten getroffenwerden. Scrum nutzt einen iterativen, inkrementellen Ansatz, umPrognosesicherheit [von Terminen / Ergebnissen] zu optimieren undRisiken zu kontrollieren.

Jede Implementierung von empirischer Prozesssteuerung ruht aufdrei Säulen: Transparenz, Überprüfung [Inspection] und Anpassung[Adaptation].


Scrum: Theorie

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, und

• jene die Arbeitsergebnisse produzierenden und akzeptierenden Personen müs-sen alle ein gemeinsames Verständnis der Definition von ``Done'' teilen

Überprüfung

Scrum Anwender müssen die Scrum Artefakte und den Fortschrittständig 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 gewissenhaftdurch fähige Prüfer dort vorgenommen werden, wo die Arbeit ver-richtet wird.

Anpassung

Wenn ein Überprüfer feststellt, dass Aspekte des Prozesses von denakzeptablen 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 Reader – DasScrumTeam 7

1 Der Scrum Guide

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 Commitment, Mut, Fokus, Offenheit und Respektdurch das Scrum Team verkörpert und gelebt werden, werden dieScrum-Säulen Transparenz, Inspektion und Adaption lebendig undbauen bei allen Beteiligten Vertrauen ineinander auf. Die Mitgliederdes Scrum Teams lernen und erkunden diese Werte, indem sie mitden Scrum Ereignissen, Rollen und Artefakten arbeiten.

Die erfolgreiche Anwendung von Scrum erfordert, dass die alle Betei-ligten kompetenter im Leben dieser fünf Werte werden. Sie verpflich-ten sich persönlich dazu, die Ziele des Scrum Teams zu erreichen.Die Mitglieder des Scrum Teams haben den Mut, die richtigen Dingezu tun und an schwierigen Problemen zu arbeiten. Jeder fokussiertsich auf die Arbeit im Sprint und die Ziele des Scrum Teams. DasTeam und seine Stakeholder sind sich einig, offen mit allen Belangenihrer Arbeit und den damit verbundenen Herausforderungen umzuge-hen. Die Mitglieder des Scrum Teams respektieren sich gegenseitigals kompetente, unabhängige Personen.


Das Scrum Team

Das Scrum Team

Das Scrum Team besteht aus demProduct Owner, dem Entwicklungs-team, sowie dem ScrumMaster. ScrumTeams 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 Perso-nen außerhalb des Entwicklungsteams abhängig zu sein. Das Team-Modell in Scrum wurde konzipiert, um Flexibilität, Kreativität undProduktivität zu optimieren.

Scrum Teams liefern Produkte iterativ und inkrementell und ma-ximieren somit die Gelegenheiten für Feedback. Die inkrementelleAuslieferung von “fertigem” [Done] Produkt sorgt dafür, dass stetseine potentiell nützliche Version des Produkts zur Verfügung steht.

Der Product Owner

Der Product Owner ist für die Wertmaximierung des Pro-dukts sowie der Arbeit des Entwicklungsteams verantwort-lich. Wie dies geschieht, kann je nach Organisation, ScrumTeam und Einzelpersonen stark variieren.

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

• Product Backlog-Einträge klar zu formulieren;


1 Der Scrum Guide

• 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;

• Das Sicherstellen, 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 tunoder sie durch das Entwicklungsteam erledigen lassen. Der ProductOwner bleibt jedoch immer rechenschaftspflichtig [accountable].

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 vom Entwicklungsteam verlangen,andere Anforderungen zu bearbeiten. Dem Entwicklungsteam ist esnicht erlaubt, nach den Angaben einer anderen Person als denen desProduct Owners zu arbeiten.

Das Entwicklungsteam

Das Entwicklungsteam besteht aus Profis, die am Ende eines je-den Sprints ein fertiges Inkrement übergeben, welches potentiellauslieferbar ist. Nur Mitglieder der Entwicklungsteams erstellen dasProdukt-Inkrement.


Das Scrum Team

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 machen soll.

• Entwicklungsteams sind interdisziplinär tätig. Sie haben als Team alle Fähig-keiten, die notwendig sind, um ein Produkt-Inkrement zu erstellen.

• Scrum kennt keine Titel außer ``Entwickler'' für Mitglieder des Entwicklungs-teams. Dies ist unabhängig von der Arbeit, die diese Personen erledigen. Esgibt keine Ausnahmen von dieser Regel.

• Scrum kennt keine weiteren Unterteilungen innerhalb des Entwicklungsteams,ungeachtet von bestimmten zu adressierenden Domänen, wie ``Test'' oder ``Ana-lyse''. Es gibt keine Ausnahmen von dieser Regel.

• Individuelle Mitglieder des Entwicklungsteams können zwar spezialisierte Fä-higkeiten oder Spezialgebiete haben, aber die Rechenschaftspflicht obliegtdem Team 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 einesSprints erledigen zu können. Weniger als drei Mitglieder des Ent-wicklungsteams reduzieren die Interaktion und führen zu geringe-ren Produktivitätssteigerungen [als bei größeren Teams]. Kleinere


1 Der Scrum Guide

Entwicklungsteams können eventuell kein potentiell auslieferbaresProdukt-Inkrement liefern, da sie möglicherweise nicht über alle be-nötigten Fähigkeiten verfügen. Mehr als neun Mitglieder erfordern zuviel Koordination. Große Entwicklungsteams erzeugen eine zu hoheKomplexität, um durch einen empirischen Prozess gemanagt werdenzu können. Product Owner und Scrum Master zählen nicht zu dieserZahl dazu, sofern sie nicht ebenso die Arbeit aus dem Sprint Backlogerledigen.

Der Scrum Master

Der Scrum Master ist für das Verständnis und die Durch-führung von Scrum verantwortlich. Er tut dies, indem erdafür sorgt, dass das Scrum Team die Theorie, Praktikenund Regeln von Scrum einhält.

Der Scrum Master ist ein Servant Leader für das ScrumTeam. Der Scrum Master hilft denjenigen, die kein Teil desScrum Teams sind, zu verstehen, welche ihrer Interaktio-

nen mit dem Team sich hilfreich auswirken und welche nicht. DerScrum Master hilft dabei die Zusammenarbeit so zu optimieren, dassder durch das 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

• 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;


Das 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 Bedarf oder auf Anfrage bei der Durchführung von Scrum-Ereignissen.

Der Dienst des Scrum Masters für das Entwicklungsteam

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

• 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 Bedarf oder auf Anfrage bei der Durchführung von Scrum-Ereignissen;

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

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;


1 Der Scrum Guide

• 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 Ereignissehaben eine zeitliche Beschränkung (Time Box), so dass jedes Ereig-nis eine maximale Dauer hat. Die Dauer eines Sprints steht zu sei-nem Beginn fest und darf weder gekürzt noch verlängert werden. Dieanderen Ereignisse dürfen beendet werden, sobald sie ihren Zweckerfüllt haben. Dies stellt sicher, dass nur so viel Zeit wie nötig auf-gewendet und Verschwendung 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-parenz und ist eine verpasste Gelegenheit den Ist-Stand zu erfassenund darauf zu reagieren [Inspect & Adapt].

Das Herz von Scrum ist der Sprint, eine Time Box von maximal einemMonat, innerhalb dessen ein fertiges (“Done”), nutzbares und poten-ziell auslieferbares Produkt-Inkrement hergestellt wird. Alle Sprintsinnerhalb eines Entwicklungsvorhabens sollten die gleiche Dauer ha-


Scrum-Ereignisse

ben. Der neue Sprint startet sofort nach dem Abschluss des vorigenSprints.

Ein Sprint beinhaltet und umfasst das Sprint Planning, die DailyScrums, die Entwicklungsarbeit, das Sprint Review und die SprintRetrospektive.

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.

Der Sprint

Jeder Sprint kann als ein Projekt mit einem Zeithorizont von maxi-mal einem Monat gesehen werden. Wie mit einem Projekt will manmit einem Sprint etwas Bestimmtes erreichen. Jeder Sprint hat ei-nen definierten Leistungsumfang, einen Entwurf und einen flexiblenPlan, welche Umsetzung, Arbeit und Ergebnis in die richtige Rich-tung führen.

Sprints sind auf einen Kalendermonatbeschränkt. Wenn der Zeithorizont ei-nes Sprints zu groß gewählt wird, kannsich die Definition des Ergebnisses än-dern, die Komplexität ansteigen undsich das Risiko erhöhen. Sprints er-möglichen eine Vorhersagbarkeit, in-dem sie mindestens einmal im Mo-nat Überprüfung und Anpassungendes Fortschritts zu einem bestimmten


1 Der Scrum Guide

Sprintziel ermöglichen. Sprints redu-zieren dazu noch das Risiko auf dieKosten 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 Scrum Masters vornimmt.

Ein Sprint wird dann abgebrochen werden, wenn sein 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 macht der Abbruchbei der kurzen Dauer der Sprints selten Sinn.

Wenn ein Sprint abgebrochen wird, werden alle abgeschlossenen und”Done”Product Backlog-Einträge begutachtet. Wenn ein Teil der Ar-beit potentiell 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-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 Start des neuen Sprints in einem Sprint Planning neu findenmüssen. Sprint-Abbrüche sind zudem oft schmerzhaft für das ScrumTeam; sie sind eher unüblich.


Scrum-Ereignisse

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 auf eine Time Box von maximal 8 Stunden füreinen einmonatigen Sprint beschränkt. Bei kürzeren Sprints wendetman normalerweise weniger Zeit auf. Der Scrum Master sorgt dafür,dass das Ereignis stattfindet, und die Teilnehmer seinen Zweck ver-stehen. Er bringt dem Scrum Team bei, das Ereignis innerhalb derTime Box erfolgreich 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 einePrognose über die Funktionalität, dieim Sprint entwickelt werden soll. DerProduct Owner beschreibt das Ziel, dasmit dem Sprint erreicht werden sollund die Product Backlog-Einträge, wel-che - wenn sie in dem Sprint abge-schlossen werden - das Ziel erfüllen.Das ganze Scrum Team erarbeitet ge-meinsam ein Verständnis über die Ar-beitsinhalte des Sprints.

Als Eingangsgrößen für das Meeting dienen das Product Backlog, dasneueste Produkt-Inkrement, die veranschlagte Kapazität des Ent-


1 Der Scrum Guide

wicklungsteams im Sprint sowie die bisherige Leistung desselben.Ausschließlich das Entwicklungsteam bestimmt die Anzahl der aus-gewählten Product Backlog-Einträge für den kommenden Sprint. Eskann nur selbst beurteilen, was im kommenden Sprint machbar ist.

Nach der Prognose der Product Backlog-Einträge für den Sprint durchdas Entwicklungsteam formuliert das ganze Scrum Team ein Sprint-Ziel aus. Das Sprint-Ziel bildet die Messlatte, die durch die Imple-mentierung der Product Backlog-Einträge im Sprint erreicht wird; esleitet das Entwicklungsteam in der Frage, warum es dieses Produkt-Inkrement erstellt.

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

Nach der Vereinbarung des Sprint-Ziels und der Auswahl der ProductBacklog-Einträge für den Sprint ent-scheidet das Entwicklungsteam, wiees das Produkt-Inkrement erstellenmöchte, 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.

Das Entwicklungsteam beginnt normalerweise mit dem Systement-wurf und den notwendigen Arbeiten zur Erstellung des funktionsfä-higen Produkt-Inkrements. Die Arbeiten können sich in der Größeoder dem geschätzten Aufwand unterscheiden. Auf jeden Fall soll-te das Entwicklungsteam genug planen, um zu prognostizieren, wasim kommenden Sprint fertiggestellt werden kann. Die für die erstenSprint-Tage geplanten Arbeiten sind nach Abschluss des Meetingsin kleinere Einheiten - oft von einem Tag oder weniger - zerlegt. DasEntwicklungsteam organisiert selbst, wie es die Arbeiten im Sprint


Scrum-Ereignisse

Backlog angeht, beginnend mit dem Sprint Planning und nach Be-darf im Sprint selbst.

Der Product Owner kann dabei helfen, die ausgewählten ProductBacklog-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 ProductBacklog-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 esals selbstorganisiertes Team an der Erreichung des Sprint-Ziels undErstellung des gewünschten Produkt-Inkrements arbeiten möchte.


1 Der Scrum Guide

Sprint-Ziel

Das Sprint-Ziel bietet dem Entwicklungsteam ei-ne gewisse Flexibilität in Bezug auf die im Sprintzu implementierende Funktionalität. Die aus-gewählten Product Backlog-Einträge bilden ei-ne zusammenhängende Funktionalität, die alsSprint-Ziel angesehen werden kann. Das Sprint-Ziel kann aber auch jedes andere verbindendeElement sein, welches das Entwicklungsteam -statt in verschiedene Richtungen 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, innerhalb dererdas Entwicklungsteam seine Aktivitäten synchronisiert und an derPlanung für die nächsten 24 Stunden arbeitet. Das geschieht durchdie Überprüfung der Arbeit seit dem letzten Daily Scrum und derPrognose der Arbeitsergebnisse, die bis zum nächsten Daily Scrumerreicht werden könnten.

Um die Komplexität zu reduzieren, wird das Daily Scrum an jedemTag zur gleichen Uhrzeit am gleichen Ort abgehalten. Während desMeetings schildern die Mitglieder des Entwicklungsteams:

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


Scrum-Ereignisse

• Was werde ich heute erledigen, um dem Entwicklungsteam bei der Erreichungdes Sprint-Ziels zu helfen?

• Sehe ich irgendwelche Hindernisse [Impediments], die mich oder das Entwick-lungsteam vom Erreichen des Ziels abhalten?

Das Entwicklungsteamüberprüft im Daily Scrumseinen Fortschritt in Rich-tung des Sprint-Ziels undden Trend bei der Abar-beitung der Sprint Back-log-Einträge. Das DailyScrum erhöht die Wahr-scheinlichkeit, dass das Entwicklungsteam sein Sprint-Ziel erreicht.Das Entwicklungsteam sollte Tag für Tag im Blick haben, wie es alsselbstorganisiertes Team zusammenarbeiten möchte, um das Sprint-Ziel zu erreichen und das erwartete Inkrement zum Sprintende zuliefern. Das Entwicklungsteam oder einzelne Mitglieder treffen sichhäufig direkt nach dem Daily Scrum für detailliertere Diskussionen,Anpassungen oder Umplanungen 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.

Der Scrum Master sorgt für die Einhaltung der Regel, dass nur Mit-glieder des Entwicklungsteams am Daily Scrum aktiv teilnehmen.

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


1 Der Scrum Guide

Sprint Review

Am Ende eines Sprints wird ein Sprint Re-view abgehalten, um das [Produkt-]Inkrement zuüberprüfen und das Product Backlog bei Bedarfanzupassen. Während des Sprint Reviews be-schäftigen sich das Scrum Team und die Sta-keholder gemeinsam mit den Ergebnissen desSprints. Zusammen mit eventuellen Änderungenam Product Backlog während des Sprints bieten

diese die Basis für die gemeinsame Arbeit an möglichen neuen, denWert des Produkts steigernden Punkten. Beim Sprint Review handeltes sich 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 Time Boxvon 4 Stunden angesetzt. Für kürzere Sprints wird in der Regel einkürzerer Zeitrahmen veranschlagt. Der Scrum Master kümmert sichum die Organisation des Meetings und die Vorbereitung der Teilneh-mer. Er zeigt allen Teilnehmern, wie sie das Meeting innerhalb derTime Box halten können.

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 ``Done'' sind, undwelche 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 ``Done''-Arbeiten vor, und beantwortet Fragenzu dem Inkrement.


Scrum-Ereignisse

• Der Product Owner stellt den aktuellen Stand des Product Backlogs dar. Er gibtbei Bedarf eine aktualisierte Vorhersage eines Fertigstellungstermins, auf derBasis 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.

Sprint Retrospektive

Die Sprint Retrospektive bietet dem Scrum Teamdie Gelegenheit, sich selbst zu überprüfen undeinen Verbesserungsplan für den kommendenSprint zu erstellen.

Sie findet zwischen dem Sprint Review und demnächsten Sprint Planning statt. Für einen ein-monatigen Sprint wird hierfür eine Time Box vondrei Stunden angesetzt. Für kürzere Sprints istdas Meeting in der Regel kürzer. Der Scrum Master sorgt dafür, dassdas Meeting stattfindet und alle Teilnehmer seinen Zweck verstehen.Er sorgt dafür, dass die Time Box eingehalten wird. Aufgrund seinerVerantwortung für den Scrum Prozess nimmt der Scrum Master alsgleichberechtigtes Mitglied an der Sprint Retrospektive teil.


1 Der Scrum Guide

Die Sprint Retrospektive wird durchgeführt, um

• zu überprüfen wie der vergangene Sprint in Bezug auf die beteiligten Men-schen, 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 ScrumTeams zu erstellen.

Der Scrum Master bestärkt das Scrum Team darin, innerhalb desScrum Prozessrahmenwerks seine Entwicklungsprozesse und -prak-tiken zu verbessern, um im kommenden Sprint effektiver und befrie-digender arbeiten zu können. In jeder Sprint Retrospektive erarbeitetdas Scrum Team Wege zur Verbesserung der Produktqualität durchdie entsprechende Anpassung der Definition of Done.

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 je-derzeit Verbesserungen eingeführt werden können, bietet die SprintRetrospektive eine formelle Gelegenheit, sich auf die Überprüfungund Anpassung 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.


Scrum Artefakte

Product Backlog

Das Product Backlog isteine geordnete Liste vonallem, was in dem Pro-dukt enthalten sein kann.Es dient als einzige An-forderungsquelle für al-le Änderungen am Produkt. Der Product Owner ist für das ProductBacklog, seine Inhalte, den Zugriff darauf und die Reihenfolge derEinträge verantwortlich. Ein Product Backlog ist niemals vollstän-dig. Während seiner ersten Entwicklungsschritte zeigt es nur die an-fangs bekannten und am besten verstandenen Anforderungen auf.Das Product Backlog entwickelt sich mit dem Produkt und dessenEinsatz weiter. Es ist dynamisch; es passt sich konstant an, um fürdas Produkt klar herauszustellen, was es braucht, um seiner Aufgabeangemessen zu sein, im Wettbewerb zu bestehen und den erforder-lichen Nutzen zu bieten. Das Product Backlog lebt so lange wie dasdazugehörige Produkt.

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.

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-


1 Der Scrum Guide

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 desProduct 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 angeordnete Product Backlog-Einträge sind generell klarer undweisen mehr Details auf als niedrigere. Präzisere Schätzungen ent-stehen auf der Basis von größerer Klarheit und Detailtiefe - je nied-riger der Rang, desto weniger Details sind bekannt. Die ProductBacklog-Einträge, mit denen sich das Entwicklungsteam im kom-menden Sprint beschäftigen soll, werden so weit verfeinert, dass je-der von ihnen innerhalb der Time Box des Sprints auf ”Done”gebrachtwerden kann. Die Product Backlog-Einträge, für die das der Fall ist,werden als “Ready” angesehen - bereit für die Auswahl durch dasEntwicklungsteam in einem Sprint Planning. Ein Product Backlog-Eintrag entwickelt diesen Transparenzgrad in der Regel durch dieoben beschriebenen Verfeinerungs-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.


Scrum Artefakte

Fortschrittskontrolle in Richtung eines Ziels

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.

Zur Fortschrittsprognose werden diverse Planungspraktiken einge-setzt, wie Burndown- oder Burnupdiagramme. Diese haben sich alsnützlich erwiesen, allerdings ersetzen sie nicht die Wichtigkeit desempirischen Vorgehens. In komplexen Umgebungen lassen sich zu-künftige Ereignisse nicht vorherbestimmen. Nur was geschehen ist,gibt Anhaltspunkte für die zukunftsgerichtete Entscheidungsfindung.

Sprint Backlog

Das Sprint Backlog ist die Menge der für denSprint ausgewählten Product Backlog-Einträge,ergänzt um den Plan für die Lieferung desProdukt-Inkrements sowie zur Erfüllung desSprint-Ziels. Das Sprint Backlog ist eine Pro-gnose des Entwicklungsteams darüber, welcheFunktionalität im nächsten Inkrement enthaltensein wird, sowie über die erforderliche Arbeit, um diese Funktionali-tät in einem fertigen – “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.

Das Sprint Backlog ist ein ausreichend detaillierter Plan, um denFortschritt innerhalb des Sprints im Daily Scrum erkennen zu kön-


1 Der Scrum Guide

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.

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


Transparenz der Artefakte

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 “Done” sein; das heißt es muss in einemverwendbaren Zustand sein und die Definition ofDone des Teams erfüllen. 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 wirklichvollkommen transparent sind. Es gibt Methoden für den Umgang mitfehlender Transparenz; der Scrum Master muss jedem dabei helfen,die bestmöglichen Praktiken zu finden und anzuwenden, wenn voll-ständige Transparenz nicht gewährleistet werden kann. Ein ScrumMaster spürt mangelnde Transparenz durch die Überprüfung der Ar-tefakte, die Erkennung von Mustern, intensives Zuhören, und dieErkennung von Abweichungen zwischen den erwarteten und den tat-sächlichen Resultaten auf.


1 Der Scrum Guide

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 unterscheidet, müssen alle Teammit-glieder ein gemeinsames Verständnis davon habenwann Arbeit fertig ist, um Transparenz zu gewähr-leisten. Dies erfolgt durch die Definition of Donedes Scrum Teams und wird dazu verwendet festzu-

stellen, wann die Arbeit an einem Produkt-Inkrement fertig ist.

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 relea-sen. Wenn die Definition of Done für ein Inkrement Teil der Konven-tionen, Standards oder Richtlinien der Entwicklungsorganisation ist,müssen alle Scrum Teams diese als Minimalziel befolgen. Wenn “Do-ne” für ein Inkrement nicht Teil der Konvention der Entwicklungs-organisation ist, muss das Entwicklungsteam des Scrum Teams einefür das Produkt geeignete Definition of Done formulieren [Anm. d.


Schlussbemerkung

Übers.: Das heißt nicht, dass Product Owner und Scrum Master nichteingebunden werden]. Wenn es mehrere Scrum Teams gibt, die amselben System- oder Produktrelease arbeiten, müssen alle Entwick-lungsteams aller Scrum Teams gemeinsam eine Definition of Doneerstellen.

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 De-finition of Done erweitern, um strengere Kriterien für eine höhereQualität sicherzustellen. Jedes einzelne Produkt oder System soll-te eine Definition of Done haben, welche den Standard für jeglichedaran 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

Menschen

Von den tausenden Menschen, die zu Scrum beigetragen haben, soll-ten wir diejenigen besonders hervorheben, die für Scrum in seinen


1 Der Scrum Guide

ersten zehn Jahren von besonderer Bedeutung waren. Am Anfangstanden Jeff Sutherland, welcher mit Jeff McKenna arbeitete, sowieKen Schwaber, welcher mit Mike Smith und Chris Martin zusammen-arbeitete. Viele weitere haben in den folgenden Jahren einen Beitraggeleistet. Ohne deren Hilfe wäre Scrum nicht so ausgefeilt, wie esheute 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 kann man heute schon als recht lang an-sehen. Zur Würdigung der ersten Orte, an denen Scrum ausprobiertund verfeinert wurde, möchten wir hier Individual, Inc., Fidelity In-vestments 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.

Ü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


Schlussbemerkung

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

Lizenz

©2015 Scrum.Org and ScrumInc. Offered for license under the Attri-bution Share-Alike license of Creative Commons, accessible 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 acknow-ledge and agree that you have read and agree to be bound by theterms of the Attribution ShareAlike license of Creative Commons.


http://creativecommons.org/licenses/by-sa/4.0/legalcode

http://creativecommons.org/licenses/by-sa/4.0/legalcode

http://creativecommons.org/licenses/by-sa/4.0/

http://creativecommons.org/licenses/by-sa/4.0/

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,

www.p-a-m.org

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-

www.scrummaster-ausbildung.de

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ühn

ebe

reite

n

Inform

atione

nsammeln

Einsichten

gewinne

n

Aktio

nenplan

en

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 entsprechendeMaß-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.

http://scaledprinciples.org

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]

· scrum teams sind, zu verstehen, welche ihrer interaktio-nen mit dem team sich hilfreich...

Documents