In einem Projekt zur Umsetzung einer Web-basierten Applikation tauchte die Frage auf, ob einige der altbekannten Probleme durch ein agiles Vorgehensmodell gelöst werden könnten. Unter Betreuung eines Coachs wurde hierfür Scrum aufgesetzt, wobei keiner der Projekt-Beteiligten einschlägige Erfahrungen mitbrachte. Die folgenden Ausführungen beleuchten einige Aspekte der gesammelten Erfahrungen, setzen jedoch ein grundsätzliches Verständnis von Scrum voraus.
Bei Scrum geht es im Kern um eine Entwicklung in kurzen und überschaubaren Zyklen. Damit sollen Möglichkeiten geschaffen werden, auf veränderte Anforderungen reagieren sowie Fehlentwicklungen zeitnah erkennen und ausräumen zu können. Um diese Idee herum wird ein Vorgehensmodell mit maßgeschneiderten Rollen, Werkzeugen und Methoden definiert. Ein großer Teil davon lässt sich schlicht als formalisierter “gesunder Menschenverstand” identifizieren. Ein Beispiel hierfür ist die Schaffung von Teams mit überschaubarer Größe, in denen eine Mischung verschiedener Rollen (Konzeption, Entwicklung, Test) vorgeschrieben ist.
Rollenverständnis
Trotzdem erschließen sich Sinn und Zweck der durch Scrum vorgegebenen Elemente nicht immer unmittelbar. Einen Grund dafür stellen die anfangs gewöhnungsbedürftigen und teils schwer aus dem Englischen ins Deutsche übertragbaren Begriffe dar: Sprint, Product Owner, Daily Scrum, Burndown-Chart usw. Schon dieser Umstand verdirbt die Hoffnung auf einen spontanen Umstieg auf das Vorgehensmodell. Im betrachteten Projekt haben allein der Aufbau des Verständnisses und das endgültige Übernehmen der definierten Rollen durch die Beteiligten mehrere Sprints in Anspruch genommen. Insbesondere der Selbstfindungsprozess des Product Owners – als eine der zentralen Figuren im gesamten Prozess – gestaltete sich schwierig. Einerseits hat er die Interessen des Kunden zu vertreten, andererseits muss er die Interessen des Teams berücksichtigen. Dies setzt ein gutes Verständnis der fachlichen Domäne auf der einen und der Softwareentwicklungsprozesse auf der anderen Seite sowie ein Gespür für die jeweiligen Befindlichkeiten der Beteiligten voraus. Der Product Owner ist über die gesamte Laufzeit des Projektes dafür verantwortlich, unter Berücksichtigung des zur Verfügung stehenden Budgets gemeinsam mit dem Kunden eine tragfähige Vision für die entstehende Anwendung zu entwickeln, Anforderungen aufzunehmen, zu bewerten und diese soweit zu schärfen, dass daraus umsetzbare Features entstehen.
Die Arbeit des Product Owners hält den Scrum-Prozess am Laufen: Er ordnet Features einzelnen Sprints zu und legt Akzeptanzkriterien für die Abnahme der Features fest. Letzteres erfordert besondere Aufmerksamkeit: Sind die Kriterien unklar, wird am Ende eines Sprints zwar “Etwas” durch das Team umgesetzt sein, aber nur bedingt den Vorstellungen des Product Owners bzw. denen des Kunden entsprechen. Es hat sich daher als hilfreich erwiesen, bei der Planung eines Sprints sämtliche anstehenden Features gemeinsam intensiv zu diskutieren und die Kriterien für eine erfolgreiche Abnahme, soweit es möglich ist, noch einmal gemeinsam zu schärfen. Dabei haben sich stellvertretend für die Sicht des Kunden Oberflächenentwürfe (z. B. als Scribbles) bewährt, anhand derer das gewünschte Verhalten diskutiert und gegebenfalls angepasst werden kann. Nicht selten kommt es vor, dass auf diesem Wege offene Punkte oder Ungereimtheiten identifiziert werden, deren Klärung als Tasks in den Sprint einfließen oder im Zweifelsfall zur Rückstellung des Features führen kann.
Scrum im Original: Scrum-Situation im Rugby
(© sylvaine thomas - Fotolia.com)
Was sich gut bewährt hat
Eine Schwierigkeit in der Anfangsphase bestand in der Einschätzung, auf welche zeitliche Granularität einzelne Tasks – also der Schritte zur Umsetzung eines Features – herunter gebrochen werden sollten. Es hat sich wiederholt bestätigt, dass sich Tasks, deren Aufwände vom Team mit mehr als sechs bis acht Stunden veranlagt wurden, während des Sprints zu Risikofaktoren mit real deutlich höheren Umsetzungsaufwendungen entwickeln. Die Ursache lässt sich in diesen Fällen leicht finden: eine zu oberflächliche Diskussion des Features während der Planung und der damit fehlenden Identifizierung potentieller Fallstricke bzw. Abhängigkeiten. Einer Sprint-Planung sollte daher kein zu enges zeitliches Korsett aufgezwängt werden. Sie ist der ideale Zeitpunkt, um im gesamten Team ein gemeinsames Verständnis für fachliche und technische Konzepte zu erzeugen. Im konkreten Projekt hat sich für die Planung eines zweiwöchigen Sprints ein Umfang von einem halben Arbeitstag bewährt. Ein ähnlicher Zeitaufwand ergibt sich für Review und Retrospektive am Ende eines Sprints. Beim Aufsummieren der genannten Zeiten ergibt sich, dass mindestens ein Arbeitstag, also in diesem Fall zehn Prozent der Arbeitszeit aller Beteiligten, schon von vornherein fest für “Meetings” eingeplant werden muss. Darin ist der Zeitanteil der Daily-Scrums (weitere 15 Minuten pro Tag) noch nicht berücksichtigt. Das erzeugt bei Budgetverantwortlichen u. U. Vorbehalte, die noch verstärkt werden, da sich spürbare Ergebnisse nicht sofort nach der Einführung von Scrum einstellen, sondern durchaus zwei bis drei Monate auf sich warten lassen. Eines der wichtigsten Resultate der Sprint-Planung sind belastbare Abschätzungen für Zeitaufwendungen und die Fähigkeit des Teams, überhaupt die Umsetzbarkeit von Features innerhalb eines Sprints einschätzen zu können.
Ein durchaus nützliches Hilfsmittel für die Planung ist die so genannte “Velocity” - ein Zahlenwert, welcher Fehleinschätzungen des Teams sowie den Einfluss nicht direkt bzw. schwer planbarer Ereignisse (z. B. Störungen, Krankheiten) repräsentiert. Sie ist das Verhältnis aus der Zeit für erfolgreich abgeschlossene Features zur gesamten verfügbaren Zeit des Teams innerhalb des Sprints. Der Wert fließt in die Planung des folgenden Sprints ein und ist ein Maß dafür, in welchem Umfang Tasks anhand der verfügbaren Zeit mit großer Wahrscheinlichkeit abgearbeitet werden können. Die ermittelten Werte der Velocity wirken zu Beginn äußerst ernüchternd – im vorliegenden Projekt lagen sie anfangs sehr deutlich unter 50 Prozent und überschritten später diesen Wert nicht maßgeblich. Von Bedeutung ist allerdings nicht die Höhe der Velocity, sondern der Umstand, dass sie sich in einem gewissen Wertebereich einpegelt. Die Velocity ist kein Maß für Produktivität, denn sie misst nicht die Leistungsfähigkeit des Teams. Sie ist viel mehr Ausdruck dessen, wie stark sich Umwelteinflüsse auf die ursprüngliche, unter realistischen Gesichtspunkten ausgeführte Planung auswirken.
Retrospektive
Die angesprochenen Themen sind nur ein Teil der in der Praxis gesammelten Erkenntnisse. Mit dieser Aussage tritt jedoch eine weitere Erkenntnis zu Tage: Scrum ist keine Magie sondern auch nur ein Vorgehensmodell – es anzuwenden setzt die Akzeptanz durch alle Beteiligten sowie das Verständnis und den konsequenten Einsatz der zugehörigen Werkzeuge voraus. Mit dem Einstieg verbunden ist das Durchleben eines längeren Lernprozesses, welcher durch Zertifizierungskurse bzw. Literatur zwar unterstützt, aber keinesfalls ersetzt werden kann. Für die Einführung von Scrum ist es also nicht ausreichend, ein Scrum-Board an der Wand zu befestigen und jeden Tag eine Viertelstunde davor ein Meeting namens Daily Scrum abzuhalten, solange die Beteiligten nicht wissen, wozu dieses eigentlich dient.
Laden Sie sich den Artikel “Täglich Scrum” als PDF herunter.
