Scrum – auf einer Seite erklärt

Scrum kennt drei Rollen für direkt am Prozeß Beteiligte: Product Owner (stellt fachliche Anforderungen und priorisiert sie), ScrumMaster (managt den Prozeß und beseitigt Hindernisse) und Team (entwickelt das Produkt). Daneben gibt es als Beobachter und Ratgeber noch die Stakeholders.

Die Anforderungen (Requirements) werden in einer Liste (Product Backlog) gepflegt, erweitert und priorisiert. Das Product Backlog ist ständig im Fluß. Um ein sinnvolles Arbeiten zu ermöglichen, wird monatlich vom Team in Kooperation mit dem Product Owner ein definiertes Arbeitspaket dem oberen, höher priorisierten Ende des Product Backlogs entnommen und komplett in Funktionalität umgesetzt (inkl. Test und notwendiger Dokumentation). Dieses Arbeitspaket, das Increment, wird während der laufenden Iteration, des sog. Sprints, nicht durch Zusatzanforderungen modifiziert, um seine Fertigstellung nicht zu gefährden. Alle anderen Teile des Product Backlogs können vom Product Owner in Vorbereitung für den nachfolgenden Sprint verändert bzw. neu priorisiert werden.

Das Arbeitspaket wird in kleinere Arbeitspakete (Tasks) heruntergebrochen und mit jeweils zuständigem Bearbeiter und täglich aktualisiertem Restaufwand in einer weiteren Liste, dem Sprint Backlog, festgehalten.  Während des Sprints arbeitet das Team konzentriert und ohne Störungen von außen daran, die Tasks aus dem Sprint Backlog in ein Increment of Potentially Shippable Functionality, also einen vollständig fertigen und potentiell produktiv einsetzbaren Anwendungsteil, umzusetzen. Das Team gleicht sich in einem täglichen, streng auf 15 Minuten begrenzten Informations-Meeting, dem Daily Scrum Meeting, ab, damit jeder weiß, woran der andere zuletzt gearbeitet hat, was er als nächstes vor hat und welche Probleme es evtl. gibt.

Am Ende des Sprints präsentiert das Team dem Product Owner, den Stakeholders u.a. interessierten Teilnehmern in einem sog. Sprint Review Meeting live am System die implementierte Funktionalität. Halbfertiges oder gar Powerpoint-Folien sind während des Reviews verboten. Das Feedback der Zuseher und die neuen Anforderungen des Product Owners für den kommenden Sprint fließen dann wieder in das nächste Sprint Planning Meeting ein, und der Prozeß beginnt von neuem.

Der ScrumMaster sorgt während des gesamten Prozesses dafür, daß Regeln eingehalten werden und der Status aller Tasks im Sprint Backlog von den jeweils zuständigen Team-Mitgliedern täglich aktualisiert wird. Er macht den Projektfortschritt transparent durch einen geeigneten Reporting-Mechanismus: die Veröffentlichung sog. Burndown Charts, welche den Fortschritt für den aktuellen Sprint bzw. für das gesamte Projekt jeweils in Form einer Kurve visualisieren. Eingezeichnete Trendlinien erlauben es, mögliche Probleme und Verzögerungen einfach (und rechtzeitig!) zu erkennen.

Im Kern basiert Scrum also auf einer inkrementellen Vorgehensweise, der Organisation von Entwicklungsabschnitten und Meetings in vordefinierten Zeitabschnitten (Time-Boxes) und der Erkenntnis, daß ein funktionierendes Produkt wichtiger ist als eine dreihundertseitige Spezifikation.

Time-Boxing

Eine Time-Box ist ein Zeitabschnitt, der nicht überschritten werden darf und in dessen Grenzen Meetings oder Entwicklungs-Inkremente ablaufen. Die Time-Box ist eines der grundlegenden Konzepte in Scrum und trägt maßgeblich zur Effizienz des Prozesses bei.

Time-Boxing ist auch aus anderen agilen Methoden (z.B. Extreme Programming) bekannt und hat sich in der Praxis bewährt. Ist Ihnen jemals aufgefallen, wie effektiv Sie plötzlich arbeiten, wenn etwas zu einem gegebenen (relativ nahen) Zeitpunkt fertig sein muß? Sie trödeln nicht herum, konzentrieren sich aufs Wesentliche, fokussieren sich auf Ihr Ziel. Mit Time-Boxing kann man diese Fokussierung bewußt herbeiführen.

Das Konzept der Time-Box sollte von allen Beteiligten ernst genommen und nicht aufgeweicht werden. Dafür sorgt der ScrumMaster als Überwacher des Prozesses.

Vorteile des Time-Boxing

• Meetings konzentrieren sich aufs Wesentliche, beginnen und enden pünktlich. Nicht jeder erzählt jedem alles, sondern es werden Informationen ausgetauscht, die für alle Beteiligten von Bedeutung sind. Ein gutes Scrum-Meeting erzeugt zusätzlichen anschließenden Gesprächsbedarf im kleineren Kreis, anstatt alle zu ermüden mit für den Einzelnen uninteressanten Informationen.
• In der Software-Entwicklung erhöhen zeitlich klar definierte und abgegrenzte, nicht zu lange Intervalle (z.B. Sprint-Länge 30 Tage) die Planungssicherheit, weil Voraussagen und Schätzungen für überschaubare Zeitabschnitte mit höherer Genauigkeit möglich sind als für ein komplettes Projekt oder Release. Und wer hat schon etwas von geradezu obszön von der Planung abweichenden Projekten? Was sind solche Planzahlen wert? Erstaunlich, daß viele Projekte trotzdem so gehandhabt werden.

Nachteile des Time-Boxing

Aus Projektsicht hat Time-Boxing keine wesentlichen Nachteile, sonst würde Scrum es nicht propagieren. Time-Boxing stellt aber einige Anforderungen an Gruppen und Individuen, deren Erfüllung sich auszahlt, die aber nicht jeder ohne Training oder Umgewöhnung erfüllen kann:

• Eine gewisse Disziplin in Meetings ist unabdingbar.
• Wer sich selbst gern reden hört – der Autor dieser Zeilen gehört dazu – muß sich manchmal zurücknehmen.
• In der Lernphase kommen, besonders in Daily Scrums, manchmal nicht alle zu Wort, weil das Meeting vom ScrumMaster beendet wird, bevor alle Team Members ihren Bericht abgeliefert haben. Das reguliert sich jedoch sehr schnell selbst, weil das Team merkt, daß es unter dem Informationsdefizit leidet.
• Die bequeme Möglichkeit, eine Iteration in der Entwicklung zu verlängern, weil man nicht fertig wird, steht nicht mehr zur Verfügung, weil die Sprint-Länge von niemandem – auch nicht vom ScrumMaster – während der laufenden Iteration angepaßt werden darf. Der Vertrag zwischen Product Owner und Team ist von beiden Seiten einzuhalten – einziger Ausweg ist die unrühmliche Sprint Cancellation.

Sprint

Scrum-Projekte werden inkrementell entwickelt. Jedes Inkrement ist eine Time-Box von normalerweise 30 Kalendertagen und heißt Sprint. Innerhalb jedes Sprints entwickelt das Team ein Increment of Potentially Shippable Functionality, welches anschließend der Auftraggeberseite vorgestellt wird. Der Product Owner entscheidet dann über einen Produktiveinsatz des Inkrements.

Merkmale eines Sprints

• Time-Box für die Implementation eines Increment of Potentially Shippable Functionality durch das Scrum-Team
• Klassische Länge: 30 Kalendertage
• Beginnt mit dem Sprint Planning Meeting
• Endet mit dem Sprint Review Meeting und anschließendem Sprint Retrospective Meeting
• Während des Sprints wird das Team nicht durch neue oder geänderte Anforderungen unterbrochen. Damit erreicht man Kontinuität und konzentriertes Arbeiten auf das vom Product Owner ausgegebene Sprint Goal hin.
• Nicht-Team-Mitglieder (insbesondere der Product Owner u.a. Stakeholders) stehen während des Sprints für Rückfragen zur Verfügung.
• Sonderformen von Sprints: Stabilisation Sprint und Release Sprint
• In sehr seltenen(!) Ausnahmefällen kommt es zur vorzeitigen Sprint Cancellation durch den ScrumMaster.

Wahl der richtigen Sprint-Länge

Hierbei handelt es sich um ein besonderes Thema, welches demnächst innerhalb eines Fachartikels in der Scrum-Kolumne behandelt werden wird. Nur so viel vorab: In der Scrum-Szene setzen sich immer häufiger kürzere Sprint-Längen von bspw. 14 Tagen oder sogar einer Woche durch. Gerade in der Anfangsphase eines Projekts bieten sich dadurch mehr Lernmöglichkeiten für unerfahrene Scrum-Teams durch mehr Sprint-Zyklen innerhalb einer bestimmten Zeitspanne. Allerdings erfordern kurze Sprints auch besondere Disziplin und einen erfahrenen ScrumMaster.

Sprint Planning Meeting

Zu Beginn jedes Sprints findet als Kick-Off das Sprint Planning Meeting statt. Es dauert einen Tag (Time-Box 8 Std.) und dient dazu, das Arbeitspaket des Scrum-Teams für den kommenden Sprint (Sprint Backlog) zu schnüren.

Ablauf des Sprint Planning Meeting 

• Time-boxed (8 h)
• Input: Product Backlog
• Output: Sprint Backlog
• Aufgeteilt in zwei weitere Time-Boxes von jeweils 4 h:
• Der Product Owner präsentiert dem Team die Product Backlog Items mit der höchsten Priorität und benennt (optional) sein Sprint Goal, mit dem das Team einverstanden sein muß. Gemeinsam bestimmen beide Seiten, welchen Teil des Product Backlogs das Team im kommenden Sprint in ein Increment of Potentially Shippable Functionality verwandeln kann. Das Team verpflichtet sich (engl. „to commit“) auf den besprochenen Lieferumfang, welchen es soeben selbst mitbestimmt hat.
• Das Team plant autonom (ohne Mitsprache des Product Owners) im Detail, wie es sein gegebenes Versprechen einlösen kann, indem es die betreffenden Requirements in Tasks herunterbricht und letztere zu einem Sprint Backlog konsolidiert.

Hinweise

• Der Product Owner stellt zwar die Anforderungen, aber das Scrum-Team alleine entscheidet, wieviel von der gewünschten Funktionalität es im kommenden Sprint tatsächlich realistisch schaffen kann. Das Team kann bei differierenden Ansichten von niemandem “überstimmt” werden.
• Jedes Team wird, wenn es auch nur im geringsten Wert auf sein Ansehen legt, versuchen, so viel wie möglich in einem Sprint zu schaffen. Meistens muß bei unerfahrenen Teams sogar der ScrumMaster das Team etwas bremsen, damit es sich nicht übernimmt. Darunter würde dann die Qualität leiden, und das Produkt-Inkrement würde seinem Anspruch, “Sashimi” bzw. potentially shippable zu sein, nicht gerecht werden.

Daily Scrum Meeting

Wie der Name andeutet, findet das Daily Scrum Meeting an jedem Arbeitstag statt. Es dauert nicht länger als 15 Minuten (Time-Box) und dient dem Team dazu, sich abzustimmen und gegenseitig zu informieren.

Ablauf des Daily Scrum Meeting (kurz: Daily Scrum)

• Kurzes, tägliches Status-Meeting des Teams
• §Time-boxed (15 min)
• Stand-Up-Meeting, d.h. die aktiven Teilnehmer stehen (am besten im Kreis), sie sitzen nicht
• §ScrumMaster nimmt teil, notiert sich genannte Impediments (s.u.) auf seiner Blocks List und greift moderierend(!) ein, wenn unbedingt nötig
• §Product Owner nimmt nach Möglichkeit auch teil, um auf dem neuesten Stand zu bleiben und bei Bedarf fragen zu beantworten
• §Nur die Team Members sprechen und berichten einander jeweils Folgendes:
  §    –  Was habe ich seit dem letzten Daily Scrum getan?
  §    –  Was plane ich, bis zum nächsten Daily Scrum zu tun?
  §    –  Was hat mich bei der Arbeit behindert (Impediments)?

Hinweise

• Ein fruchtbares Daily Scrum erzeugt durch seine Kürze bewußt weiteren Gesprächs- und Informationsbedarf, der in anschließenden Einzelgesprächen gedeckt werden kann – ein positiver Nebeneffekt der Time-Box.
• Es ist wichtig, daß die Team Members einander berichten und nicht ihren evtl. anwesenden Vorgesetzten oder dem ScrumMaster oder dem Product Owner. Sie schauen einander an, alle anderen Anwesenden sind nur Zuhörer. Das Command-and-Control-Muster zu durchbrechen, erfordert ein wenig Übung. Die Umstellung dauert eine Weile für neue Scrum-Teams. Innerhalb kurzer Zeit sind Daily Scrums jedoch hocheffiziente und zielgerichtete Veranstaltungen.
• Daß jedes Team Member weiß, woran die anderen arbeiten, ist wichtig, damit nicht jeder in seinem Elfenbeinturm bleibt, sondern ein Gesamtbild des Projekts erhält. Wer ein Problem hat, dem kann vielleicht ein anderer helfen.
• Dieser Hinweis gilt für alle Scrum-Meetings: Es wird pünktlich begonnen, nicht fünf Minuten später. Wer zu spät kommt, hat Pech gehabt und wird, falls das Team es so festgelegt hat, entsprechend einer team-internen Regelung sanktioniert, z.B. zwei Euro in eine Kasse zahlen, aus der am Ende des Projekts für einen wohltätigen Zweck gespendet wird. Das Geld hinterher als “Belohnung” fürs Zuspätkommen gemeinsam zu “verfressen”, wäre kein gutes Signal.

Sprint Review Meeting

Am Ende jedes Sprints präsentiert das Team dem Product Owner und allen interessierten Stakeholders das Ergebnis seiner Arbeit live am System und sammelt Feedback (Meinungen, Verbesserungsvorschläge, Lob und Kritik) ein.

Ablauf des Sprint Review Meeting

• Time-boxed (4 h)
• Maximal eine Stunde Vorbereitungszeit pro Person
• Das Team selbst – nicht irgendein übergeordneter Manager – zeigt dem Product Owner und anderen interessierten Personen live am funktionierenden System, was es innerhalb des Sprints erreicht hat.
• Wichtig: keine Dummies, kein Powerpoint! Nur fertige Produktfunktionalität (Increment of Potentially Shippable Functionality) darf vorgeführt werden.
• Feedback seitens Product Owner, Stakeholders u.a. Anwesenden ist erwünscht und fließt in die weitere Arbeit ein.
• Auf Basis des Gezeigten entscheidet später der Product Owner, ob das Inkrement produktiv gesetzt oder weiter entwickelt werden soll. Diese Möglichkeit hat er nach jedem Sprint. So ist gewährleistet, daß in sich abgeschlossene funktionale Bausteine eines Gesamtsystems möglichst früh einen Nutzen und somit einen Return on Investment – Manager lieben das, und zu Recht – erzeugen.

Hinweise

• Ort der Veranstaltung kann durchaus ein Entwicklerbüro sein. Team Members sollen vom Fachbereich als Menschen, nicht als Ressourcen wahrgenommen werden. Dazu gehört auch, Menschen in ihrer Umgebung zu erleben. Im Büro hängen vielleicht Bilder der Familie, Cartoons, Zeitungsausschnitte, Poster usw. Man kann das Team in seiner Umgebung, dem “eigenen Revier” erleben. Das ist völlig anders, als Menschen in einen sterilen Konferenzraum zu zitieren.
• Manager reagieren auf die Ankündigung, es werde in einem Meeting Software live gezeigt, manchmal ablehnend (“Für so etwas habe ich keine Zeit.”). Auch unterhalten sie sich i.d.R. lieber mit einem Team- oder Abteilungsleiter als mit einem Entwickler oder Tester. Aber genau diese (auf Gegenseitigkeit beruhende) Abgrenzung der Projektbeteiligten voneinander – man könnte beinahe von Kastenwesen sprechen – erzeugt die allseits bekannten Effekte und Probleme in Projekten, welche wir immer zu vermeiden suchen und uns wundern, daß es nicht klappt. Wenn Menschen nicht wenigstens ab und zu direkt miteinander sondern über “Delegierte” oder nur per E-Mail kommunizieren, wie soll dann jemals ein Entwickler ein fachliches Problem verstehen und lösen können? Wie sollen ein Fachbereichskollege oder sein übergeordneter Manager vom Hörensagen verstehen, welche technischen Grenzen ein System hat bzw. welche nicht erkannten Möglichkeiten sich bieten, etwas anders oder besser zu machen?
• Warum wird überhaupt Software live vorgeführt, bevor das Projekt vollständig abgeschlossen ist? Dafür gibt es viele Gründe. U.a. kann man besser über etwas reden, das man sehen und anfassen kann als über Präsentationsfolien und Fachkonzepte. Entwicklungsfortschritt wird greifbar, Fehlentwicklungen erkennbar. Schlußendlich ist es auch einfach notwendig, wirklich zu sehen, was ein Projektteam in einem Zeitabschnitt geleistet hat. Eine direktere und bessere Möglichkeit des Projekt-Controllings hat ein Auftraggeber nicht. Aus der ansonsten gehörten Aussage eines Projektleiters, “Wir sind im Plan.”, kann er sich keine konkrete Vorstellung machen und muß darauf vertrauen, daß die Aussage wahr ist. Das nennt man dann wohl “die Katze im Sack kaufen”, und das tut kein Kunde bzw. Manager gern. Wieso sich also diese Kontrollmöglichkeit entgehen lassen?