Scrum Reader. Scrum Projekt Ablaufplan Von Peter Beck. Scrum Eine Darstellung Übersetzung von agileatlas.org

Transkript

1 Scrum Reader Scrum Projekt Ablaufplan Von Peter Beck Scrum Eine Darstellung Übersetzung von agileatlas.org Scrum besser machen Von Peter Hundermark 7 Praktiken für die effektive Scrum-Implementierung Von Peter Beck 9 Übungen für erfolgreiche Retrospektiven Von Andreas Schliep Scrum-Coaching Von Peter Beck, Andreas Schliep ScALeD Scaled Agile Lean Development Von Peter Beck, Andreas Schliep Scrum Übersicht Von Peter Beck DasScrumTeam AG CH Emanuel Obrist Andreas Schliep Peter Beck Kai Simons Bahnhofstrasse Zug Schweiz tel: mail@dasscrumteam.com

2 Scrum Projekt Ablaufplan PO, Dev. Team & Stakeholder Dev. Team / PO and Stakeholder auf Einladung 6 Wochen bis 18 Monate Backlog Vorbereitung und Schätzung ~ 1 Woche Kick-Off 1,5-3 Stunden Training 2 Tage Aufräumen und Vorbereitung der Arbeitsumgebung ~ 1 Woche Sprint 5-20 Arbeitstage (fix) 3-9 Sprints für 1. Auslieferung Release Planning ~5% vom Sprint; time-boxed; 1/Woche Planning I ~2% der Sprintlänge Planning II ~2% Sprint Daily Meeting 15min täglich Review ~2% der Sprintlänge Retrospective ~2% des Sprints Peter Beck DasScrumTeam.com

3 Scrum eine Darstellung V Scrum Alliance,Inc übersetzt von Sabine Canditt, Markus Gärtner, Andreas Schliep, Jan 2013

4 Scrum-Prinzipien Werte aus dem Agilen Manifest Scrum ist das bekannteste der agilen Frameworks. Es ist der Ursprung eines großen Teils der Gedankengänge, die zu den Werten und Prinzipien des Agilen Manifests geführt haben. Werte und Prinzipien, die wiederum die gemeinsame Basis für alle agilen Ansätze bilden. Das Manifest bietet dazu weitere Informationen. Die Werte des Agilen Manifests treffen direkt auf Scrum zu: Wir schätzen Individuen und Interaktionen mehr als Prozesse und Werkzeuge. Wie alle agilen Frameworks baut Scrum direkt auf das Vertrauen auf Teams, die Individuen in den Teams, und die Art und Weise, wie sie miteinander interagieren. Teams finden heraus, was getan werden muss; Teams finden heraus, wie es zu tun ist; und Teams tun es. Teams erkennen, was ihnen im Weg steht, und übernehmen die Verantwortung, alle Schwierigkeiten zu lösen, die in ihrem Einflussbereich liegen. Teams arbeiten mit anderen Teilen der Organisation zusammen, um die Probleme zu lösen, die außerhalb ihrer Kontrolle liegen. Das ist entscheidend. Der Versuch, nach Scrum vorzugehen, aber den grundsätzlichen Fokus auf die Team- Verantwortlichkeit zu untergraben, wird zu vielen Problemen führen. Wir schätzen funktionierende Software mehr als umfassende Dokumentation. Scrum fordert ein lauffähiges, fertig gestelltes Produktinkrement als das Hauptergebnis jedes Sprints. Natürlich wird es auch Analyse-, Design- und Test-Tätigkeiten geben, die vielleicht alle dokumentiert werden müssen. Aber es ist die funktionierende Software, die es der Organisation ermöglicht, das Projekt zum Erfolg zu führen. Das ist entscheidend. Scrum Teams müssen in jedem Sprint ein Produktinkrement erzeugen. Wir schätzen die Zusammenarbeit mit dem Kunden mehr als die Vertragsverhandlung. Der Scrum Product Owner ist der wichtigste Kontakt des Scrum Teams zum späteren Benutzer des Produktes sowie zu den Teilen der Organisation, die das Produkt benötigen. Der Product Owner ist ein Mitglied des Scrum Teams und arbeitet mit ihm eng zusammen, um festzulegen, was getan werden muss. In dieser Zusammenarbeit wählt der Product Owner die wertvollsten Dinge aus, die als nächstes getan werden müssen, und stellt so sicher, dass das Produkt zu jedem Zeitpunkt den höchstmöglichen Wert hat. Das ist entscheidend. Der Product Owner muss eine reichhaltige Zusammenarbeit mit seinem Team aufbauen. Wir schätzen das Reagieren auf Veränderung mehr als das Befolgen eines Plans: Alles in Scrum ist darauf ausgerichtet, dass jeder die nötigen Informationen hat, um gute Entscheidungen über das Projekt zu fällen. Der Projektfortschritt zeigt sich in einem realen, lauffähigen Produktinkrement. Jeder kann das Product Backlog der noch zu erledigenden Dinge einsehen. Der Fortschritt ist klar sichtbar, sowohl übergeordnet, als auch Sprint für Sprint. Probleme und Bedenken werden offen diskutiert und sofort behandelt. Das ist entscheidend. Scrum funktioniert für Teams, die offen inspizieren (inspect), was vor sich geht und ihre Aktionen an die Realität anpassen (adapt). Scrum funktioniert schlecht für die, die das nicht tun. 1 Scrum eine Darstellung

5 Scrum-Werte Alle Arbeit, die in Scrum gemacht wird, braucht eine feste Basis von Werten, die als Grundlage für den Prozess und die Prinzipien des Teams dienen. Durch Teamwork und kontinuierliche Verbesserung bringt Scrum diese Werte hervor, und stützt sich auf sie. Diese Werte sind Fokus, Mut, Offenheit, Selbstverpflichtung und Respekt. Fokus. Weil wir uns nur auf wenige Dinge zu einem Zeitpunkt konzentrieren, arbeiten wir gut zusammen und erzeugen exzellente Arbeit. Wir liefern früher wertvolle Ergebnisse. Mut. Weil wir nicht allein sind, fühlen wir uns unterstützt und haben mehr Ressourcen zur Verfügung. Das gibt uns den Mut, größere Herausforderungen anzugehen. Offenheit. Bei unserer Zusammenarbeit üben wir uns darin auszudrücken, wie wir vorgehen, und was uns im Weg steht. Wir lernen, dass es gut ist, Bedenken auszusprechen, so dass sie adressiert werden können. Selbstverpflichtung. Weil wir viel Kontrolle über unser eigenes Schicksal haben, wächst unsere Selbstverpflichtung zum Erfolg. Respekt. Wenn wir zusammenarbeiten und Erfolge und Misserfolge teilen, kommen wir dazu, uns gegenseitig zu respektieren, und helfen einander, sich des Respekts würdig zu erweisen. Wenn eine Organisation Scrum seine Wirkung entfalten lässt, wird sie die Vorteile von Scrum entdecken und erkennen, warum diese Werte von Scrum gebraucht werden, und Scrum sie erzeugt. Scrum-Framework Scrum ist ein Framework, mit dem man ein Produkt erzeugt. Scrum beginnt, wenn einige Stakeholder ein Produkt benötigen. Scrum ist ein Team-Prozess. Das Scrum Team umfasst drei Rollen: den Product Owner, den ScrumMaster und die Mitglieder des Entwicklungs-Teams. Der Product Owner ist verantwortlich dafür zu entscheiden, welche Arbeit gemacht werden muss. Der ScrumMaster agiert als Servant Leader, indem er dem Team und der Organisation hilft, das Beste aus Scrum zu machen. Das Entwicklungs-Team erzeugt das Produkt inkrementell, in einer Reihe von kurzen Zeitabschnitten, die Sprints genannt werden. Ein Sprint ist ein fester Zeitabschnitt von einer bis zu vier Wochen, wobei kürzere Intervalle bevorzugt werden. In jedem Sprint erzeugt und liefert das Entwicklungs-Team ein Produktinkrement. Jedes Inkrement ist ein erkennbarer, sichtbar verbesserter und funktionierender Teil des Produkts, der vereinbarte Akzeptanzkriterien einhält, sowie einen Qualitätsmaßstab erfüllt, der Definition of Done genannt wird. Scrum enthält drei wesentliche Artefakte, das Product Backlog, das Sprint Backlog und das Produktinkrement. Das Product Backlog ist eine Liste von Ideen für das Produkt, in der Reihenfolge, in der wir ihre Umsetzung erwarten. Das Sprint Backlog ist der detaillierte Plan für die Entwicklung im nächsten, respektive im aktuellen Sprint. Das Produktinkrement ist das geforderte Ergebnis eines jeden Sprints. Es ist eine integrierte Version des Produktes, Scrum eine Darstellung 2

6 dessen Qualität gut genug ist für eine Auslieferung, wenn der Product Owner entscheidet, dass sie ausgeliefert werden soll. Zusätzlich zu diesen Artefakten verlangt Scrum Transparenz für das Team und die Stakeholder. Dazu stellt das Scrum-Team für alle sichtbar seine Pläne und seinen Fortschritt dar. Scrum beinhaltet fünf Aktivitäten oder Meetings. Diese sind: die Product Backlog Verfeinerung (Product Backlog Refinement), das Sprint Planning, das Daily Scrum, der Sprint Review und die Sprint Retrospective. Wir beschreiben im folgenden die Rollen, Artefakte und Aktivitäten, sowie den Fluss im Scrum-Zyklus. Scrum-Rollen Rolle: Product Owner Der Product Owner ist eine einzelne Person, die verantwortlich dafür ist, ein möglichst wertvolles Produkt zu einem gewünschten Datum zu erhalten. Um dies zu tun, organisiert er den Arbeitsfluss zum Team, wählt die Einträge aus dem Product Backlog aus und verfeinert sie. Der Product Owner führt das Product Backlog und stellt sicher, dass jeder weiß, was es enthält, und was die Prioritäten sind. Der Product Owner wird manchmal von anderen Personen unterstützt, die Rolle wird aber nur von einer Person besetzt. Natürlich ist der Product Owner nicht alleine verantwortlich für alles. Das ganze Scrum Team ist dafür verantwortlich, so produktiv wie möglich zu sein, seine Praktiken zu verbessern, die richtigen Fragen zu stellen, dem Product Owner zu helfen, usw. Das Entwicklungs-Team ist dafür verantwortlich zu bestimmen, wie viel Arbeit es in einem Sprint annehmen kann, und in jedem Sprint ein verwendbares Produktinkrement zu erzeugen. Dennoch ist der Product Owner in einer besonderen Situation. Der Product Owner ist typischerweise die Person, die am nächsten an der geschäftlichen Seite des Projektes ist. Der Product Owner wird typischerweise von der Organisation beauftragt, das Produkt herauszubringen, und er ist typischerweise derjenige, von dem man erwartet, dass er sein Bestes tut, um alle Stakeholder zufriedenzustellen. Der Product Owner tut das, indem er das Product Backlog führt, und sicherstellt, dass das Product Backlog und der Fortschritt in Bezug darauf sichtbar gemacht werden. Indem er mit dem Entwicklungs-Team auswählt, was als Nächstes getan und was auf später verschoben wird, trifft er die Entscheidungen über den Funktionsumfang gegenüber der Zeitplanung, die zum bestmöglichen Produkt führen. Rolle: Mitglied des Entwicklungs-Teams Das Entwicklungs-Team ist aus den Fachleuten zusammengesetzt, die an der Lieferung des Produktinkrementes arbeiten. Es organisiert sich selbst, um die Arbeit zu vollenden. Ein Mitglied des Entwicklungs-Teams soll für das Projekt komplett zur Verfügung stehen. 3 Scrum eine Darstellung

7 Scrum erfordert, dass das Entwicklungs-Team eine funktionsübergreifende Gruppe von Menschen ist, die zusammen alle erforderlichen Fähigkeiten besitzen, um jedes Produktinkrement liefern zu können. Die Mitglieder des Entwicklungs-Teams sind dafür verantwortlich, sich selbst zu organisieren, um das Sprint-Ziel zu erreichen, indem sie jedes neue Produktinkrement gemäß ihres Sprint-Plans erstellen. Der Product Owner erstellt eine geordnete Liste der gewünschten Arbeiten. Die Mitglieder des Entwicklungs-Teams prognostizieren, wie viel sie in einem Sprint erreichen können. Danach entscheiden sie, wie sie das bewerkstelligen wollen. Rolle: ScrumMaster Der ScrumMaster ist ein Servant Leader - also eine dienende Führungsperson. Er hilft dem Rest des Scrum-Teams dabei, dass es seinen Prozess verfolgt. Der ScrumMaster muss ein gutes Verständnis des Scrum-Frameworks mitbringen, sowie die Fähigkeit, andere in den Feinheiten von Scrum zu ertüchtigen. Der ScrumMaster arbeitet mit dem Product Owner zusammen, um ihm dabei zu helfen zu verstehen, wie er das Product Backlog erstellen und pflegen soll. Der ScrumMaster arbeitet mit dem Entwicklungs-Team zusammen, um die technischen Praktiken zu erkennen und einzusetzen, die es dem Team ermöglichen, am Ende jedes Sprints etwas Fertiges zu erstellen. Er arbeitet mit dem ganzen Scrum-Team zusammen, um die Definition of Done zu entwickeln. Ein weiterer Zuständigkeitsbereich des ScrumMasters ist, dafür zu sorgen, dass die Hindernisse beseitigt werden, die dem Fortschritt des Teams im Wege stehen. Diese Hindernisse können außerhalb des Teams liegen, wie zum Beispiel fehlende Unterstützung durch ein anderes Team. Die Hindernisse können auch innerhalb des Teams liegen, beispielsweise wenn der Product Owner nicht weiß, wie er das Product Backlog richtig vorbereiten soll. Der ScrumMaster fördert Selbstorganisation. Probleme sollten wann immer möglich vom Team gelöst werden. Der ScrumMaster fungiert als Coach für die Mitglieder des Scrum Teams. Er hilft ihnen dabei, den Scrum-Prozess zu leben. Er hilft ihnen dabei, zusammen zu arbeiten und das Scrum-Framework zu lernen. Er schirmt sie sowohl von internen als auch externen Ablenkungen ab. Er kann Meetings moderieren und hilft dem Team dabei, bei der Sache und produktiv zu bleiben und seine Fähigkeiten zu verbessern. Der ScrumMaster ist dafür verantwortlich sicherzustellen, dass Scrum verstanden und richtig eingesetzt wird, innerhalb des Teams und auch außerhalb. Er hilft den Menschen außerhalb des Teams dabei, den Prozess zu verstehen, und zu verstehen, welche Interaktionen mit dem Team hilfreich sind, und welche nicht. Der ScrumMaster hilft jedem dabei, sich zu verbessern, um das Scrum-Team produktiver und wertvoller zu machen. Scrum eine Darstellung 4

8 Artefakt: Product Backlog Das Product Backlog ist ein essentielles Artefakt in Scrum. Das Product Backlog ist eine geordnete Liste von Ideen für das Produkt - in der Reihenfolge, in der wir erwarten, dass die Ideen realisiert werden. Es ist die einzige Quelle, aus der alle Anforderungen fließen. Das bedeutet, dass alle Arbeiten des Entwicklungs-Teams aus dem Product Backlog kommen. Jede Feature-Idee, Verbesserung, Fehlerbehebung, Anforderung an Dokumentation jedes Stück Arbeit, das das Team erledigt wird aus einem Eintrag im Product Backlog abgeleitet. Jeder Eintrag im Product Backlog beinhaltet eine Beschreibung und eine Schätzung. Das Product Backlog kann anfangs eine lange oder kurze Liste sein. Es kann vage oder sehr detailliert sein. Typischerweise beginnt es kurz und vage, und wird länger und konkreter, wenn die Zeit fortschreitet. Product Backlog Einträge, die bald implementiert werden sollen, werden verfeinert : genauer erklärt, besser definiert, in mehrere Teile gesplittet im Rahmen der Aktivität der Product Backlog Verfeinerung. Der Product Owner ist dafür verantwortlich und Rechenschaft schuldig, dass das Product Backlog richtig geführt wird, auch wenn er bei der Erstellung und Aktualisierung Hilfe in Anspruch nehmen kann und soll. Product Backlog Einträge können vom Product Owner, von Teammitgliedern oder von anderen Stakeholdern kommen. Aktvität: Product Backlog Verfeinerung Da Product Backlog Einträge häufig ziemlich groß und generell sein können, und weil Ideen kommen und gehen können und sich Prioritäten verändern, ist die Verfeinerung des Product Backlogs eine dauerhafte Aktivität während eines Scrum-Projektes. Diese Aktivität umfasst, ist aber nicht nur beschränkt darauf, das Product Backlog geordnet zu halten, die Entfernung oder Herabstufung von Einträgen, die nicht länger wichtig sind, das Hinzufügen oder Heraufstufung von Einträgen, die neu dazu kommen oder wichtiger werden, das Aufteilen von Einträgen in kleinere Einträge, das Verschmelzen von Einträgen zu größeren Einträgen, die Schätzung von Einträgen. Ein Hauptvorteil der Product Backlog Verfeinerung ist die Vorbereitung auf den kommenden Sprint. Dazu lenkt diese Verfeinerungsarbeit besondere Aufmerksamkeit auf die Vorbereitung von Einträgen, die für die baldige Implementierung vorgesehen werden. Dabei gibt es viele Dinge zu beachten, insbesondere, aber nicht nur: Jeder Eintrag, der in einen Sprint aufgenommen wird, sollte idealerweise einen geschäftlichen Mehrwert widerspiegeln. Das Entwicklungs-Team muss dazu in der Lage sein, jeden Eintrag innerhalb eines einzigen Sprints zu erstellen. Jeder Beteiligte sollte Klarheit darüber haben, was mit dem Eintrag beabsichtigt ist. 5 Scrum eine Darstellung

9 Abhängig von der Art des Produktes können andere Fähigkeiten und Informationen notwendig sein. In jedem Fall sollte man die Product Backlog Verfeinerung am Besten als eine Aktivität für alle Teammitglieder ansehen, nicht nur für den Product Owner. Aktivität: Sprint Planning Jeder Sprint beginnt mit einem zeitlich begrenzten Meeting, das Sprint Planning genannt wird. In diesem Meeting arbeitet das Scrum Team gemeinsam daran, die zu erledigende Arbeit für den kommenden Sprint auszuwählen und zu verstehen. Das ganze Team nimmt am Sprint Planning Meeting teil. Ausgehend vom geordneten Product Backlog diskutieren der Product Owner und die Entwicklungs-Teammitglieder jeden Eintrag und kommen dabei zu einem gemeinsamen Verständnis des Eintrags und darüber, was notwendig ist, um ihn im Einklang mit der aktuellen Definition of Done umzusetzen. Alle Scrum-Meetings sind zeitlich begrenzt (engl.: time-boxed). Die empfohlene Zeit für das Sprint Planning Meeting beträgt eine Stunde pro Woche der Sprintdauer. Da das Meeting zeitlich begrenzt ist, hängt der Erfolg des Sprint Planning Meetings hochgradig von der Qualität des Product Backlogs ab, das zum Beginn des Meetings vorliegt. Aus diesem Grund ist die Verfeinerung des Product Backlogs eine so wichtige Aufgabe. In Scrum hat das Sprint Planning Meeting zwei Teile: 1 Ermitteln, welche Arbeit im Sprint erledigt werden wird; 2 Ermitteln, wie diese Arbeit erledigt werden soll. Teil Eins: Welche Arbeit wird erledigt? Im ersten Teil des Meetings präsentiert der Product Owner dem Entwicklung-Team der Reihe nach Product Backlog Einträge, und das ganze Scrum-Team arbeitet zusammen daran, die dahinterliegende Arbeit zu verstehen. Einzig das Entwicklungs-Team entscheidet, wie viele Product Backlog Einträge dabei in den Sprint aufgenommen werden. Um zu entscheiden, wie viele Einträge sie sich vornehmen wollen, zieht das Entwicklungs-Team den derzeitigen Zustand des Produktinkrements, die vergangene Leistung des Teams, die derzeitige Verfügbarkeit des Teams und das vorsortierte Product Backlog heran. Das Entwicklungs-Team alleine entscheidet, wie viel Arbeit es sich vornimmt. Weder der Product Owner noch irgendeine andere Kraft kann dem Entwicklungs-Team zusätzliche Arbeit aufhalsen. Meistens, aber nicht immer, bekommt der Sprint ein Ziel, das auch Sprint-Ziel genannt wird. Dies ist eine sehr machtvolle Praktik, die jedem dabei hilft, auf das zu fokussieren, was getan werden muss, und sich weniger mit kleinen Details aufzuhalten, die nicht so wichtig sind für das, was wir wirklich erreichen müssen. Scrum eine Darstellung 6

10 Teil Zwei: Wie werden wir die Arbeit erledigen? Im zweiten Teil des Meetings arbeitet das Entwicklungs-Team daran zu entscheiden, wie es das nächste Produktinkrement in Übereinstimmung mit der derzeitigen Definition of Done erstellen kann. Dafür designen und planen die Mitglieder in einem ausreichenden Maß, um zuversichtlich zu sein, die Arbeit während des Sprints erledigen zu können. Arbeit, die in den nächsten Tagen getan werden soll, wird in kleinere Einheiten von jeweils einem Tag oder weniger heruntergebrochen. Arbeit, die später im Sprint erledigt werden soll, kann in größeren Einheiten belassen und erst später heruntergebrochen werden. Die Entscheidung, wie die Arbeit getan werden soll, ist die Verantwortung des Entwicklungs- Teams, genau so wie die Entscheidung darüber, was getan werden soll, in die Verantwortung des Product Owners fällt. Der Product Owner kann an diesem Teil des Meetings teilnehmen, um offene Fragen zu beantworten und Missverständnisse aufzulösen. In jedem Fall sollten Product Owner kurzfristig verfügbar sein können. Das Ergebnis des Sprint Planning Das Sprint Planning endet damit, dass das Scrum-Team zu einem gemeinsamen Verständnis über die Menge und Komplexität dessen kommt, was während des Sprints geschafft werden soll. So kann es davon ausgehen, die Arbeit unter vernünftiger Weise anzunehmenden Umständen erledigen zu können. Das Entwicklungs-Team gibt eine Prognose über den Umfang der Arbeit ab, den es fertig stellen will, und die Mitglieder verpflichten sich gegenseitig dazu, dieses auch zu erreichen. Zur Zusammenfassung: Im Sprint Planning Meeting betrachtet und diskutiert das Entwicklungs-Team Product Backlog Einträge mit dem Product Owner, stellt das Entwicklungs-Team sicher, dass es diese verstanden hat, wählt das Entwicklungs-Team eine Anzahl an Einträgen aus, von denen die Teammitglieder vorausplanen, sie zu erledigen, erstellt das Entwicklungs-Team einen genügend detaillerten Plan, um sicherzustellen, dass es diese Einträge erledigen kann. Die sich daraus ergebende Liste an Dingen, die erledigt werden müssen, nennt man Sprint Backlog. Artefakt: Sprint Backlog Das Sprint Backlog ist die Liste der zur Entwicklung im aktuellen Sprint ausgewählten wohl definierten Product Backlog Einträge. Das Sprint Backlog enthält eine Vorhersage der im Sprint abzuschließenden Arbeit, sowie einen Durchführungsplan. Mit dem Sprint Backlog zur Hand beginnt der Sprint - und das Entwicklungsteam erstellt das neue im Sprint Backlog definierte Produktinkrement. 7 Scrum eine Darstellung

11 Entwicklung Während des Sprints organisiert sich das Entwicklungsteam selbst, um ein dem Sprint Backlog entsprechendes Produktinkrement zu erstellen, so wie es im Sprint Planning vereinbart wurde. Selbstorganisation heisst, dass das Team verantwortlich daran arbeitet, das Produktinkrement im Einklang mit allen organisatorischen Richtlinien gemäß der Definition of Done zu liefern - und das Entwicklungsteam bestimmt, wie es das anstellt. Artefakt: Produktinkrement Das wichtigste Artefakt in Scrum ist das Produktinkrement. Jeder Sprint bringt ein Produktinkrement hervor. Das Produktinkrement muss qualitativ so hochwertig sein, dass es den Benutzern ausgehändigt werden kann. Das Produktinkrement muss der aktuellen Definition of Done des Scrum-Teams entsprechen, und in jedem Bereich vom Product Owner abnehmbar sein. Zusätzliche Indikatoren des sichtbaren Fortschritts Scrum erfordert Transparenz innerhalb und außerhalb des Teams. Während das Produktinkrement die wesentliche Praktik zur Erzeugung von Transparenz darstellt, erarbeitet das Team alle weiteren Artefakte, die zur Verständigung über den Fortschritt des Projekts beitragen. Häufige zusätzliche Artefakte sind Burndown Charts und Taskboards. Vereinbarung: Definition of Done Wenn das Produktinkrement ausgeliefert wird, muss es "done" (fertig) sein - gemäß einer gemeinsamen Vereinbarung, was "done" bedeutet. Diese Definition ist bei jedem Scrum- Team anders. Mit dem Reifeprozeß des Teams wird die Definition of Done erweitert und geschärft. Die Definition of Done muss stets den Anspruch beinhalten, dass das Produktinkrement so hochwertig ist, dass es ausgeliefert werden könnte: Der Product Owner könnte sich dafür entscheiden, es umgehend auszuliefern. Das Produktinkrement enthält die Funktionalität aller früheren Produktinkremente und ist bestmöglich getestet, so dass alle abgeschlossenen Product Backlog Einträge weiterhin zusammen funktionieren. Aktivität: Daily Scrum Das Entwicklungsteam organisiert sich selbst. Das Entwicklungsteam nutzt das Daily Scrum Meeting, um sicherzustellen, dass es auf dem richtigen Weg zur Erreichung des Sprint-Ziels ist. Das Treffen findet täglich am gleichen Ort zur gleichen Uhrzeit statt. Jedes Mitglied des Entwicklungsteams gibt dabei drei Informationen bekannt Scrum eine Darstellung 8

12 Was habe ich seit dem letzten Daily Scrum erreicht? Was möchte ich bis zum nächsten Daily Scrum erreichen? Was bremst meinen Fortschritt? Auch wenn kurze, klärende Fragen und Antworten eingebracht werden können, gibt es keine weiterführende Diskussion dieser Themen während des Daily Scrums. Statt dessen treffen sich viele Teams direkt nach dem Daily Scrum, um an möglicherweise aufgekommenen Themen zu arbeiten. Das Daily Scrum ist weder ein Bericht an das Management noch an den Product Owner oder ScrumMaster. Es ist ein Kommunikations-Meeting innerhalb des Entwicklungsteams, das sicherstellt, dass alle über das Gleiche sprechen. Während dieses Meetings äußern sich nur die Scrum-Team-Mitglieder, einschliesslich des ScrumMasters und Product Owners. Andere Interessengruppen können sich dazu gesellen und zuhören. Auf der Basis dessen, was im Meeting besprochen wird, organisiert das Entwicklungsteam die Arbeit um, damit es das Sprintziel erreichen kann. Das Daily Scrum ist ein Schlüsselelement von Scrum, das zu Transparenz, Vertrauen und höherer Leistungsfähigkeit führt. Es bietet die schnelle Erkennung von Problemen, und fördert die Selbstorganisation und das Selbstvertrauen des Teams. Alle Scrum-Meetings sind zeitbegrenzt. Die empfohlene Time-Box für das Daily Scrum beträgt nicht mehr als 15 Minuten. Aktivität: Sprint Review Am Ende des Sprints untersuchen das Scrum-Team und Stakeholder das Ergebnis des Sprints. Alle Scrum-Meetings sind zeitbegrenzt. Die empfohlene Time-Box für das Sprint Review beträgt eine Stunde pro Woche der Sprintdauer. Der Kernpunkt der Diskussion ist das im Sprint erstellte Produktinkrement. Da die Stakeholder diejenigen sind, die einen Anteil an den Ergebnissen haben, ist ihre Teilnahme an diesem Meeting meistens weise und hilfreich. Das Meeting ist informell; man sieht sich den aktuellen Stand an und arbeitet zusammen am weiteren Vorgehen. Dazu kann jeder etwas beitragen. Natürlich trifft der Product Owner die endgültigen Entscheidungen über die Zukunft, indem er das Product Backlog entsprechend anpasst. Teams entwickeln ihre eigene Art, das Sprint Review durchzuführen. Typisch ist eine Vorführung des Produktinkrements. Die Teilnehmer diskutieren häufig darüber, was sie während des Sprints beobachtet haben, und welche Produkt-Ideen aufgekommen sind. Sie besprechen den Stand des Product Backlogs, mögliche Fertigstellungsdaten und die bis dahin lieferbaren Inhalte. Der Sprint Review gibt jedem Anwesenden einen Überblick über das aktuelle Produktinkrement. In dieser Hinsicht wird oft das Product Backlog innerhalb des Sprint Reviews aktualisiert. 9 Scrum eine Darstellung

13 Aktivität: Sprint Retrospective Am Ende jedes Sprints trifft sich das Scrum-Team zur Sprint Retrospective. Dessen Zweck ist die Begutachtung der vergangenen Ereignisse in Bezug auf den Prozess, die Beziehungen zwischen den Menschen und die eingesetzten Werkzeuge. Das Team identifiziert gute und nicht so gute Vorgehensweisen und Verbesserungsmöglichkeiten. Dann erarbeitet es einen Plan für die zukünftigen Verbesserungen. Alle Scrum-Meetings sind zeitbegrenzt. Die empfohlene Time-Box für eine Sprint Retrospective beträgt eine Stunde pro Woche der Sprintdauer. Das Scrum-Team verbessert seinen eigenen Prozess innerhalb des Frameworks von Scrum. Zurück zum Start Der Scrum-Zyklus wiederholt sich ab hier für jeden Sprint. Zusammenfassend lässt sich sagen, dass die Mitglieder des Scrum-Teams - der Product Owner, das Entwicklungsteam und der ScrumMaster - zusammen an der Erschaffung einer Serie von Produktinkrementen arbeiten; in kurzen als Sprint bezeichneten zeitbegrenzten Intervallen, in denen sie die Abnahmekriterien des Product Owners, sowie die vereinbarte Definition of Done des Teams erfüllen. Ihre Arbeit basiert auf einem Product Backlog. In jedem Sprint beginnen sie mit einem Sprint Planning, um das Sprint Backlog zu erstellen, einen Plan für den Sprint. Sie organisieren sich selbst, um die Entwicklung vorzunehmen, wobei sie Daily Scrum Meetings nutzen, um sich untereinander abzustimmen, und die Erstellung des bestmöglichen Produktinkrements sicherzustellen. Sie führen eine Verfeinerung des Product Backlogs durch, um sich auf das Sprint Planning Meeting des nächsten Sprints vorzubereiten. Sie beschließen den Sprint mit einem Sprint Review und einer Sprint Retrospective, in denen sie das Produkt und ihren Prozess begutachten und verbessern. Scrum eine Darstellung 10

14

15 Scrum besser machen! Eine inoffizielle Sammlung von Tipps und Einsichten für eine gute Scrum-Umsetzung Geschrieben von Certified Scrum Coach und Trainer Peter Hundermark Deutsche Übersetzung: Andreas Schliep, Henning Wolf, Peter Beck & Sebastian Lauber! ScrumSense Leaders in facilitating lasting Agile change scrumsense.com

16 Warum dieser Leitfaden? Der Certified Scrum Trainer und Coach Jim York sagt: Scrum ist einfach. Scrum machen ist schwer. Viele Menschen, denen ich in Unternehmen begegne, sagen, dass sie es schwer finden, sich über den Einstieg in Scrum zu informieren. Andere haben Teams, die zwar einigen agilen Praktiken folgen, aber weit davon entfernt sind das zu werden, was Jeff Sutherland hyper-produktiv nennt. Ich hoffe, dieses kleine Büchlein kann als Quelle der Inspiration dienen, um dir dabei zu helfen, Scrum und Agil besser einzusetzen. Wichtiger noch: Ich hoffe, dass es dich dazu ermutigt, dich selbst, dein Team und deine ganze Organisation von den alten Arbeitsweisen wegzubewegen, die einfach nicht funktionieren und neue Wege zu finden, die zu besserer Qualität, schnellerer Lieferung und vor allem mehr Spaß führen. Lass uns wissen, was du magst und was nicht, so dass wir es verbessern können. Und nun geh los und fang an!! Peter Hundermark Kapstadt, November 2009 Zweite Ausgabe! Mitwirkende an der deutschen Übersetzung: Peter Beck Sebastian Lauber Andreas Schliep Henning Wolf (2.1.1)! Copyright by Peter E Hundermark. This work is made available under the terms of the Creative Commons Attribution-ShareAlike 3.0 license 1 Scrum Besser Machen

17 Was ist Scrum? Woher kommt Scrum? Scrum ist ein Management-Rahmenwerk, innerhalb dessen komplexe Produkte entwickelt werden können. Scrum ist abgeleitet von der Arbeit im Wissensmanagement, komplexen adaptiven Systemen und der Theorie der Steuerung von empirischen Prozessen. Es beinhaltet Einflüsse von beobachteten Software- Entwicklungsmustern und der Theory of Constraints. Scrum und Agil Scrum ist das beliebteste der agilen Vorgehensmodelle. Es wird häufig in Verbindung mit Extreme Programming (XP) genutzt. Was ist das Problem? Auslieferungen und Produktivnahmen dauern zu lange Die Stabilisierung dauert zu lange Änderungen sind schwer einzubringen Die Qualität sinkt Todesmärsche lassen die Moral sinken Seit Jahrzehnten haben Softwareentwickler versucht, definierte Methoden der Arbeit und des Projektmanagements einzusetzen. Definierte Methoden sind angemessen, wenn die Voraussetzungen wohl definiert sind und die Art und Weise vorhersagbar ist, wie diese in Ergebnisse überführt werden. Softwareentwicklung und andere Arten der komplexen Arbeit sind nicht für solche Vorgehensweisen geeignet. Die hohe Rate an Projektfehlschlägen und unzufriedenen Kunden illustrieren das sehr deutlich. Wie hilft Scrum, das Problem zu lösen? Alistair Cockburn [Cockburn 2008] beschreibt Softwareentwicklung als ein kooperatives Spiel von Interaktion und Kommunikation. Traditionelle Entwicklungsmethodologien verlassen sich auf Dokumente, um Wissen festzuhalten und von einem Spezialisten zum anderen weiterzugeben. Die Rückkopplungs-Zyklen sind zu lang, oder existieren gar nicht. Jahrzehnte der Projekt- Unterperformance haben diese Arbeitsmethoden als absoluten Fehlschlag aufgezeigt. Scrum bietet den Menschen eine Plattform, effektiv zusammenzuarbeiten; und es macht unermüdlich auf jedes Problem aufmerksam, dass sich ihm in den Weg stellt. Scrum Besser Machen 2

18 Die Essenz von Scrum Das ist die Essenz von Scrum: Das Team erhält klare Ziele vorgegeben Das Team organisiert sich um die Arbeit selbst Das Team liefert regelmäßig wertvolle Funktionalitäten Das Team erhält Feedback von der Außenwelt Das Team reflektiert seine Arbeitsweisen, um sich zu verbessern Die gesamte Organisation hat Einblick auf den Fortschritt des Teams Team und Management kommunizieren ehrlich über Fortschritt und Risiken Diese Art der Arbeit basiert auf den Werten Selbstrespekt, Respekt gegenüber anderen, Vertrauen und Mut. Warum schweigt Scrum über Softwareentwicklungs- Praktiken? Scrum versucht nicht, Teams vorzuschreiben, wie sie ihre Arbeit zu machen haben. Scrum erwartet von Teams, dass sie tun, was auch immer erforderlich ist, um das gewünschte Produkt zu liefern. Es ermächtigt sie, genau das zu tun. Entwicklungspraktiken und Werkzeuge ändern und verbessern sich ständig und gute Teams werden permanent daran arbeiten, sie zu ihrem Vorteil zu nutzen. Anwendbarkeit Während Scrum zuerst bei der Entwicklung von Software-Produkten eingesetzt wurde, passt es doch zu allen Formen der komplexen Arbeit. Es wird heutzutage genutzt, um Software- und Hardwareentwicklungen, Support, Werbung und Marketing, Kirchen und ganze Unternehmen zu managen. Wie lässt sich Scrum auf herkömmliche Methoden abbilden? Die kurze Antwort ist, dass es sich nicht auf herkömmliche Methoden abbilden lässt. Agilität und Scrum basieren auf einem anderen Paradigma. Die Begründer Jeff Sutherland und Ken Schwaber haben häufig bemerkt, dass Versuche, definierte Methoden auf empirische Methoden abzubilden, zum Scheitern verurteilt sind. Wird Scrum in meinem Unternehmen gelingen? Das hängt von dir ab! Die Implementierung in deinem Unternehmen kann fehlschlagen, weil die Mitarbeiter nicht resolut genug versuchen, die Probleme zu überwinden, die Scrum mit Sicherheit aufdecken wird. Und doch haben Tausende Teams auf allen Kontinenten und in jedem Wirtschaftsbereich Erfolg dabei, ihre Arbeitswelt heute besser als die von gestern zu machen. 3 Scrum Besser Machen

19 Das Agile Manifest Im Februar 2001 trafen sich siebzehn unabhängige leichtgewichtige Software- Methodologen, um miteinander zu reden und eine gemeinsame Basis zu finden. Unter ihnen befanden sich die Scrum Begründer Jeff Sutherland und Ken Schwaber, zusammen mit Mike Beedle, der an den initialen Scrum Patterns gearbeitet und das erste Buch über Scrum mitgeschrieben hatte. Die Gruppe nannte sich selbst die Agile Alliance und einigte sich auf ein Manifest für die Agile Softwareentwicklung. Des Weiteren definierten sie eine Reihe von zwölf Prinzipien hinter dem Manifest, die in voller Länge auf der nächsten Seite wiedergegeben sind. Kommentar Das Agile Manifest und seine zwölf Prinzipien bestehen aktuell seit nahezu einem Jahrzehnt. Sie bleiben der Lackmustest für alle agilen Methoden und Praktiker, nach dem sie ihre Arbeitsweise beurteilen können. Die am meisten geäußerte Kritik daran war die Betonung auf Softwareentwicklung, während agile Methoden wesentlich weitläufiger angewendet werden können. Scrum ist eine Spielart der Agilität. Die Übereinstimmung mit dem Agilen Manifest und allen darin enthaltenen Prinzipien bedeutet nicht unbedingt, dass ein Team oder eine Organisation Scrum befolgt. Jedoch bedeutet eine fehlende Übereinstimmung mit IRGENDEINEM dieser Prinzipien, dass du NICHT Scrum machst oder Agile! Manifest für die Agile Softwareentwicklung Wir entdecken bessere Wege, Software zu entwickeln, indem wir es tun und anderen dabei helfen, es zu tun. Durch diese Arbeit schätzen wir: Individuen und Interaktionen höher als Prozesse und Werkzeuge Funktionierende Software höher als vollständige Dokumentation Zusammenarbeit mit Kunden höher als Vertragsverhandlungen Auf Änderungen zu reagieren höher als einem Plan zu folgen Das heißt, während wir den Wert der Dinge auf der rechten Seite sehen, schätzen wir die Dinge auf der linken Seite als wichtiger ein.! Scrum Besser Machen 4

20 Prinzipien hinter dem Agilen Manifest 1. Unsere höchste Zielsetzung ist es, den Kunden durch die frühe und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen. 2. Begrüße Anforderungsänderungen, auch spät in der Entwicklung. Agile Prozesse nutzen den Wandel für den Wettbewerbsvorteil des Kunden. 3. Liefere häufig funktionierende Software, alle paar Wochen oder Monate, eher in kürzeren Zeiträumen. 4. Geschäftsleute und Entwickler müssen täglich im Projekt zusammen arbeiten. 5. Baue Projekte um motivierte Individuen. Gib ihnen die Umgebung und Unterstützung, die sie brauchen, und traue ihnen zu, den Job zu erledigen. 6. Die effizienteste und effektivste Art der Informationsweitergabe an und in einem Entwicklungsteam ist die Konversation von Angesicht zu Angesicht. 7. Funktionierende Software ist das primäre Maß für Fortschritt 8. Agile Prozesse fördern nachhaltige Entwicklung. Die Sponsoren, Entwickler und Benutzer sollten ein gleichbleibendes Tempo ohne Unterbrechung einhalten können. 9. Die fortwährende Beachtung von technischer Exzellenz und gutem Design verbessert die Agilität. 10. Einfachheit die Kunst der Maximierung von nicht angegangener Arbeit ist essentiell. 11. Die besten Architekturen, Anforderungen und Designs entstehen in sich selbst organisierenden Teams. 12. In regelmässigen Intervallen reflektiert das Team darüber, wie es effektiver werden kann, und passt dann sein Verhalten entsprechend an.! Highsmith (2001) 5 Scrum Besser Machen