17Ereignisse

Wie im vorhergehenden Kapitel werden Sie im Folgenden nur einige Hinweise darauf er-halten, was Sie besonders im Auge behalten sollten, wenn Sie sich mit den Ereignissen inScrum beschäftigen. Eine tiefe Einführung in die „Scrum Events“ werden Sie nicht erhal-ten.

17.1 Der Sprint selbst

Der Sprint ist eine Iteration von bis zu 30 Kalendertagen. Ziel ist, am Ende jeder Iterati-on ein fertiges Produktinkrement auszuliefern und damit potentiell sofort einen Returnon Invest zu generieren. Am Ende jedes Sprints finden ein Sprint Review und eine SprintRetrospektive statt – mehr dazu später. Die Länge der Sprints können Sie nach den Bedürf-nissen Ihres Unternehmens anpassen. Ein paar Dinge sollten Sie dabei aber beachten:

1. Nur wenn die Sprintlänge über viele Sprints stabil bleibt, haben Sie eine aussagekräf-tige Velocity, also eine Kennzahl über die Produktivität Ihres Teams und damit einePlanungsgrundlage für Ihre Lieferprognose. Egal für welche Sprintlänge Sie sich ent-scheiden: Bleiben Sie dabei, falls nicht gewichtige Gründe dagegen sprechen.

2. Scrum schreibt zwar keine Mindestlänge von Sprints vor, in der Praxis zeigt sich aber,dass Sprints minimal eine Woche lang sein sollten. Es gibt zwar Teams, die behaup-ten „Tagessprints“ durchzuführen, dies verdeckt aber in der Regel ein grundlegendesPlanungsproblem. In einem normalen Team weiß der Product Owner mindestens eineWoche im Voraus, was er bekommenmöchte und das Entwicklungsteam kann denWegzu diesem Ziel durchplanen.

3. Wenn Scrum neu in Unternehmen eingeführt wird, gibt es oft Druck aus dem Ent-wicklungsteam oder vomManagement, die Sprintdauer zu verlängern, da „man in vierWochen nichts fertig bekommen kann“. Geben Sie diesem Druck auf keinen Fall nach!Mir ist kein einziger Fall bekannt, in demdie obigeBehauptung auf einer solidenGrund-

181D. Maximini, Scrum - Einführung in der Unternehmenspraxis,DOI 10.1007/978-3-642-34823-5_17,© Springer-Verlag Berlin Heidelberg 2013

182 17 Ereignisse

lage beruhte. Stellen Sie denBeteiligten stattdessen die folgende Frage: „Wannwerden Sieheute Abend zu Hause sein?“. Sie werden sofort Antworten bekommen. Zum Beispiel:„Gegen sechs“. Bohren Sie dann nach: „Nicht gegen sechs. Wann genau? Auf die Minu-te bitte!“ Möglicherweise bekommen Sie sogar eine Antwort. Dann fragen Sie: „Wanngenau werden Sie Mittwoch in vier Wochen zu Hause sein?“Ziel der Übung ist es zu zeigen, dass wir schon einfache Zusammenhänge nicht exaktplanen können.Wie sollen wir dann etwas soKomplexes wie Softwareerstellung planen,das auch nochweit in der Zukunft liegt? Stellen Sie dann die Kernfrage: „Wasmüssenwirtun, damit wir gemeinsam in der Lage sind, innerhalb eines Sprints ein fertiges Produktzu liefern?“Sie werden zahlreiche Vorschläge von Ihrem Team erhalten, die Sie gemeinsam verfei-nern sollten. Am Ende wissen Sie, was nötig ist (zumindest für den Anfang, die Anfor-derungen werden sich mit der Zeit weiterentwickeln).

4. Die Erfahrung zeigt, dass einwöchige Sprints sehr anstrengend und vierwöchige Sprintsoft zu lang sind, um sie noch sinnvoll durchplanen zu können. In der Regel sind zwei-oder dreiwöchige Sprints sehr gut geeignet. Meine Empfehlung für Sie: Beginnen Siemit zweiwöchigen Sprints. Gibt es schwerwiegende Probleme, gehen Sie auf eineWoche– das gibt Ihnen mehr Gelegenheiten, die Ursachen der Probleme zu analysieren undMaßnahmen zu ergreifen. Ist das Team eingespielt und möchte von sich aus längereSprints, gehen Sie auf drei- oder sogar vierwöchige Sprints.

17.2 Sprint Planning

Das Sprint Planning besteht aus zwei Teilen. Im ersten Teil stellt der Product Owner demEntwicklungsteam vor, was er am Sprintende bekommen möchte und das Entwicklungs-team gibt eine Vorhersage darüber ab, was es glaubt zu schaffen. Im zweiten Teil plant dasEntwicklungsteam so genau wie möglich, wie es das Sprintziel erreichen möchte. AchtenSie hier auf zwei Dinge. Erstens darf außer dem Scrum-Team zu Beginn der Scrumeinfüh-rung niemand an der Besprechung teilnehmen. Einzige Ausnahme bilden Experten, derenWissen für die Planung gebrauchtwird. Insbesondere dasManagement darf aber auf keinenFall teilnehmen, da allein die Anwesenheit der Führungskräfte das Team in seinem Den-ken einschränkt. Auch können sich Manager oft nicht zurückhalten und versuchen durchgut gemeinte Ratschläge zu helfen. Diese werden von jungen Teams aber oft als Vorgabeinterpretiert und andere – vielleicht bessere – Lösungswege werden nicht mehr betrachtet.Das ändert sich mit der Zeit, wenn das Team genug Selbstbewusstsein hat, um solche Ein-wände zu ignorieren. Meist hat dasManagement dann aber gar kein Interesse mehr, an derBesprechung teilzunehmen.

Zweitens müssen Sie auf die Teamdynamik achten. Es gibt immer sehr dominanten Per-sönlichkeiten, die auch die Lösungsdiskussionen beherrschen. Das ist natürlich und nichtschlimm. Problematisch wird das immer dann, wenn das Entwicklungsteam in Dogmatis-mus verfällt: Was Person x sagt, muss genau so gemacht werden, eben weil es von genau

17.3 Sprint Review 183

dieser Person kommt. Dieser blinde Gehorsam ist kontraproduktiv. Sorgen Sie dafür, dassalle Teammitglieder sich beteiligen. Wenn nötig, erteilen Sie dem Alphatier ein Sprech-verbot bis zum Ende der Diskussion (erklären Sie ihm aber unter vier Augen warum). ImExtremfall kann es sogar nötig sein, dass Sie Ihr bestes Pferd imStall zeitweise in ein anderesProjekt verschieben, damit die übrigen Pferde anfangen zu laufen. Langfristig gewinnen Sieso mehr, als würde die dominante Person wie bisher das Projekt quasi „alleine“ stemmen.An dieser Stelle sind Sie auf einen guten Scrum Master angewiesen, der diese teamdyna-mischen Prozesse versteht und sie steuern kann.

17.3 Sprint Review

Das Sprint Review dient dazu, am Sprintende gemeinsam mit den Stakeholdern das wäh-rend des Sprints entstandeneProdukt zu inspizieren undÄnderungsbedarf festzustellen. Esist keine Demo. Es ist ein Planungsmeeting. Sorgen Sie dafür, dassmindestens die internen(wenn es „läuft“ auch die externen) Stakeholder anwesend sind. Lassen Sie die Stakeholderdas Produkt selbst ausprobieren. Geben Sie Hilfestellung, aber führen Sie es nicht in Formeiner Präsentation vor. Schreiben Sie alle Kommentare der Stakeholder auf, denn darauskönnen Sie ablesen, wo das Produkt noch Änderungsbedarf hat. Ist die Bedienung viel-leicht nicht intuitiv? Fehlt eine wichtige Funktion? Macht eine Funktion nicht das, was derAnwender erwartet hat? Da der Product Owner normalerweise auf täglicher Basis mit sei-nem Team zusammenarbeitet, wird er das Produkt bereits kennen. Sieht er es beim Reviewzum ersten Mal, so ist er ein schlechter Product Owner. Das Sprint Review ist die Haupt-möglichkeit für den ProductOwner, echtes zeitnahes Feedback von seinen Stakeholdern zubekommen. Führen Sie das Review auch dann durch, wenn das Team nichts zu zeigen hat.Solche Situationen sind in höchstemMaße unangenehm für alle Beteiligten und führen inder folgenden Retrospektive dazu, dass das Team ausreichend motiviert ist, sich ernsthafteGedanken über Verbesserungsmöglichkeiten zu machen. Schonen Sie das Team maximalim allerersten Sprint.

17.4 Sprint Retrospektive

Die Sprint Retrospektive ist normalerweise der offizielle Abschluss eines Sprints, währenddas Sprint Planning den Beginn eines neuen Sprints markiert. In der Retrospektive wirdder vergangene Sprint aus Prozesssicht betrachtet und Maßnahmen zur Verbesserung derZusammenarbeit erarbeitet. Es gibt unzählige Arten, Retrospektiven durchzuführen (vgl.z. B. Derby und Larsen 2006). Wichtig ist, dass am Ende konkrete Maßnahmen heraus-kommen, die das Team selbst umsetzen kann undwill. Wenige sehr greifbare Maßnahmensind dabei einer hohen Anzahl schwammiger Ideen vorzuziehen. Hier müssen Sie nur aufdrei Dinge achten: Erstens, dass die Retrospektive jeden Sprint stattfindet. Zweitens, dasssie von einem fähigen Scrum Master geleitet wird. Drittens, dass konkrete Maßnahmen

184 17 Ereignisse

beschlossen werden. Es hilft, dem Team den Hinweis an die Hand zu geben, dassMaßnah-menmindestens dem Schema „Wer tut was bis wann?“ genügen müssen, wobei das „wann“normalerweise fest als „bis zur nächsten Retrospektive“ definiert ist.

17.5 Daily Scrum

Das Daily Scrum ist kein Statusmeeting, sondern ein Planungsmeeting. Täglich plant dasEntwicklungsteam eigenständig (ggf. unterstützt durch den ScrumMaster), wie es auf Basisdes bisher Erreichten das Sprintziel noch erreichen wird. Der Status jedes Einzelnen ist da-bei nur Mittel zum Zweck, um den aktuellen Standort des Teams zu bestimmen und davonausgehend präzise planen zu können. Im Daily Scrum können Sie sehr einfach feststellen,wie selbstorganisiert undmotiviert Ihr Teamarbeitet. Für Sie als ChangeManager sind aberandere Dinge wichtig. Achten Sie darauf, dass keine Gäste amDaily Scrum teilnehmen, au-ßer das Teambittet aktiv darum.Manager sind in diesemMeeting grundsätzlich immer fehlam Platze, da die Diskussionen sich normalerweise auf einem hohen technischen Niveaubewegen, dem man als Nicht-Entwickler nicht folgen kann. Diese Höhe überfordert häu-fig auch den Product Owner, weshalb es nicht erforderlich ist, dass dieser am Daily Scrumteilnimmt. Es hilft aber, wenn er unmittelbar nach dem Daily Scrum für Fragen zur Ver-fügung steht. Achten Sie auch darauf, dass diese tägliche Besprechung sich nicht unnötigin die Länge zieht. Meistens entstehen Verzögerungen dadurch, dass zwei Einzelpersoneneinen Klärungsbedarf haben und der Rest des Teams mehr oder weniger gelangweilt zu-hört. Der ScrumMaster sollte diese Zwiegespräche aus demDaily Scrum verlagern. SorgenSie außerdem dafür, dass das Daily Scrum auch wirklich täglich stattfindet. Es handelt sichauch um ein Instrument der Risikominimierung: Wenn Sie diese nur einmal die Wochedurchführen, werden Sie ggf. erst nach einer vollenWoche (also nach ca. 25.000 € Entwick-lungskosten bei einem durchschnittlichen Team) feststellen, dass Ihr Team in eine falscheRichtung läuft.

Literatur

Derby E, Larsen D (2006) The Pragmatic Programmers. Frisco