READER DER. Lesestoff und Nachschlagewerk für den Start mit Scrum. DasScrumTeam AG Bahnhofstraße Zug / Switzerland

Transkript

1 DER READER Lesestoff und Nachschlagewerk für den Start mit Scrum DasScrumTeam AG Bahnhofstraße Zug / Switzerland mail@dasscrumteam.com

2 Scrum Projektablaufplan Product Owner, Development- Team und Stakeholder Development-Team, Product Owner und Stakeholder auf Einladung durch Dev-Team Kick-Off 1,5-3 Stunden 6 Wochen bis 18 Monate Backlog Vorbereitung und Schätzung ~ 1 Woche Scrum Training 1-3 Tage Aufräumen und Vorbereitung der Arbeitsumgebung ~ 1 Woche Sprint 5-20 Arbeitstage (fix) Planning I : Was ~1 Stunde / Sprint-Woche 3-9 Sprints für 1. Auslieferung Backlog Refinement max. 10% vom Sprint z.b. time-boxed; 1 Stunde / Woche Planning II : Wie ~1 Stunde / Sprint-Woche Daily Scrum 15 Minuten, täglich Review ~1 Stunde / Sprint-Woche Peter Beck, Kai Simons DasScrumTeam.com Retrospective ~1,5-3 Stunden 2 Scrum Reader DasScrumTeam

3 Inhaltsverzeichnis 5 Kapitel 1 Der Scrum Guide von Ken Schwaber und Jeff Sutherland 35 Kapitel 2 Sieben Praktiken für die effektive Scrum-Implementierung von Peter Beck 45 Kapitel 3 Neun Übungen für erfolgreiche Retrospektiven von Andreas Schliep 65 Kapitel 4 Scrum Coaching von Peter Beck und Andreas Schliep 69 Kapitel 5 ScALeD Scaled Agile and Lean Development 77 Kapitel 6 Impressum

4

5 1 Der Scrum Guide Ken Schwaber und Jeff Sutherland Übersetzung der Version aus Juli 2016 Zielsetzung des Scrum Guide Scrum ist ein Rahmenwerk zur Entwicklung und Erhaltung komplexer Produkte. Dieser Leitfaden beinhaltet die Definition von Scrum. Diese Definition besteht aus den Scrum Rollen, Ereignissen, Artefakten sowie den Regeln, die sie miteinander verbinden. Ken Schwaber und Jeff Sutherland haben Scrum entwickelt; der Scrum Guide wird von ihnen verfasst und veröffentlicht. Beide stehen gemeinsam hinter dem Scrum Guide. Definition von Scrum Scrum (n): Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern. Scrum ist: Leichtgewichtig Einfach zu verstehen Schwierig zu meistern

6 1 Der Scrum Guide Scrum wird seit den frühen 1990er Jahren als Prozessrahmenwerk bei der Entwicklung komplexer Produkte verwendet. Es ist weder ein Prozess noch eine Technik zur Erstellung von Produkten, sondern ist vielmehr als Rahmenwerk zu verstehen, innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können. Scrum macht die relative Wirksamkeit Ihres Produktmanagements und Entwicklungsvorgehens sichtbar, so dass Sie sich verbessern können. Das Scrum Rahmenwerk besteht aus Scrum Teams und den mit ihnen verbundenen Rollen, Ereignissen, Artefakten und Regeln. Jede Komponente des Rahmenwerks dient einem spezifischen Zweck und ist unentbehrlich für den Einsatz von Scrum und dessen Erfolg. Durch die Regeln von Scrum werden die Beziehungen und Wechselwirkungen zwischen den Ereignissen, Rollen und Artefakten bestimmt. Die Regeln von Scrum sind in diesem Dokument beschrieben. Bestimmte Taktiken zur Nutzung von Scrum variieren und sind an anderer Stelle beschrieben. Scrum: Theorie Scrum basiert auf der Theorie empirischer Prozesssteuerung oder kurz Ëmpirie. Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Basis des Bekannten getroffen werden. Scrum nutzt einen iterativen, inkrementellen Ansatz, um Prognosesicherheit [von Terminen / Ergebnissen] zu optimieren und Risiken zu kontrollieren. Jede Implementierung von empirischer Prozesssteuerung ruht auf drei Säulen: Transparenz, Überprüfung [Inspection] und Anpassung [Adaptation]. 6 Scrum Reader DasScrumTeam

7 Scrum: Theorie Transparenz Die wesentlichen Aspekte des Prozesses müssen für diejenigen sichtbar sein, die für das Ergebnis verantwortlich sind. Transparenz erfordert, dass diese Aspekte nach einem gemeinsamen Standard definiert werden, damit die Betrachter ein gemeinsames Verständnis des Gesehenen teilen. Dies umfasst beispielsweise eine gemeinsame Prozesssprache, die von allen Teilnehmern geteilt wird, und jene die Arbeitsergebnisse produzierenden und akzeptierenden Personen müssen alle ein gemeinsames Verständnis der Definition von ``Done'' teilen Überprüfung Scrum Anwender müssen die Scrum Artefakte und den Fortschritt ständig in Bezug auf die Erreichung des Sprint-Ziels überprüfen, um unerwünschte Abweichungen zu erkennen. Ihre Untersuchungen sollten nicht so häufig erfolgen, dass sie die Arbeit behindern. Den größten Nutzen bringen Überprüfungen, wenn sie gewissenhaft durch fähige Prüfer dort vorgenommen werden, wo die Arbeit verrichtet wird. Anpassung Wenn ein Überprüfer feststellt, dass Aspekte des Prozesses von den akzeptablen Grenzwerten abweichen, und dass das resultierende Produkt so nicht akzeptabel sein wird, müssen der Prozess oder das zu bearbeitende Material angepasst werden. Die Anpassung muss [dann] so schnell wie möglich vorgenommen werden, um weitere Abweichungen zu minimieren. Scrum Reader DasScrumTeam 7

8 1 Der Scrum Guide Scrum schreibt vier formale Ereignisse für Überprüfung und Anpassung 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 Respekt durch das Scrum Team verkörpert und gelebt werden, werden die Scrum-Säulen Transparenz, Inspektion und Adaption lebendig und bauen bei allen Beteiligten Vertrauen ineinander auf. Die Mitglieder des Scrum Teams lernen und erkunden diese Werte, indem sie mit den Scrum Ereignissen, Rollen und Artefakten arbeiten. Die erfolgreiche Anwendung von Scrum erfordert, dass die alle Beteiligten kompetenter im Leben dieser fünf Werte werden. Sie verpflichten sich persönlich dazu, die Ziele des Scrum Teams zu erreichen. Die Mitglieder des Scrum Teams haben den Mut, die richtigen Dinge zu tun und an schwierigen Problemen zu arbeiten. Jeder fokussiert sich auf die Arbeit im Sprint und die Ziele des Scrum Teams. Das Team und seine Stakeholder sind sich einig, offen mit allen Belangen ihrer Arbeit und den damit verbundenen Herausforderungen umzugehen. Die Mitglieder des Scrum Teams respektieren sich gegenseitig als kompetente, unabhängige Personen. 8 Scrum Reader DasScrumTeam

9 Das Scrum Team Das Scrum Team Das Scrum Team besteht aus dem Product Owner, dem Entwicklungsteam, sowie dem Scrum Master. Scrum Teams sind selbstorganisierend und interdisziplinär. Selbstorganisierende Teams entscheiden selbst, wie sie ihre Arbeit am besten erledigen, anstatt dieses durch andere Personen außerhalb des Teams vorgegeben zu bekommen. Interdisziplinäre Teams verfügen über alle Kompetenzen, die erforderlich sind, um die Arbeit zu erledigen, ohne dabei von Personen außerhalb des Entwicklungsteams abhängig zu sein. Das Team- Modell in Scrum wurde konzipiert, um Flexibilität, Kreativität und Produktivität zu optimieren. Scrum Teams liefern Produkte iterativ und inkrementell und maximieren somit die Gelegenheiten für Feedback. Die inkrementelle Auslieferung von fertigem [Done] Produkt sorgt dafür, dass stets eine potentiell nützliche Version des Produkts zur Verfügung steht. Der Product Owner Der Product Owner ist für die Wertmaximierung des Produkts sowie der Arbeit des Entwicklungsteams verantwortlich. Wie dies geschieht, kann je nach Organisation, Scrum Team und Einzelpersonen stark variieren. Der Product Owner ist die einzige Person, die für das Management des Product Backlogs verantwortlich ist. Das Product Backlog Management umfasst: Product Backlog-Einträge klar zu formulieren; Scrum Reader DasScrumTeam 9

10 1 Der Scrum Guide Die Einträge im Product Backlog so zu sortieren, dass Ziele und Missionen optimal 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 alle klar ist sowie zeigt, woran das Scrum Team als nächstes arbeiten wird; und sicherzustellen, dass das Entwicklungsteam die Product-Backlog-Einträge im erforderlichen Maße versteht. Der Product Owner kann die oben genannten Arbeiten selbst tun oder sie durch das Entwicklungsteam erledigen lassen. Der Product Owner bleibt jedoch immer rechenschaftspflichtig [accountable]. Der Product Owner ist eine einzelne Person, kein Komitee. Er kann zwar die Wünsche eines Komitees im Product Backlog wiedergeben, aber diejenigen, die einen Eintrag des Product Backlogs in seiner Priorität verändern möchten, müssen sich an den Product Owner wenden. Damit der Product Owner erfolgreich sein kann, muss die gesamte Organisation seine Entscheidungen respektieren. Die Entscheidungen des Product Owners sind in Inhalt und Reihenfolge des Product Backlogs sichtbar. Niemand darf vom Entwicklungsteam verlangen, andere Anforderungen zu bearbeiten. Dem Entwicklungsteam ist es nicht erlaubt, nach den Angaben einer anderen Person als denen des Product Owners zu arbeiten. Das Entwicklungsteam Das Entwicklungsteam besteht aus Profis, die am Ende eines jeden Sprints ein fertiges Inkrement übergeben, welches potentiell auslieferbar ist. Nur Mitglieder der Entwicklungsteams erstellen das Produkt-Inkrement. 10 Scrum Reader DasScrumTeam

11 Das Scrum Team Entwicklungsteams sind von der Organisation so strukturiert und befähigt, dass sie ihre eigene Arbeit selbst organisieren und managen. Die daraus resultierende Synergie optimiert die Gesamteffizienz und -effektivität des Entwicklungsteams. Entwicklungsteams weisen die folgenden Eigenschaften auf: Sie sind selbstorganisierend. Niemand (nicht einmal der Scrum Master) sagt dem Entwicklungsteam, wie es aus dem Product Backlog potentiell auslieferbare Funktionalität machen soll. Entwicklungsteams sind interdisziplinär tätig. Sie haben als Team alle Fähigkeiten, die notwendig sind, um ein Produkt-Inkrement zu erstellen. Scrum kennt keine Titel außer ``Entwickler'' für Mitglieder des Entwicklungsteams. Dies ist unabhängig von der Arbeit, die diese Personen erledigen. Es gibt keine Ausnahmen von dieser Regel. Scrum kennt keine weiteren Unterteilungen innerhalb des Entwicklungsteams, ungeachtet von bestimmten zu adressierenden Domänen, wie ``Test'' oder ``Analyse''. Es gibt keine Ausnahmen von dieser Regel. Individuelle Mitglieder des Entwicklungsteams können zwar spezialisierte Fähigkeiten oder Spezialgebiete haben, aber die Rechenschaftspflicht obliegt dem Team als Ganzem. Größe des Entwicklungsteams Die optimale Größe des Entwicklungsteams ist klein genug, um flink zu bleiben und groß genug, um bedeutende Arbeit innerhalb eines Sprints erledigen zu können. Weniger als drei Mitglieder des Entwicklungsteams reduzieren die Interaktion und führen zu geringeren Produktivitätssteigerungen [als bei größeren Teams]. Kleinere Scrum Reader DasScrumTeam 11

12 1 Der Scrum Guide Entwicklungsteams können eventuell kein potentiell auslieferbares Produkt-Inkrement liefern, da sie möglicherweise nicht über alle benötigten Fähigkeiten verfügen. Mehr als neun Mitglieder erfordern zu viel Koordination. Große Entwicklungsteams erzeugen eine zu hohe Komplexität, um durch einen empirischen Prozess gemanagt werden zu können. Product Owner und Scrum Master zählen nicht zu dieser Zahl dazu, sofern sie nicht ebenso die Arbeit aus dem Sprint Backlog erledigen. Der Scrum Master Der Scrum Master ist für das Verständnis und die Durchführung von Scrum verantwortlich. Er tut dies, indem er dafür sorgt, dass das Scrum Team die Theorie, Praktiken und Regeln von Scrum einhält. 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 dem Team sich hilfreich auswirken und welche nicht. Der Scrum Master hilft dabei die Zusammenarbeit so zu optimieren, dass der 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 Product Backlog Einträge im Scrum Team; 12 Scrum Reader DasScrumTeam

13 Das Scrum Team Schaffen eines Verständnisses für Produktplanung in einem empirischen Arbeitsumfeld; Sicherstellen, dass der Product Owner weiß, wie er das Product Backlog so anordnet, 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 verschiedene Arten, unter anderem durch: Coachen des Entwicklungsteams hin zu Selbstorganisation und funktionsübergreifender Teamarbeit; Unterstützung des Entwicklungsteams bei der Schaffung hochwertiger Produkte; 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 nicht vollstä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; Scrum Reader DasScrumTeam 13

14 1 Der Scrum Guide Planen von Scrum-Implementierungen innerhalb der Organisation; Unterstützen von Kollegen und Stakeholdern, Scrum und empirische Produktentwicklung zu verstehen und umzusetzen; Auslösen von Veränderungen zur Produktivitätssteigerung des Teams; Zusammenarbeiten mit anderen Scrum Mastern, um die Effektivität von Scrum- Implementierungen innerhalb der Organisation zu verbessern. Scrum-Ereignisse In Scrum werden vorgeschriebene Ereignisse verwendet, um eine Regelmäßigkeit herzustellen und die Notwendigkeit anderer, nicht in Scrum definierter, Besprechungen zu minimieren. Alle Ereignisse haben eine zeitliche Beschränkung (Time Box), so dass jedes Ereignis eine maximale Dauer hat. Die Dauer eines Sprints steht zu seinem Beginn fest und darf weder gekürzt noch verlängert werden. Die anderen Ereignisse dürfen beendet werden, sobald sie ihren Zweck erfüllt haben. Dies stellt sicher, dass nur so viel Zeit wie nötig aufgewendet und Verschwendung vermieden wird. Mit Ausnahme des Sprints als Container für alle anderen Ereignisse ist jedes Scrum Ereignis eine formale Gelegenheit zur Überprüfung und Anpassung. Diese Ereignisse sind genau dazu gedacht, an den kritischen Stellen Transparenz und Überprüfung zu ermöglichen. Das Weglassen irgendeines dieser Ereignisse führt zu verringerter Transparenz und ist eine verpasste Gelegenheit den Ist-Stand zu erfassen und darauf zu reagieren [Inspect & Adapt]. Das Herz von Scrum ist der Sprint, eine Time Box von maximal einem Monat, innerhalb dessen ein fertiges ( Done ), nutzbares und potenziell auslieferbares Produkt-Inkrement hergestellt wird. Alle Sprints innerhalb eines Entwicklungsvorhabens sollten die gleiche Dauer ha- 14 Scrum Reader DasScrumTeam

15 Scrum-Ereignisse ben. Der neue Sprint startet sofort nach dem Abschluss des vorigen Sprints. Ein Sprint beinhaltet und umfasst das Sprint Planning, die Daily Scrums, die Entwicklungsarbeit, das Sprint Review und die Sprint Retrospektive. 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 Entwicklungsteam geklärt und neu ausgehandelt werden, wenn sich neue Erkenntnisse ergeben haben. Der Sprint Jeder Sprint kann als ein Projekt mit einem Zeithorizont von maximal einem Monat gesehen werden. Wie mit einem Projekt will man mit einem Sprint etwas Bestimmtes erreichen. Jeder Sprint hat einen definierten Leistungsumfang, einen Entwurf und einen flexiblen Plan, welche Umsetzung, Arbeit und Ergebnis in die richtige Richtung führen. Sprints sind auf einen Kalendermonat beschränkt. Wenn der Zeithorizont eines Sprints zu groß gewählt wird, kann sich die Definition des Ergebnisses ändern, die Komplexität ansteigen und sich das Risiko erhöhen. Sprints ermöglichen eine Vorhersagbarkeit, indem sie mindestens einmal im Monat Überprüfung und Anpassungen des Fortschritts zu einem bestimmten Scrum Reader DasScrumTeam 15

16 1 Der Scrum Guide Sprintziel ermöglichen. Sprints reduzieren dazu noch das Risiko auf die Kosten eines Monats. Einen Sprint abbrechen Ein Sprint kann vorzeitig, d.h. vor dem Ablauf seiner Time Box, abgebrochen werden. Dazu ist nur der Product Owner berechtigt, auch wenn er oder sie den Abbruch auf Anraten der Stakeholder, des Entwicklungsteams oder Scrum Masters vornimmt. Ein Sprint wird dann abgebrochen werden, wenn sein Sprint-Ziel obsolet wird. Das kann vorkommen, wenn das Unternehmen seine Zielrichtung wechselt, oder sich andere Markt- oder technologische Rahmenbedingungen ändern. In der Regel sollte ein Sprint dann abgebrochen werden, wenn die Fortführung unter den gegenwärtigen Umständen keinen Sinn mehr macht. Allerdings macht der Abbruch bei 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 Arbeit potentiell auslieferbar ist, wird sie vom Product Owner meistens abgenommen. Alle unvollständigen Product Backlog-Einträge werden neu geschätzt und wieder in das Product Backlog aufgenommen. 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 Teammitglieder zum Start des neuen Sprints in einem Sprint Planning neu finden müssen. Sprint-Abbrüche sind zudem oft schmerzhaft für das Scrum Team; sie sind eher unüblich. 16 Scrum Reader DasScrumTeam

17 Scrum-Ereignisse Sprint Planning Im Sprint Planning wird die Arbeit für den kommenden Sprint geplant. Dieser Plan entsteht durch die gemeinschaftliche Arbeit des gesamten Scrum Teams. Das Sprint Planning ist auf eine Time Box von maximal 8 Stunden für einen einmonatigen Sprint beschränkt. Bei kürzeren Sprints wendet man normalerweise weniger Zeit auf. Der Scrum Master sorgt dafür, dass das Ereignis stattfindet, und die Teilnehmer seinen Zweck verstehen. Er bringt dem Scrum Team bei, das Ereignis innerhalb der Time 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 erreicht? 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 beschreibt das Ziel, das mit dem Sprint erreicht werden soll und die Product Backlog-Einträge, welche - wenn sie in dem Sprint abgeschlossen werden - das Ziel erfüllen. Das ganze Scrum Team erarbeitet gemeinsam ein Verständnis über die Arbeitsinhalte des Sprints. Als Eingangsgrößen für das Meeting dienen das Product Backlog, das neueste Produkt-Inkrement, die veranschlagte Kapazität des Ent- Scrum Reader DasScrumTeam 17

18 1 Der Scrum Guide wicklungsteams im Sprint sowie die bisherige Leistung desselben. Ausschließlich das Entwicklungsteam bestimmt die Anzahl der ausgewählten Product Backlog-Einträge für den kommenden Sprint. Es kann nur selbst beurteilen, was im kommenden Sprint machbar ist. Nach der Prognose der Product Backlog-Einträge für den Sprint durch das Entwicklungsteam formuliert das ganze Scrum Team ein Sprint- Ziel aus. Das Sprint-Ziel bildet die Messlatte, die durch die Implementierung der Product Backlog-Einträge im Sprint erreicht wird; es leitet 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 Product Backlog-Einträge für den Sprint entscheidet das Entwicklungsteam, wie es das Produkt-Inkrement erstellen möchte, damit die Funktionalität in einen Done -Zustand gebracht werden kann. Als Sprint Backlog bezeichnet man die Auswahl der Product Backlog- Einträge für den jeweiligen Sprint plus den Umsetzungsplan des Entwicklungsteams. Das Entwicklungsteam beginnt normalerweise mit dem Systementwurf und den notwendigen Arbeiten zur Erstellung des funktionsfähigen Produkt-Inkrements. Die Arbeiten können sich in der Größe oder dem geschätzten Aufwand unterscheiden. Auf jeden Fall sollte das Entwicklungsteam genug planen, um zu prognostizieren, was im kommenden Sprint fertiggestellt werden kann. Die für die ersten Sprint-Tage geplanten Arbeiten sind nach Abschluss des Meetings in kleinere Einheiten - oft von einem Tag oder weniger - zerlegt. Das Entwicklungsteam organisiert selbst, wie es die Arbeiten im Sprint 18 Scrum Reader DasScrumTeam

19 Scrum-Ereignisse Backlog angeht, beginnend mit dem Sprint Planning und nach Bedarf im Sprint selbst. Der Product Owner kann dabei helfen, die ausgewählten Product Backlog-Einträge zu klären und ggf. Kompromisse einzugehen. Wenn das Entwicklungsteam herausfindet, dass es sich zu viel oder zu wenig Arbeit vorgenommen hat, kann es die ausgewählten Product Backlog-Einträge neu mit dem Product Owner aushandeln. Das Entwicklungsteam kann auch andere Teilnehmer zu dem Meeting einladen, um technische oder fachliche Unterstützung zu erhalten. Am Ende des Sprint Plannings sollte das Entwicklungsteam in der Lage sein, Product Owner und Scrum Master zu schildern, wie es als selbstorganisiertes Team an der Erreichung des Sprint-Ziels und Erstellung des gewünschten Produkt-Inkrements arbeiten möchte. Scrum Reader DasScrumTeam 19

20 1 Der Scrum Guide Sprint-Ziel Das Sprint-Ziel bietet dem Entwicklungsteam eine gewisse Flexibilität in Bezug auf die im Sprint zu implementierende Funktionalität. Die ausgewählten Product Backlog-Einträge bilden eine zusammenhängende Funktionalität, die als Sprint-Ziel angesehen werden kann. Das Sprint- Ziel kann aber auch jedes andere verbindende Element sein, welches das Entwicklungsteam - statt in verschiedene Richtungen zu laufen - zur Zusammenarbeit motiviert. Bei seiner Arbeit behält das Entwicklungsteam sein Sprint-Ziel vor Augen. Um dieses zu erreichen, implementiert es die entsprechende Funktionalität und Technologie. Falls es sich zeigt, dass der Arbeitsumfang von den ursprünglichen Erwartungen abweicht, handelt das Entwicklungsteam gemeinsam mit dem Product Owner eine Änderung des Sprint Backlog-Umfangs für den laufenden Sprint aus. Daily Scrum Das Daily Scrum ist eine Time Box von 15 Minuten, innerhalb derer das Entwicklungsteam seine Aktivitäten synchronisiert und an der Planung für die nächsten 24 Stunden arbeitet. Das geschieht durch die Überprüfung der Arbeit seit dem letzten Daily Scrum und der Prognose der Arbeitsergebnisse, die bis zum nächsten Daily Scrum erreicht werden könnten. Um die Komplexität zu reduzieren, wird das Daily Scrum an jedem Tag zur gleichen Uhrzeit am gleichen Ort abgehalten. Während des Meetings schildern die Mitglieder des Entwicklungsteams: Was habe ich gestern erreicht, das dem Entwicklungsteam hilft, das Sprint- Ziel zu erreichen? 20 Scrum Reader DasScrumTeam

21 Scrum-Ereignisse Was werde ich heute erledigen, um dem Entwicklungsteam bei der Erreichung des Sprint-Ziels zu helfen? Sehe ich irgendwelche Hindernisse [Impediments], die mich oder das Entwicklungsteam vom Erreichen des Ziels abhalten? Das Entwicklungsteam überprüft im Daily Scrum seinen Fortschritt in Richtung des Sprint-Ziels und den Trend bei der Abarbeitung der Sprint Backlog-Einträge. Das Daily Scrum erhöht die Wahrscheinlichkeit, dass das Entwicklungsteam sein Sprint-Ziel erreicht. Das Entwicklungsteam sollte Tag für Tag im Blick haben, wie es als selbstorganisiertes Team zusammenarbeiten möchte, um das Sprint- Ziel zu erreichen und das erwartete Inkrement zum Sprintende zu liefern. Das Entwicklungsteam oder einzelne Mitglieder treffen sich hä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 stattfindet, ist das Entwicklungsteam für die Durchführung zuständig. Hierzu bringt der Scrum Master dem Entwicklungsteam bei, wie es die 15-minütige Time Box des Daily Scrums einhalten kann. Der Scrum Master sorgt für die Einhaltung der Regel, dass nur Mitglieder des Entwicklungsteams am Daily Scrum aktiv teilnehmen. Daily Scrums verbessern die Kommunikation, machen andere Meetings überflüssig, identifizieren zu beseitigende Hindernisse, fokussieren sowie fördern die schnelle Entscheidungsfindung und erhöhen den Wissensstand des Entwicklungsteams. Das Daily Scrum ist ein entscheidendes Meeting zur Überprüfung und Anpassung. Scrum Reader DasScrumTeam 21

22 1 Der Scrum Guide Sprint Review Am Ende eines Sprints wird ein Sprint Review abgehalten, um das [Produkt-]Inkrement zu überprüfen und das Product Backlog bei Bedarf anzupassen. Während des Sprint Reviews beschäftigen sich das Scrum Team und die Stakeholder gemeinsam mit den Ergebnissen des Sprints. Zusammen mit eventuellen Änderungen am Product Backlog während des Sprints bieten diese die Basis für die gemeinsame Arbeit an möglichen neuen, den Wert des Produkts steigernden Punkten. Beim Sprint Review handelt es sich um ein informelles Meeting, keinen Statusreport. Die Vorführung des Inkrements ist als Anregung für Feedback und die Basis für die Zusammenarbeit gedacht. Für einen einmonatigen Sprint wird für dieses Meeting eine Time Box von 4 Stunden angesetzt. Für kürzere Sprints wird in der Regel ein kürzerer Zeitrahmen veranschlagt. Der Scrum Master kümmert sich um die Organisation des Meetings und die Vorbereitung der Teilnehmer. Er zeigt allen Teilnehmern, wie sie das Meeting innerhalb der Time 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, und welche nicht. Das Entwicklungsteam stellt dar, was während des Sprints gut lief, welche Probleme aufgetaucht sind, und wie es diese Probleme gelöst hat. Das Entwicklungsteam führt die ``Done''-Arbeiten vor, und beantwortet Fragen zu dem Inkrement. 22 Scrum Reader DasScrumTeam

23 Scrum-Ereignisse Der Product Owner stellt den aktuellen Stand des Product Backlogs dar. Er gibt bei Bedarf eine aktualisierte Vorhersage eines Fertigstellungstermins, auf der Basis des Entwicklungsfortschritts. Alle Teilnehmer erarbeiten gemeinsam, was als nächstes zu tun ist, so dass das Sprint Review wertvollen Input für die kommenden Sprint Plannings liefert. Es erfolgt eine Begutachtung, ob sich durch die Marktsituation oder den möglichen Produkteinsatz neue Erkenntnisse über die wertvollsten nächsten Schritte ergeben haben. Anschließend werden Zeitplan, Budget, die potentiellen Eigenschaften sowie die Markterwartungen für das nächste zu erwartende Produkt-Release überprüft. Das Ergebnis des Sprint Reviews ist ein überarbeitetes Product Backlog, das die möglichen Product Backlog-Einträge für den kommenden Sprint enthält. Das Product Backlog kann auch umfassend umgearbeitet werden, um neue Chancen zu nutzen. Sprint Retrospektive Die Sprint Retrospektive bietet dem Scrum Team die Gelegenheit, sich selbst zu überprüfen und einen Verbesserungsplan für den kommenden Sprint zu erstellen. Sie findet zwischen dem Sprint Review und dem nächsten Sprint Planning statt. Für einen einmonatigen Sprint wird hierfür eine Time Box von drei Stunden angesetzt. Für kürzere Sprints ist das Meeting in der Regel kürzer. Der Scrum Master sorgt dafür, dass das Meeting stattfindet und alle Teilnehmer seinen Zweck verstehen. Er sorgt dafür, dass die Time Box eingehalten wird. Aufgrund seiner Verantwortung für den Scrum Prozess nimmt der Scrum Master als gleichberechtigtes Mitglied an der Sprint Retrospektive teil. Scrum Reader DasScrumTeam 23

24 1 Der Scrum Guide Die Sprint Retrospektive wird durchgeführt, um zu überprüfen wie der vergangene Sprint in Bezug auf die beteiligten Menschen, Beziehungen, Prozesse und Werkzeuge verlief; die wichtigsten gut gelaufenen Elemente und mögliche Verbesserungen zu identifizieren 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, innerhalb des Scrum Prozessrahmenwerks seine Entwicklungsprozesse und -praktiken zu verbessern, um im kommenden Sprint effektiver und befriedigender arbeiten zu können. In jeder Sprint Retrospektive erarbeitet das Scrum Team Wege zur Verbesserung der Produktqualität durch die entsprechende Anpassung der Definition of Done. Zum Ende der Sprint Retrospektive sollte das Scrum Team Verbesserungen für den kommenden Sprint identifiziert haben. Die Umsetzung dieser Verbesserungen im nächsten Sprint ist die Anpassungsleistung zur Selbstüberprüfung des Scrum Teams. Auch wenn jederzeit Verbesserungen eingeführt werden können, bietet die Sprint Retrospektive eine formelle Gelegenheit, sich auf die Überprüfung und Anpassung zu fokussieren. Scrum Artefakte Die Artefakte von Scrum repräsentieren Arbeit oder Wert, um Transparenz sowie Möglichkeiten zur Überprüfung und Anpassung zu schaffen. Die in Scrum definierten Artefakte wurden speziell so entworfen, dass sie die Transparenz der wesentlichen Informationen maximieren, um für alle ein gleiches Verständnis über das Artefakt zu schaffen. 24 Scrum Reader DasScrumTeam

25 Scrum Artefakte Product Backlog Das Product Backlog ist eine geordnete Liste von allem, was in dem Produkt enthalten sein kann. Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt. Der Product Owner ist für das Product Backlog, seine Inhalte, den Zugriff darauf und die Reihenfolge der Einträge verantwortlich. Ein Product Backlog ist niemals vollständig. Während seiner ersten Entwicklungsschritte zeigt es nur die anfangs bekannten und am besten verstandenen Anforderungen auf. Das Product Backlog entwickelt sich mit dem Produkt und dessen Einsatz weiter. Es ist dynamisch; es passt sich konstant an, um für das Produkt klar herauszustellen, was es braucht, um seiner Aufgabe angemessen zu sein, im Wettbewerb zu bestehen und den erforderlichen Nutzen zu bieten. Das Product Backlog lebt so lange wie das dazugehörige Produkt. Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases ausmachen. Ein Product-Backlog-Eintrag enthält als Attribute eine Beschreibung, die Reihenfolge, die Schätzung und den Wert. Das Product Backlog entwickelt sich mit dem Einsatz eines Produktes, dessen Wertsteigerung sowie durch das Feedback des Marktes zu einer längeren, ausführlicheren Liste. Anforderungen werden nie aufhören, sich zu ändern. Daher ist das Product Backlog ein lebendes Artefakt. Änderungen an den Geschäftsanforderungen, Marktbedingungen oder der Technologie können Änderungen am Product Backlog nach sich ziehen. Häufig arbeiten mehrere Scrum Teams gemeinsam an einem Produkt. Dann wird ein einziges Product Backlog benutzt, um die an- Scrum Reader DasScrumTeam 25

26 1 Der Scrum Guide stehende Arbeit am Produkt zu beschreiben. In diesem Fall kann ein Gruppierungsattribut für die Product Backlog-Einträge verwendet werden. Als Verfeinerung [Refinement] des Product Backlogs wird der Vorgang angesehen, in dem Details zu Einträgen hinzugefügt, Schätzungen erstellt, oder die Reihenfolge der Einträge im Product Backlog bestimmt werden. Die Verfeinerung ist ein kontinuierlicher Prozess, in dem der Product Owner und das Entwicklungsteam gemeinsam die Product Backlog-Einträge detaillieren. Bei der Verfeinerung des Product Backlogs werden die Einträge begutachtet und revidiert. Das Scrum Team bestimmt, wann und wie diese Verfeinerungsarbeit erfolgt. Sie sollte normalerweise nicht mehr als 10% der Kapazität des Entwicklungsteams beanspruchen. Der Product Owner kann jedoch jederzeit die Einträge im Product Backlog aktualisieren oder aktualisieren lassen. Höher angeordnete Product Backlog-Einträge sind generell klarer und weisen mehr Details auf als niedrigere. Präzisere Schätzungen entstehen auf der Basis von größerer Klarheit und Detailtiefe - je niedriger der Rang, desto weniger Details sind bekannt. Die Product Backlog-Einträge, mit denen sich das Entwicklungsteam im kommenden Sprint beschäftigen soll, werden so weit verfeinert, dass jeder von ihnen innerhalb der Time Box des Sprints auf Done gebracht werden kann. Die Product Backlog-Einträge, für die das der Fall ist, werden als Ready angesehen - bereit für die Auswahl durch das Entwicklungsteam in einem Sprint Planning. Ein Product Backlog- Eintrag entwickelt diesen Transparenzgrad in der Regel durch die oben beschriebenen Verfeinerungs-Aktivitäten. Das Entwicklungsteam ist für alle Schätzungen verantwortlich. Der Product Owner kann das Entwicklungsteam dahingehend beeinflussen, dass er ihm beim Verständnis der Einträge hilft oder Kompromisse eingeht. Die endgültige Schätzung erfolgt immer von denen, die auch die Arbeit erledigen werden. 26 Scrum Reader DasScrumTeam

27 Scrum Artefakte Fortschrittskontrolle in Richtung eines Ziels Die verbleibende Arbeit zur Erreichung eines Ziels kann jederzeit aufsummiert werden. Der Product Owner vermerkt diese gesamte verbleibende Arbeit mindestens zu jedem Sprint Review. Er vergleicht diesen Betrag mit der verbleibenden Arbeit in früheren Sprint Reviews, um den Fortschritt der Arbeiten im Verhältnis zur restlichen Zeit zu begutachten. Diese Information wird allen Stakeholdern präsentiert. Zur Fortschrittsprognose werden diverse Planungspraktiken eingesetzt, wie Burndown- oder Burnupdiagramme. Diese haben sich als nützlich erwiesen, allerdings ersetzen sie nicht die Wichtigkeit des empirischen Vorgehens. In komplexen Umgebungen lassen sich zukü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 den Sprint ausgewählten Product Backlog-Einträge, ergänzt um den Plan für die Lieferung des Produkt-Inkrements sowie zur Erfüllung des Sprint-Ziels. Das Sprint Backlog ist eine Prognose des Entwicklungsteams darüber, welche Funktionalität im nächsten Inkrement enthalten sein wird, sowie über die erforderliche Arbeit, um diese Funktionalität in einem fertigen Done -Inkrement zu liefern. Das Sprint Backlog macht die gesamte Arbeit sichtbar, die das Entwicklungsteam für notwendig erachtet, um das Sprint-Ziel zu erreichen. Das Sprint Backlog ist ein ausreichend detaillierter Plan, um den Fortschritt innerhalb des Sprints im Daily Scrum erkennen zu kön- Scrum Reader DasScrumTeam 27

28 1 Der Scrum Guide nen. Das Entwicklungsteam passt das Sprint Backlog während des Sprints an; das Sprint Backlog entwickelt sich so während des Sprints. Diese Entwicklung erfolgt, während das Entwicklungsteam den Plan abarbeitet und mehr über die noch benötigten Schritte zur Erreichung des Sprint-Ziels lernt. Wenn weitere Arbeiten erforderlich sind, werden sie vom Entwicklungsteam zum Sprint Backlog hinzugefügt. Wenn eine Arbeit durchgeführt wird oder abgeschlossen wurde, wird die Schätzung der verbleibenden Arbeit aktualisiert. Wenn sich Bestandteile des Plans als unnötig erweisen, werden sie entfernt. Nur das Entwicklungsteam kann sein Sprint Backlog während des Sprints ändern. Das Sprint Backlog ist ein hochgradig sichtbares Echtzeit-Bild der Arbeit, die das Entwicklungsteam plant, während des Sprints zu erreichen. Es gehört einzig und allein dem Entwicklungsteam. Überwachung des Sprint-Fortschritts Zu jedem Zeitpunkt im Sprint kann die gesamte verbleibende Arbeit an den Sprint Backlog-Einträgen aufsummiert werden. Das Entwicklungsteam verfolgt diese gesamte Restarbeit mindestens zu jedem Daily Scrum, um die Wahrscheinlichkeit, das Sprint-Ziel zu erreichen, sichtbar zu machen. Durch die Nachverfolgung der verbleibenden Arbeit während des Sprints kann das Entwicklungsteam seinen Fortschritt steuern. 28 Scrum Reader DasScrumTeam

29 Transparenz der Artefakte Inkrement Das Inkrement ist das Ergebnis aus allen in einem Sprint fertiggestellten Product Backlog-Einträgen und dem Resultat der Inkremente aller früheren Sprints. Am Ende eines Sprints muss das neue Inkrement Done sein; das heißt es muss in einem verwendbaren Zustand sein und die Definition of Done des Teams erfüllen. Es muss auch dann im einsatzfähigen Zustand sein, wenn der Product Owner es aktuell noch gar nicht ausliefern will. Transparenz der Artefakte Scrum basiert auf Transparenz. Entscheidungen zur Wertoptimierung und Risikokontrolle werden auf der Basis des festgestellten Zustands der Artefakte vorgenommen. Diese Entscheidungen haben in dem Maß eine solide Basis, in dem die Transparenz der Artefakte umfassend ist. Bei einer unvollständigen Transparenz können Entscheidungen auf Sand gebaut sein, Wert kann gemindert und das Risiko erhöht werden. Der Scrum Master muss mit dem Product Owner, dem Entwicklungsteam und anderen Beteiligten herausfinden, ob die Artefakte wirklich vollkommen transparent sind. Es gibt Methoden für den Umgang mit fehlender Transparenz; der Scrum Master muss jedem dabei helfen, die bestmöglichen Praktiken zu finden und anzuwenden, wenn vollständige Transparenz nicht gewährleistet werden kann. Ein Scrum Master spürt mangelnde Transparenz durch die Überprüfung der Artefakte, die Erkennung von Mustern, intensives Zuhören, und die Erkennung von Abweichungen zwischen den erwarteten und den tatsächlichen Resultaten auf. Scrum Reader DasScrumTeam 29

30 1 Der Scrum Guide Die Aufgabe des Scrum Masters ist es, mit dem Scrum Team und der Organisation an der Verbesserung der Transparenz der Artefakte zu arbeiten. Diese Arbeit bedeutet zumeist Lernen, Überzeugen und Verändern. Transparenz fällt einem nicht in den Schoß, sie ist ein Weg, den es zu beschreiten gilt. Definition of Done Es müssen alle verstehen, was Done bedeutet, sobald ein Product Backlog-Eintrag oder ein Produkt-Inkrement als Done bezeichnet wird. Obwohl sich dies erheblich von Scrum Team zu Scrum Team unterscheidet, müssen alle Teammitglieder ein gemeinsames Verständnis davon haben wann Arbeit fertig ist, um Transparenz zu gewährleisten. Dies erfolgt durch die Definition of Done des Scrum Teams und wird dazu verwendet festzustellen, wann die Arbeit an einem Produkt-Inkrement fertig ist. Die gleiche Definition leitet das Entwicklungsteam bei der Entscheidung, wie viele Product Backlog-Einträge es während des Sprint Plannings selektieren kann. Der Zweck eines jeden Sprints ist es, Inkremente potentiell auslieferbarer Funktionalität zu liefern, die der aktuellen Definition of Done des Scrum Teams entsprechen. Entwicklungsteams liefern jeden Sprint ein Inkrement an Produktfunktionalität. Dieses Inkrement ist vollständig verwendbar, so dass der Product Owner sich jederzeit dazu entscheiden kann, es zu releasen. Wenn die Definition of Done für ein Inkrement Teil der Konventionen, Standards oder Richtlinien der Entwicklungsorganisation ist, müssen alle Scrum Teams diese als Minimalziel befolgen. Wenn Done für ein Inkrement nicht Teil der Konvention der Entwicklungsorganisation ist, muss das Entwicklungsteam des Scrum Teams eine für das Produkt geeignete Definition of Done formulieren [Anm. d. 30 Scrum Reader DasScrumTeam

31 Schlussbemerkung Übers.: Das heißt nicht, dass Product Owner und Scrum Master nicht eingebunden werden]. Wenn es mehrere Scrum Teams gibt, die am selben System- oder Produktrelease arbeiten, müssen alle Entwicklungsteams aller Scrum Teams gemeinsam eine Definition of Done erstellen. Jedes Inkrement ist additiv zu allen früheren Inkrementen und gründlich getestet, um sicherzustellen, dass alle Inkremente gemeinsam funktionieren. Von gereiften Scrum Teams wird erwartet, dass sie ihre jeweilige Definition of Done erweitern, um strengere Kriterien für eine höhere Qualität sicherzustellen. Jedes einzelne Produkt oder System sollte eine Definition of Done haben, welche den Standard für jegliche daran durchgeführte Arbeit darstellt. Schlussbemerkung Scrum ist kostenlos und wird in Form dieses Guides angeboten. Die Rollen, Artefakte, Ereignisse und Regeln von Scrum sind unveränderlich. Es ist zwar möglich, nur Teile von Scrum einzusetzen - das Ergebnis ist dann aber nicht Scrum. Scrum existiert nur in seiner Gesamtheit und funktioniert sehr gut als Container für andere Techniken, Methoden und Praktiken. Danksagungen Menschen Von den tausenden Menschen, die zu Scrum beigetragen haben, sollten wir diejenigen besonders hervorheben, die für Scrum in seinen Scrum Reader DasScrumTeam 31

32 1 Der Scrum Guide ersten zehn Jahren von besonderer Bedeutung waren. Am Anfang standen Jeff Sutherland, welcher mit Jeff McKenna arbeitete, sowie Ken Schwaber, welcher mit Mike Smith und Chris Martin zusammenarbeitete. Viele weitere haben in den folgenden Jahren einen Beitrag geleistet. Ohne deren Hilfe wäre Scrum nicht so ausgefeilt, wie es heute ist. Historie Ken Schwaber und Jeff Sutherland haben Scrum gemeinsam zum ersten Mal auf der OOPSLA Konferenz 1995 präsentiert. Diese Präsentation dokumentierte im Kern die Erkenntnisse, die Ken und Jeff in den vorher vergangenen Jahren bei der Anwendung von Scrum gewonnen hatten. Die Geschichte von Scrum kann man heute schon als recht lang ansehen. Zur Würdigung der ersten Orte, an denen Scrum ausprobiert und verfeinert wurde, möchten wir hier Individual, Inc., Fidelity Investments und IDX (heute GE Medical) hervorheben. Der Scrum Guide dokumentiert Scrum, so wie es seit über 20 Jahren von Jeff Sutherland und Ken Schwaber konzipiert und weiterentwickelt wird. Andere Quellen liefern Ihnen Modelle, Prozesse und Einsichten, die das Rahmenwerk von Scrum ergänzen. Damit lassen sich die Produktivität, der Wert, die Kreativität und der Stolz auf das Erreichte beständig erhöhen. Übersetzung Dieser Guide wurde von der englischen Originalversion, bereitgestellt von Ken Schwaber und Jeff Sutherland, übersetzt. Beigetragen zur Übersetzung haben: 2011 Dominik Maximini, Andreas Schliep, Ulf Schneider, Wolfgang Wiedenroth 32 Scrum Reader DasScrumTeam

33 Schlussbemerkung 2013 Jan Gretschuskin, Dominik Maximini, Pascal Naujoks, Sabrina Roos, Andreas Schliep, Wolfgang Wiedenroth Lizenz 2015 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http: //creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons. Scrum Reader DasScrumTeam 33

34

35 2 Sieben Praktiken für die effektive Scrum-Implementierung Peter Beck In diesem Text lernst Du: Warum Scrum die besten Prinzipien für effektives Change Management bietet // Wie Scrum die Organisation herausfordert // Die wichtigsten Erfolgsfaktoren für die Implementierung von Scrum // Zwischen etwas zu verstehen, und es umsetzen können, liegen oft Welten. Sie verstehen Scrum vielleicht schon ziemlich gut und haben ihr erstes Scrum-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 Agiles Management, P A M ( veröffentlicht. Jede Organisation ist einzigartig, daher wirst Du keine Standardlösung finden. Ihr müsst Deinen Scrum-Implementierungsansatz auf die speziellen Bedürfnisse eurer Organisation anpassen. Zum Glück gibt es heute einen umfangreichen Schatz an Kenntnissen und Erfahrungen über Scrum-Implementierungen und anscheinend sind einige Praktiken essentieller als andere für eine effektive und erfolgreiche Scrum-Einführung. Diese sieben Praktiken für eine effektive Scrum-Implementierung geben euch immer noch nicht die Lösung für alle Probleme an die Hand. Einige davon sind für eure Organisation vielleicht wichtiger als andere. Andere spezifische und für eure Organisation bedeutsame Praktiken fehlen wahrscheinlich. Dennoch kann diese Auflistung euch Vorteile beim Start mit Scrum verschaffen dem ersten Scrum-Prinzip gemäß: Liefere frühzeitig und regelmäßig. Ermittle,

36 2 Sieben Praktiken für die effektive Scrum-Implementierung welche dieser Praktiken euch weiterhelfen und Mehrwert für eure Organisation erbringen. Lasst Praktiken aus oder erarbeitet eigene, bessere. Folge den Prinzipien Die beste Ausgangsbasis für die Weiterentwicklung von Scrum ist Scrum selbst. Alle Maßnahmen, die ihr für die Einführung von Scrum in 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 Systeme zu unterstützen. Organisationen sind komplex; die Implementierung von Scrum in traditionellen Umfeldern ist sogar noch komplexer. Die Planung und Umsetzung von organisatorischen Änderungen mit dem Scrum-Rahmenwerk garantiert euch die kontinuierliche Lieferung. Ihr gewinnt an Vertrauen innerhalb eures Umfeldes, weil der neue Ansatz Resultate bringt. Zudem sendet ihr die richtigen Signale aus: Wir vertrauen auf und nutzen den neuen Ansatz, und wir sehen, dass er funktioniert. 36 Scrum Reader DasScrumTeam

37 Beginnt mit einem dringenden und wichtigen Projekt Beginnt mit einem dringenden und wichtigen Projekt Wir setzen Scrum nicht zum Selbstzweck ein, sondern um ein besseres Produkt auf effizientere Weise zu liefern. Scrum sollte uns dabei helfen, 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 Fehlschlag am schmerzvollsten, wo sehen wir den höchsten Wert für unsere Organisation? Das sind die Ansprüche, die ihr an ein Pilotprojekt mit Scrum stellen solltet. Die Scrum-Implementierung und das Projekt profitieren voneinander. Wenn das Projekt bedeutsam genug ist, ist die Umsetzung der erforderlichen Organisationsänderungen wesentlich erleichtert. Das steigert 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 euch dabei, indem es kontinuierlich dazu beiträgt, Risiken aufzuzeigen. So werdet ihr auf jeden Fall frühzeitig herausfinden, ob das Projekt vom Scheitern bedroht ist was euer Vertrauen in Scrum eher noch bestärken wird. Es wird transparent, ob euer Projektziel im zeitlichen oder finanziellen Rahmen liegt. Die Wahrheit ist manchmal hart. Ihr müsst nur Sorge dafür tragen, dass niemand diese Tatsache fehlinterpretiert und versucht, Scrum als Sündenbock zu nutzen. Scrum Reader DasScrumTeam 37

38 2 Sieben Praktiken für die effektive Scrum-Implementierung Arbeite mit den richtigen Menschen nimm die Pioniere Es ist kein Geheimnis, dass der Erfolg eines Projekts maßgeblich davon abhängt, die richtigen Leute an Bord zu haben. Insbesondere bei Ihren ersten Scrum-Projekten solltet ihr dafür sorgen, dass ihr agile 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ögliche Wissen in ihrem Arbeitsbereich haben. Dies betrifft sowohl technisches als auch betriebswirtschaftliches Wissen. Allerdings ist ein Großteil dieses Wissens nicht entscheidend für komplexe Projekte andernfalls wären sie nicht komplex. Daher sollten Sie vorhandenes Wissen nicht überbewerten. Euer Team muss durch bisher unerforschte Bereiche gehen. Dazu kommt, dass es nun im Mittelpunkt steht: Werden Scrum und das Team gewinnen oder verlieren? Ihr müsst auf vielen Ebenen gleichzeitig spielen. Es gibt natürliche Schwierigkeiten in eurem Projekt und versteckte Kräfte, die gegen euer neues Vorgehen arbeiten. Spielt dieses Spiel nicht ohne die Besten. Ein sehr guter Weg, die Besten zu finden, ist dass ihr euch und euer Projekt finden lasst. Bewerbt einfach das neue Vorgehen und stellt dar, dass ihr nach Pionieren sucht. Gebt zum Beispiel einen 4- stündigen Scrum-Einführungsworkshop und stellt sicher, dass jeder in Ihrer Organisation die Möglichkeit hat, daran teilzunehmen. Fragt 38 Scrum Reader DasScrumTeam

39 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 trotzdem noch gebraucht. Diese sollten ihr Wissen an den Rest der Organisation weitergeben. Vielleicht sind einige einem Scrum-Einführungsoder Verbesserungsteam mit der Absicht beigetreten, Scrum in der gesamten Organisation einzuführen oder schwierige organisatorische Verä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 in seinem Sponsor finden. Der Sponsor ist jemand, der stark in die Organisation eingebunden ist, große Entscheidungskompetenz hat und die Führungsstrategie beeinflusst. In den meisten Fällen ist dies der CEO, CTO oder jemand, der diesen sehr nahe ist. Einige Organisationen können nicht mit einem solch mächtigen Sponsor starten. Allerdings wird Scrum die Führungsetage sehr früh nach dem Start der ersten Scrum-Teams herausfordern. In dem Fall, dass du nicht in einer mächtigen Position bist, versuche, eine gute Person dafür zu finden, sie dafür vorzubereiten, Sponsor der Scrum- Einführung zu werden. Der Sponsor ist für Priorisierung und Entscheidungen über notwendige Verbesserungen und Änderungen der Schwierigkeit zuständig. Es ist ein guter Weg, diesen Sponsor zum Product Owner eines Scrum- Einführungs- oder Verbesserungsteams zu machen. Dieses Team übernimmt die Aufgabe, die organisatorischen Änderungen mithilfe von Scrum mit voller Unterstützung des Sponsors durchzuführen. Zusammen mit dem Sponsor entwickelt dieses Team eine Strategie für die Einführung von Scrum in der Organisation. Es sollte außerdem Scrum Reader DasScrumTeam 39

40 2 Sieben Praktiken für die effektive Scrum-Implementierung eine Scrum-Einführungs- und Verbesserungs-Architektur entwickelt werden, die sich an den Bedürfnissen der Organisation orientiert. Das folgende Bild reduziert solch eine Struktur auf ein einzelnes Bild. Denk daran: jede Organisation ist anders. Daher benötigt jede Organisation ihren spezifischen Aufbau. Vergiss außerdem nicht, euer Vorgehen zu untersuchen und anzupassen. Agile Transition Architecture Improvement Charter and Vision Strategic Improvement Backlog / Kanban Team and Produkt Backlogs Sponsor / Executive Management Participation Overall Retrospective Go and See Replenishment Improvement Kanban ScrumMaster / Coaches Communities (Team Representatives) Overall Retrospective Organisation Impediments Cross Team Impediments Team Impediments Scrum Teams Team Retrospectives Bezieht das mittlere Management ein Normalerweise kommt der größte Widerstand gegen Scrum aus dem mittleren Management, da diese Gruppe Verlust am meisten fürchtet. Und sie haben Recht, da Scrum dahin tendiert, die Hierarchie abzuflachen. Menschen im mittleren Management werden ihre Dienste, Verantwortungen und Führungsmethoden drastisch ändern müssen. Durch das Einbeziehen dieser Gruppe in die Wandlung in eine hocheffiziente Scrum-Organisation kannst du Widerstand in Unterstützung wandeln. Und wieder: Frag dich, wer in den Prozess einbezogen wird und wer dem Fortschritt im Weg steht. Das Abflachen der 40 Scrum Reader DasScrumTeam

41 Trainiert eure Mitarbeiter und bietet Unterstützung an Hierarchie bedeutet nicht zwangsläufig die Verringerung der Mitarbeiterzahl, aber es ist eine Tatsache, dass einige die Organisation verlassen und neue Mitarbeiter kommen werden. Bereitet eure Organisation darauf vor, dass jede Veränderung eine Möglichkeit ist sogar für jene, welche dadurch die Organisation verlassen. Trainiert eure Mitarbeiter und bietet Unterstützung an Wir kennen das vom Sport: Ohne Training sollten wir nicht zum Spiel gehen. Das trifft auf dieses neue Spiel Scrum zu. Wir müssen Muskeln und Reflexe trainieren, die selten oder nie zuvor benutzt wurden. Andererseits sind andere Muskeln gut entwickelt und hindern uns daran, uns passend zu den neuen Spielregeln zu bewegen. Erklärt den Mitarbeitern die neuen Regeln, bevor ihr die Einführung von Scrum beginnt. Gebt bewährte Methoden weiter, damit die richtigen Muskeln und Reflexes bereit sind für den ersten Sprint. Es ist wichtig, dass jeder Stakeholder zumindest mit den Scrum-Regeln vertraut ist. Andernfalls könnt ihr sicher sein, dass jemand diese bricht. Spezielles Training für spezifische Rollen ist dabei weniger wichtig und kann später angeboten werden. Bei Scrum wird früh geliefert. Nach einem kurzen Training solltet ihr für den Start bereit sein. Jedoch sind viele Dinge noch unklar und die wirklich großen Fragen treten während der ersten Sprints auf. Ihr solltet euren Teams Unterstützung und Hilfe anbieten. Führung durch einen Scrum-erfahrenen Mitarbeiter oder Coach erhöhen das Vertrauen, das nötig ist, um mit Scrum zu beginnen und lässt zu, dass das Team sich auf die wirkliche Herausforderung konzentriert: das Projekt. Scrum Reader DasScrumTeam 41

42 2 Sieben Praktiken für die effektive Scrum-Implementierung Ja, du weißt es bereits: jede Organisation ist anders, jede Organisation benötigt einen speziellen Trainingsplan. Und ja, du musst diesen Plan auch anpassen, aber du findest hier ein Beispiel: Introduction Management Kick-off Scrum steering group Scrum Workshop HR, Line Mgmt. Workshop Scrum PM Coaching Scrum Implementation Management Scrum Readiness Workshop Certified ScrumMaster Training Certified Product Owner Training Scrum Team Training Clean -up Coaching Agile Facilitation Training Coaching Agile Planning and Estimation ScrumMaster Product Owner Coaching XP / Agile Engineering Practices Development Team Sprint 1 Sprint 2 Sprint 3 Richtiges Marketing Scrum hilft euch, großartige Produkte zu entwickeln und gute Produkte sind die beste Werbung, die ihr haben könnt. Aber wenn eure potenziellen Kunden nicht verstehen, dass ihr ein gutes Produkt anbietet, werden sie auch nichts kaufen. Daher benötigt ihr auch gutes Marketing. Dieselbe Logik trifft auch auf eure Scrum-Einführung zu. Die beste Werbung ist es, erfolgreich zu sein. Allerdings müsst ihr auch darüber nachdenken, wie ihr euren Erfolg in der Organisation verkaufen könnt. Ihr müsst Widerstand und Angst überwinden. Dies jedoch 42 Scrum Reader DasScrumTeam

43 Richtiges Marketing nicht nur mit Argumenten. Ihr müsst vielmehr darüber nachdenken, wie ihr eure Argumente präsentiert, zum richtigen Zeitpunkt mit der richtigen Sprache den richtigen Personen vorbringen. Transparenz und Offenheit bedeuten nicht, dass ihr jedem wahllos alles erzählen solltet. Denkt darüber nach, wer eure Nachricht konsumiert. Denkt über seinen Wohlfühlbereich nach und wie ihr ihn herausfordern 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 (niemand 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 B wählen kann, aber nicht keins von beiden) Scrum Reader DasScrumTeam 43

44

45 3 Neun Übungen für erfolgreiche 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 berufsbegleitenden ScrumMaster-Ausbildung Die Retrospektive ist die Kür des Scrum Masters. Während die anderen Mitglieder des Scrum Teams schon nach kurzer Zeit gut durch die Planungen, Abstimmungen und Reviews kommen, erfordert die Retrospektive stets eine speziell vorbereitete Moderation. Die hier dargestellten Übungen haben wir in unserer Praxis als Scrum Master und Coach in den verschiedensten Teamkonstellationen und Situationen eingesetzt. Natürlich gibt es noch viel mehr Übungen zu entdecken. 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 Einsatz der Übungen Die meisten der hier dargestellten Übungen lassen sich als kleine, eigenständige Retrospektiven durchführen oder zu einer größeren Re-

46 3 Neun Übungen für erfolgreiche Retrospektiven trospektive zusammenstellen. Dabei hilft eine Zuordnung der Übungen zu den bei Derby und Larsen beschriebenen Schritten: Bühne bereiten Informationen sammeln Einsichten gewinnen Aktionen planen Abschluss Übung Was lief gut... X X Zeitleiste Seestern X X X Emotionale Trendlinie X X Forscher, Shopper,... X Teamhistogramm X X Teamradar X X X Lob und Dank X X Hilfreich, behindern... X X X 46 Scrum Reader DasScrumTeam

47 Übung: Was lief gut / was können wir verbessern Übung: Was lief gut / was können wir verbessern Englisch: Quelle: Dauer: What went well / what could be improved Ken Schwaber, Agile Project Management with Scrum Minuten Material Flipchart oder Pinnwand Haftnotizen oder Moderationskarten Moderationsmarker Vorbereitung Der ScrumMaster organisiert einen Meetingraum und stellt das Flipchart bzw. die Pinnwand bereit. Die Arbeitsfläche wird in zwei Sektionen unterteilt, die jeweils die Überschriften Was lief gut und Was können wir verbessern erhalten. Einige ScrumMaster verwenden auch einfach Smileys. Für jeden Teilnehmer wird ein Stapel Haftnotizen oder Moderationskarten sowie ein Moderationsmarker oder sonstiger dicker Stift bereitgelegt. Ablauf 1. Bitte die Teilnehmer, an den letzten Sprint zurückzudenken. Scrum Reader DasScrumTeam 47

48 3 Neun Übungen für erfolgreiche Retrospektiven 2. Die Teilnehmer sollen jeweils je Notiz / Karte etwas schreiben, was aus ihrer Sicht im vergangenen Sprint gut gelaufen ist oder verbessert werden könnte. 3. Die Notizen oder Karten werden auf der Arbeitsfläche gesammelt. Dabei werden sie 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. Diese werden an der Arbeitsfläche angebracht und kurz besprochen. Dann erfolgt ein weiteres Brainstorming mit den zu verbessernden Dingen. 2. Jeder Teilnehmer stellt seine Karten beim Anbringen an der Arbeitsfläche selbst vor. 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 Teilnehmern per Dot-Voting priorisiert. Zu beachten Diese Übung führt schon zu recht brauchbaren Resultaten, nutzt sich aber nach einer Reihe von Wiederholungen schnell ab. Als Element einer längeren Retrospektive findet sich diese Übung nach der Betrachtung der Zeitleiste wieder. 48 Scrum Reader DasScrumTeam

49 Übung: Zeitleiste Übung: Zeitleiste Englisch: Quelle: Dauer: Retrospective Timeline Norman Kerth, Project Retrospectives 45 Minuten Material: Flipchart, Pinnwand oder großes Plakat Haftnotizen oder Moderationskarten Moderationsmarker Vorbereitung Der ScrumMaster organisiert einen Meetingraum und stellt das Flipchart bzw. die Pinnwand bereit. Auf der Arbeitsfläche wird ein waagerechter Pfeil gezeichnet. Der Anfang des Pfeils wird mit dem Sprint- Start oder einem anderen signifikanten Datum beschriftet. Das Ende des Pfeils wird dementsprechend mit dem Sprint-Review beschriftet. Ablauf 1. Bitte die Teilnehmer, an den letzten Sprint zurückzudenken. Scrum Reader DasScrumTeam 49

50 3 Neun Übungen für erfolgreiche Retrospektiven 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 die Ereignisse an der Zeitleiste an. Dabei erläutert jeder Teilnehmer seine Karten kurz. 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 Ereignisse werden oberhalb der Leiste, negative darunter gesammelt. Dadurch entsteht ein emotionales Seismogramm des vergangenen Sprints. Beim Anbringen der Ereignisse wird noch nicht gesprochen. Wenn alle Ereignisse angebracht sind, geht der Moderator in der zeitlichen Reihenfolge durch den Zeitstrahl und fragt die Teilnehmer nach ihrer Einschätzung der jeweiligen Beobachtungen. 50 Scrum Reader DasScrumTeam

51 Übung: Seestern Übung: Seestern Englisch: Quelle: Dauer: Retrospective Starfish Patrick Kua, Blog 45 Minuten Material Flipchart oder Pinnwand Haftnotizen oder Moderationskarten Moderationsmarker Scrum Reader DasScrumTeam 51

52 3 Neun Übungen für erfolgreiche Retrospektiven Vorbereitung Der ScrumMaster organisiert einen Meetingraum und stellt das Flipchart bzw. die Pinnwand bereit. Auf der Arbeitsfläche wird ein Seestern siehe Abbildung - gezeichnet. Die dadurch entstehenden Segmente werden mit mehr, weniger, anfangen, aufhören und??? beschriftet. Ablauf 1. Bitte die Teilnehmer, an den letzten Sprint zurückzudenken. 2. Die Teilnehmer sollen sich zu den jeweiligen Segmenten Dinge überlegen, von denen 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 pro Karte und in den Segmenten auf der Arbeitsfläche gesammelt. 4. Je nach Anzahl und Aufwand der identifizierten Punkte erfolgt eine Abstimmung - zum Beispiel durch Punktwertung - über die als erstes zu ändernden oder abzustimmenden Themen. Varianten Der Moderator kann auch die englischen Beschriftungen verwenden: more of, less of, start doing, stop doing und puzzles. 52 Scrum Reader DasScrumTeam

53 Übung: Emotionale Trendlinie Übung: Emotionale Trendlinie Englisch: Quelle: Dauer: Emotions Seismograph Norman Kerth, Project Retrospectives 10 Minuten Material Flipchart oder Pinnwand Moderationsmarker, am besten farbig sortiert Vorbereitung Der ScrumMaster organisiert einen Meetingraum und stellt das Flipchart bzw. die Pinnwand bereit. Auf dieser Arbeitsfläche wird wie bei Scrum Reader DasScrumTeam 53

54 3 Neun Übungen für erfolgreiche Retrospektiven der Zeitleiste ein Pfeil gezeichnet, der mit den Eckdaten des letzten Sprints beschriftet wird. Zusätzlich wird der Pfeil noch weiter in Wochen oder Arbeitstage unterteilt, um die Übersicht zu erhöhen. Über und unter dem Pfeil sollte in etwa gleich viel Platz gelassen werden. Ablauf 1. Bitte die Teilnehmer, an den letzten Sprint zurückzudenken. 2. Jeder Teilnehmer erhält einen Moderationsmarker. 3. Die Teilnehmer sollen über den Verlauf des ganzen Sprints einzeichnen, wie gut sie sich zu dem jeweiligen Zeitpunkt gefühlt haben. 4. Wenn alle Teilnehmer ihre individuelle Linie gezeichnet haben, zeichnest du den Trend des Sprints als besonders gekennzeichnete Linie nach. 5. Besprecht den Lauf des Sprints. Dabei sind einige Datenpunkte besonders interessant: a. Tiefpunkte, an denen sich die meisten Linienverläufe im unteren Bereich treffen. b. Höhepunkte, an denen sich die meisten Linienverläufe im oberen Bereich treffen. c. Kontrastpunkte, an denen die Beurteilungen der Teilnehmer besonders deutlich voneinander abweichen. Varianten Die emotionale Trendlinie lässt sich gut mit der Übung: Zeitleiste kombinieren. 54 Scrum Reader DasScrumTeam

55 Übung: Forscher, Shopper, Urlauber und Gefangener Übung: Forscher, Shopper, Urlauber und Gefangener Englisch: Quelle: Dauer: ESVP Explorer, Shopper, Vacationer, Prisoner Esther Derby, Diana Larsen: Agile Retrospectives Minuten Material Flipchart für ein Histogramm Haftnotizen oder Moderationskarten für die Abstimmung Moderationsmarker Vorbereitung Der ScrumMaster organisiert einen Meetingraum und stellt das Flipchart 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ücklich über die Pause von der täglichen Routine. Scrum Reader DasScrumTeam 55

56 3 Neun Übungen für erfolgreiche Retrospektiven Gefangene fühlen sich zur Retrospektive gezwungen und würden lieber etwas anderes tun. 3. Verteile die Wahlzettel und lass jeden einen Buchstaben F, S, U oder G geheim darauf schreiben. 4. Mache die Auswertung öffentlich und achte dabei darauf, dass niemand erkennen kann, von wem welcher Zettel war. 5. Frage die Gruppe: Was denkt ihr über das Ergebnis? Leite eine kurze Diskussion darüber, wie diese Einstellungen das Ergebnis der Retrospektive beeinflussen werden. 6. Frage zum Abschluss: Passen diese Kategorien zu unserer Einstellung zur täglichen Arbeit? 56 Scrum Reader DasScrumTeam

57 Übung: Teamhistogramm mit Perspektivenwechsel Übung: Teamhistogramm mit Perspektivenwechsel Englisch: Quelle: Dauer: Satisfaction Histogram Esther Derby, Diana Larsen: Agile Retrospectives 20 Minuten Material Flipchart für ein Histogramm Vorbereitetes Flipchart mit den 5 Stufen Haftnotizen oder Moderationskarten für die Abstimmung Moderationsmarker Scrum Reader DasScrumTeam 57

58 3 Neun Übungen für erfolgreiche Retrospektiven Vorbereitung Der ScrumMaster organisiert einen Meetingraum und stellt die Flipcharts bzw. die Pinnwände mit den fünf Stufen bereit. 5. Ich denke, wir sind das beste Team der Welt! Wir arbeiten super zusammen! 4. Ich bin froh, Teil des Teams zu sein, und zufrieden mit unserer Zusammenarbeit. 3. Ich bin einigermaßen zufrieden. Wir arbeiten meistens ganz gut zusammen. 2. In manchen Momenten bin ich zufrieden. Aber nicht oft genug. 1. Ich bin unglücklich und unzufrieden mit unserer Zusammenarbeit. Ablauf 1. Erläutere den Ablauf. 2. Für eine Abstimmung zu der Frage Wie zufrieden seid Ihr mit Eurer Leistung als Team? erläuterst Du die folgenden 5 Stufen anhand eines vorbereiteten Flipcharts. 3. Sammle die Abstimmungskarten mit den Zahlen der Teilnehmer geheim ein und sorge bei der Auswertung dafür, dass niemand die Werte Personen zuordnen kann. 4. Moderiere das Gespräch über das Ergebnis. 58 Scrum Reader DasScrumTeam

59 Übung: Team Radar Übung: Team Radar Englisch: Quelle: Dauer: Team Radar Esther Derby, Diana Larsen: Agile Retrospectives Minuten Überblick Diese Übung hilft dem Team sichtbar zu machen wie gut sie in bestimmten Feldern wie z.b. Treue zu Ihren Teamwerten, Entwicklungspraktiken oder Kommunikation untereinander sind. Material Flipchart oder Pinnwand mit einem leeren Radar Chart die Achsen können schon beschriftet sein. Haftnotizen oder Moderationskarten Moderationsmarker Scrum Reader DasScrumTeam 59

60 3 Neun Übungen für erfolgreiche Retrospektiven Vorbereitung Der Scrum Master organisiert einen Meetingraum und stellt das Flipchart bzw. die Pinnwand bereit. Ablauf 1. Du erläuterst den Ablauf mit den Worten: Wir stimmen darin überein, dass diese Felder wichtig für unsere Arbeit sind. Lasst uns herausfinden, wie gut wir 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 auf einen Wert einer Achse zu setzen. 3. Moderiere eine kurze Diskussion darüber, wie diese Felder die tägliche Arbeit beeinflussen. 4. Bewahre das fertige Diagramm auf. Mache die selbe Aktivität ein paar Iterationen später wieder und vergleiche zusammen mit dem Team die beiden Ergebnisse. Varianten Um eine gegenseitige Beeinflussung beim Kleben der Punkte auszuschließen, können die Zahlenwerte auch geheim auf Kärtchen geschrieben werden. Du malst dann als Moderator nur den Mittelwert an die Achse. Für ein größeres Set an Achsen teilst Du einen Fragebogen aus und wertest das Ergebnis nach der Retrospektive mit Hilfe von Excel aus. Das Ergebnis daraus wird dann Thema der nächsten Retrospektive sein. 60 Scrum Reader DasScrumTeam

61 Übung: Lob und Dank Übung: Lob und Dank Englisch: Quelle: Dauer: (Offer) Appreciations Norman Kerth: Project Retrospectives Esther Derby, Diana Larsen: Agile Retrospectives 5 30 Minuten Überblick Erlaube allen Teilnehmern der Retrospektive, sich bei der Gruppe oder einzelnen zu bedanken. Das gibt zum Ende eine positive Grundstimmung. Material Nichts Vorbereitung Die Gruppe sitzt im Stuhlkreis oder steht im Kreis ohne Tisch oder ein 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 Gelingen der Retrospektive beigetragen haben und sprechen unseren Dank dafür aus. Scrum Reader DasScrumTeam 61

62 3 Neun Übungen für erfolgreiche Retrospektiven 2. Demonstriere das Format mit einem Teammitglied. Auch wenn es eine Demonstration ist, wähle eine Person, der Du ehrlich dankbar bist. Sage den Namen und dann Ich danke dir für... Fülle die Lücke mit etwas über die Person, oder etwas, das sie oder er getan hat. Ein Beispiel wäre: Andreas, ich danke Dir für deine Hilfe beim Verstehen, wie wertvoll gute innere Qualität für unser Produkt ist. 3. Setze Dich wieder. Warte. Irgendjemand wird als nächster seinen Dank aussprechen. Wenn die Abstände zwischen den Danksagungen länger werden, warte. Lasse die Stille zu. Manche Menschen brauchen Zeit, um sich einen Ruck zu geben. 4. Beende die Übung, wenn mehr als eine Minute verstreicht, ohne dass jemand spricht. Varianten Die Übung kann um weitere Abfragen ergänzt werden. Wir verwenden diesen Austausch gerne als Temperature Reading : Lob und Dank Fragen und Antworten Beschwerden mit Verbesserungsvorschlägen Neue Erkenntnisse und Informationen Hoffnungen und Wünsche 62 Scrum Reader DasScrumTeam

63 Übung: Hilfreich, Behindernd, Hypothesen Übung: Hilfreich, Behindernd, Hypothesen Englisch: Quelle: Dauer: Helped, Hindered, Hypothesis Esther Derby, Diana Larsen: Agile Retrospectives 5-10 Minuten Überblick Der Retrospektiven-Moderator sammelt Feedback von den Teilnehmern ein. Ziel ist es herauszufinden was mehr und was wenig hilfreich beim Lernen war. Daraus entstehen auch neue Ideen für folgende Retrospektiven. Material 3 vorbereitete Flipcharts mit Überschiften: Hilfreich, Behindernd, Hypothesen Haftnotizen Moderationsmarker Vorbereitung Hänge die 3 Flipcharts auf. Ablauf 1. Zeige die 3 Flipcharts und erkläre: Bitte helft mir ein besserer Retrospektiven Moderator zu werden. Gebt mir Feedback zu dieser Retrospektive. Diese drei Scrum Reader DasScrumTeam 63

64 3 Neun Übungen für erfolgreiche Retrospektiven Flipcharts sind für Dinge, die Euch beim Lernprozess geholfen haben, für Dinge die Euch dabei behindert oder gestört haben, und das dritte ist für Ideen, was ich anders machen könnte, um die nächste Retrospektive für Euch effektiver zu gestalten. 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 ich eine 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 offenbart die Übung unter Umständen auch Informationen über die (unterschiedlichen?) Ziele und Vorstellungen der einzelnen Teammitglieder und dient damit auch der Reflektion für die Gruppe selber. 64 Scrum Reader DasScrumTeam

65 4 Scrum Coaching Peter Beck und Andreas Schliep Die Stärke von Scrum ist dessen Einfachheit. Diese Einfachheit täuscht aber häufig über die tatsächlichen Anforderungen bei der Einführung hinweg, da die Grundprinzipien von Scrum darauf abzielen, stetig Veränderungen in der Organisation zu bewirken. Insbesondere bei der Einführung von Scrum sind diese Veränderungen sehr komplex. Verantwortungen verlagern sich, Teams formieren sich um, Arbeitsweisen werden angepasst und Führungsaufgaben müssen neu überdacht werden. Für einige steht die positive Energie der Aufbruchsstimmung im Vordergrund, für andere sind es Unsicherheit und Angst. Beides sind notwendige Strömungen bei Veränderungen in einer funktionierenden Organisation und müssen verstanden und genutzt werden. Die Komplexität einer Scrum-Einführung bedarf eines breiten Spektrums differenzierter Maßnahmen, die wir alle erfolgreich erprobt haben. Unsere Beobachtung hat dabei gezeigt, dass diese sich in einander aufbauenden Ebenen einordnen lassen. Diese Ebenen sind nicht streng voneinander getrennt, helfen aber die Maßnahmen besser zu verstehen und einzuordnen. Prozess Wachstum Ausgleich Transfer Training Auftrag Abholung Ziele Erfolge

66 4 Scrum Coaching Prozess Eine Scrum-Einführung ist ein komplexes Vorhaben. Also genau das richtige Einsatzgebiet für Scrum. Kein Wunder also, dass wir Scrum verwenden, um Scrum einzuführen. Je nach Situation, Bedarf und Notwendigkeit gewichten wir gemeinsam mit unserem Kunden die Maßnahmen jeder Ebene. Die Maßnahmen werden in regelmäßigen Abständen geplant, durchgeführt und verifiziert. Natürlich lernen und verbessern wir den Prozess auch bei einer Scrum-Einführung durch Retrospektiven. Je nach Größe und Komplexität empfehlen wir ein multidisziplinäres Team, zusammengesetzt aus externen Trainern, Coaches und Mitarbeitern der Organisation, um die Einführung von Scrum zu begleiten. Nicht selten beginnen wir den Prozess mit einer Team- oder Projekt- Retrospektive oder mit der Analyse der Ist-Situation. Mit dem Auftraggeber werden Ziele definiert und daraus geeignete Maßnahmen abgeleitet, welche in einer Coaching-Iteration umgesetzt werden sollen. Der Erfolg und die Wirkung der Maßnahmen wird am Ende einer jeder Coaching-Iteration evaluiert. Die gewonnenen Erkenntnisse fließen dann in die Planung der nächsten Iteration mit ein. Uns liegt besonders das Verhältnis von Auftraggeber und Coaches am Herzen. Letztendlich liegt hier der Kern des Erfolges jedes Coaching- Vorhabens. Klare, messbare Ziele bei Auftragsvergabe, Anpassung an den tatsächlichen Bedarf und ein von Anfang an festgelegtes Austrittszenario garantieren, dass die Organisation selbst Verantwortung für die Verbesserungen übernimmt und erfolgreich weiterführt. Abholung Es gibt viele Motivationen Scrum einzuführen. Bei der Abholung öffnen wir den breiten Bogen der Wünsche, Erwartungen, Hoffnungen 66 Scrum Reader DasScrumTeam

67 Training und Befürchtungen, um sie in den Prozess einfließen zu lassen. Außerdem definieren wir gemeinsame Ziele, die wir später bei der Evaluierung 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 Zielsetzung zu erarbeiten. Training Die Scrum Trainings schaffen eine gemeinsame Wissensbasis in den Teams und untermauern das Rollenverständnis von ScrumMaster, Product Owner und Team. Neue Methoden, Techniken werden eingeübt und im Rückenmark gespeichert. Altes wird über Bord geworden und erfolgreich verlernt. Das Scrum Team Jumpstart Training bildet oft die Grundlage und wir empfehlen, dass das gesamte Scrum Team an einem solchen Training teilnimmt. Natürlich können die Teilnehmer bei uns den Certified ScrumMaster oder Certified Product Owner erwerben. Weiterführende und rollenspezifische Kurse runden das Angebot ab. Transfer Nach den Trainings unterstützen wir als Coaches den Transfer des Gelernten in die tägliche Praxis. Wir begleiten Ihre Teams mit einer Mischung aus systemischer Grundhaltung, fachlicher Beratung und Trainingselementen. Ziel ist dabei, dass die Mitarbeiter selbst die Verantwortung für den Transfer übernehmen. Nur dann kann gewährleistet werden, dass die vereinbarten Veränderungen tatsächlich gelebt werden. Typische Transfermaßnamen sind der Scrum bei uns -Workshop oder die ScrumMaster-Gruppe. Scrum Reader DasScrumTeam 67

68 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 viel Wert darauf, dass diese Lücken nicht implizit kompensiert werden. Die Kompensation dieser Lücken würde Probleme verdecken und so den Lernprozess behindern. Gleichzeitig ist der Ausgleich von Lücken mit qualifizierten ScrumMastern, Moderatoren und Projektmitarbeiten aber notwendig um Vertrauen in den neuen Ansatz aufzubauen, Erfolge zu feiern und die Befruchtung mit neuen Ideen von Außen zuzulassen. Ausgleich findet in Mentoring- und Interimsfunktionen 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 Aufgaben, um dann im dritten Schritt nur noch bei Bedarf als Unterstützer und 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 im Einführungsprozess vorzusehen. Zum Beispiel durch das Einrichten von Multiplikatoren-Gruppen und internen Informationsangeboten. So können Ängste und Widerstände schon im Vorfeld abgefedert werden. Dieser Wachstumsprozess muss im Senior-Management verankert werden. Eine Maßnahme ist dabei die Bildung einer Steuerungsoder Supportgruppe. 68 Scrum Reader DasScrumTeam

69 5 ScALeD Scaled Agile and Lean Development ScALeD Principles Agile Produktentwicklung hat sich für die Entwicklung in komplexen Umgebungen bewährt und verbreitet sich immer stärker. In der Anfangszeit wurden agile Prinzipien und Methoden vornehmlich bei kleineren Vorhaben eingesetzt. Mit der Zeit wurden mehr und mehr größere Entwicklungsvorhaben agil entwickelt. Dabei werden die Herausforderungen 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 betrachten, um eine eigene Lösung für die Skalierung von Agilität abzuleiten. Wir sind der Meinung, dass für die agile Skalierung keine neue Methode und auch kein zusätzliches Framework notwendig ist. In diesem Sinne sind die vorgestellten Prinzipien auch nicht als neu zu verstehen. Wir haben lediglich das unter Skalierungsgesichtspunkten formuliert, was immer schon agiles Gedankengut war. Entsprechend nehmen wir hier auch keine weitreichenden Eigentumsrechte in Anspruch. Der Text kann ganz oder teilweise reproduziert werden, wenn auf die Webseite verwiesen wird. Begeisterte Kunden Begeisterte Kunden sind der Garant für jedes Unternehmen, langfristig zu wachsen. Die Aufgabe der Produktentwicklung ist es, die Grundlage für dieses Wachstum zu schaffen.

70 5 ScALeD Scaled Agile and Lean Development Definiere, was Wert bedeutet und schafft Das gemeinsame Verständnis über die wertschöpfenden Elemente muss gerade in einer skalierten Produktorganisation bei allen Mitarbeitern vorhanden sein. Leitbilder helfen dabei, die strategischen Ziele zu erreichen. Ein klares Wertverständnis gibt gemeinsame Orientierung. Produziere kleine, lieferbare Inkremente Inkremente bauen aufeinander auf und beinhalten stets den Nutzen und die Funktionalität der vorherigen Inkremente. Daher eignen sie sich ausgezeichnet zur Herstellung und Messung von Mehrwert. Ein lieferbares Inkrement eines Produktes hat somit qualitativ alle Eigenschaften, die man zur Auslieferung braucht, wobei die Produktorganisation Stück für Stück die fehlenden funktionalen und nichtfunktionalen Eigenschaften ergänzt. Im Idealfall kann der Wert eines Inkrements sofort in Nutzen für den Kunden umgesetzt werden. Doch auch wenn das nicht möglich ist, bieten kleine, lieferbare Inkremente die Basis für die kontinuierliche Verbesserung des Produkts, sie minimieren Risiken und reduzieren Komplexität. Zufriedene produktive Mitarbeiter In der Produktentwicklung stellen Mitarbeiter das größte Potenzial für Verbesserungen dar. Zufriedene Mitarbeiter sorgen für höhere Produktivität. Deshalb ist es wichtig, eine Arbeitsumgebung zu schaffen, die eine hohe Mitarbeiterzufriedenheit sicherstellt. 70 Scrum Reader DasScrumTeam

71 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 Teams gelten auch auf der Ebene mehrerer Teams. Teams müssen in der Lage sein, sich untereinander eigenständig und ohne künstliche Hindernisse zu verständigen. Die Aufgabe des Unternehmens ist es, die dafür erforderlichen Ziele, Strukturen, Freiräume und Unterstützung bereitzustellen. Bevollmächtige und befähige die Mitarbeiter Mitarbeiter brauchen nicht nur technische Fertigkeiten, sondern auch die 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 selbstorganisiert zu arbeiten. Globale Optimierung Bei der agilen Skalierung ist eine Aufteilung des Produktes in (möglichst lose gekoppelte) Komponenten unumgänglich. Eine rein lokale Optimierung der Komponenten führt in der Regel auf der Ebene der Gesamt-Wertschöpfungskette zu einer Sub-Optimierung. Daher muss sichergestellt werden, dass immer die Gesamt-Wertschöpfungskette im Blick behalten wird. Scrum Reader DasScrumTeam 71

72 5 ScALeD Scaled Agile and Lean Development Schaffe Transparenz in alle Richtungen Alle Mitwirkenden haben Einblick in alle Informationen, die sie benötigen, um sinnvolle Entscheidungen zur Optimierung der Gesamtsituation zu treffen. Das betrifft insbesondere die Ziele, Gegebenheiten, Entscheidungen und den aktuellen Stand. Dabei reicht es nicht aus, diese Informationen bloß zu sammeln oder statisch bereitzustellen. Der dynamische Austausch von relevanten Informationen ist eine der Grundvoraussetzungen für kontinuierliche Verbesserung. Bevorzuge den persönlichen Kontakt Der persönliche, direkte Kontakt bietet die höchste Bandbreite für den Austausch von Wissen, Fertigkeiten, Zielen, Bedürfnissen, Bedenken. Oftmals werden implizite Informationen erst im direkten Kontakt sichtbar. Persönlicher Kontakt ist nicht nur innerhalb eines Teams wichtig, sondern auch zwischen Teams und mit dem Rest der Organisation. Schaffe Flow & Rhythmus Flow und Rhythmus über die gesamte Wertschöpfungskette sind eine wichtige Voraussetzung für hochperformante Teams. Diese florieren auf der Basis von klaren Zielen, intensiver Synchronisation und schnellen (oder vermiedenen) Übergaben. Unterstützende Führung Führungskräfte haben in einer agilen Umgebung eine wichtige Rolle als Lehrer und Enabler. Als Führungskraft dient man dabei dem 72 Scrum Reader DasScrumTeam

73 Unterstützende Führung Unternehmen und den Mitarbeitern, indem man jeweils das Beste unternimmt, um den Erfolg die Wertschöpfung des Gesamtunternehmens zu unterstützen. Setze Ziele und Rahmenbedingungen Führungskräfte setzen Ziele und Rahmenbedingungen. Sie schaffen Freiraum für das agile Arbeiten, indem bürokratische Hürden beseitigt, starre Strukturen aufgelöst und die Mitarbeiter sukzessive ermächtigt werden. Als Führungskraft dient man dabei dem Unternehmen und den Mitarbeitern, indem man jeweils das Beste unternimmt, um den Erfolg die Wertschöpfung des Gesamtunternehmens zu unterstützen. Dezentralisiere Kontrollstrukturen Selbstorganisation und Eigenverantwortung funktionieren nicht nur innerhalb eines Entwicklungsteams, sondern auch zwischen den Teams. Lange Entscheidungswege verbrauchen wertvolle Entwicklungszeit. Daher muss ein Großteil der Entscheidungen dort getroffen werden können, wo die Arbeit erledigt wird. Für die Koordination mehrerer Teams ist keine hierarchische Steuerungsinstanz notwendig. Sie folgt stattdessen den Prinzipien der Transparenz, der direkten Kommunikation, 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 dem Ausbau agiler Denk- und Vorgehensweisen sollte allen Beteiligten die Philosophie, wesentliche Zielsetzungen und die eigene Rolle bei Scrum Reader DasScrumTeam 73

74 5 ScALeD Scaled Agile and Lean Development diesem Wandel klar sein. Die Aufgabe der strategischen Führung ist hierbei, mit gutem Beispiel voran zu gehen, und den Kulturwandel somit beständig voranzubringen. Kontinuierliche Verbesserung Ein Kernelement von Agilität ist die kontinuierliche Verbesserung, welche auf allen Ebenen und in allen Bereichen der Organisation stattfindet. Kontinuierliche Verbesserung lässt sich durch wiederholte Inspektion und Anpassung herstellen. Die Ergebnisse aus der Inspektion sollten kurze Wege gehen und die Anpassungen schnell umgesetzt werden. Überprüfe das Produkt und passe es an Die häufige Inspektion des Gesamtproduktes und die Adaption der weiteren Planung ermöglichen eine schnelle Anpassung an aktuelle und geänderte Bedürfnisse der Kunden. Dies muss auch und gerade in 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 Teams reflektieren gemeinsam, was in ihrer Zusammenarbeit gut und weniger gut funktioniert, leiten daraus passende Verbesserungsmaßnahmen ab und setzen diese um. 74 Scrum Reader DasScrumTeam

75 Kontinuierliche Verbesserung Überprüfe die Organisation und passe sie an Verbesserung einer agilen Organisation ist nicht eine einmalige Umstellung, sondern ein iterativer Prozess. Vom ersten Tag der Einführung an werden regelmässig Überprüfungs- und Anpassungsschritte vorgenommen. Dafür wird der aktuelle Zustand überprüft, neue Gelegenheiten und Herausforderungen identifziert und Verbesserungsziele bewertet und eingeordnet. Autoren Peter Beck, Markus Gärtner, Christoph Mathis, Stefan Roock, Andreas Schliep Scrum Reader DasScrumTeam 75

76

77 6 Impressum DasScrumTeam AG Bahnhofstrasse Zug Schweiz