Scrum – agile Umsetzung von Projekten

Bedingt durch die Krise etabliert sich im Sensemaking gegenwärtig ein neuer Ansatz: BANI. Das Akronym basiert auf den Attributen b:rittle (brüchig), ­a:nxious (ängstlich), n:on-linear (nicht-linear) und i:ncomprehensible ­(unbegreiflich). Bisherige Erfahrungen werden danach grundsätzlich in Frage gestellt – genauso wie einschlägige Muster. Begünstigt wird dieser Umstand durch omnipräsente, mitunter disruptive Kommunikationstechnologien. Der daraus resultierende Anpassungsdruck für Organisationen ist erheblich – gerade klein- und mittelständische Unternehmen können durch die ­Anwendung von Scrum konstruktiv auf die aktuellen Verhältnisse reagieren und nachhaltig «Mehrwerte» schaffen.

Im Zentrum von Scrum stehen hochflexible Teams. Sein minimalistisches Regelwerk ermöglicht ein strategisches sowie anpassungsfähiges Vorgehen innerhalb von Innovations- und Entwicklungsprozessen. Ausgerichtet ist es auf pragmatisch umsetzbare Ziele: zeitnahe und wirksame Ergebnisse. Verbindliche Ereignisse, Rollen und Artefakte bilden insoweit den Rahmen. Dieser fokussiert die eigenverantwortliche Interaktion – basierend auf einer ausgeprägten Selbstkompetenz und Resilienz – sowie die transparente Kollaboration der am Prozess Beteiligten. Die derzeit gültige Fassung des «Scrum Guide» vom November 2020 liess das Framework noch leichtgewichtiger als bisher ausfallen.

Scrum und agile Werte
Massgeblich für die Definition von Scrum ist allein der zitierte Guide. Allerdings finden sich in seinem Umfeld zahlreiche Techniken und Instrumente, die das Vorgehensmodell förmlich erweitern bzw. dessen inhaltlich-konkretisierende Ausgestaltung überhaupt erst ermöglichen.

Die Grundidee von Scrum basiert auf den Werten des «Agilen Manifests» aus dem Jahr 2001, vgl. www.agilemanifesto.org:

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
• Funktionierende Software ist wichtiger als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen
• Reagieren auf Veränderungen ist wichtiger als das Befolgen eines Plans

Sowohl das «Agile Manifest» als auch Scrum finden ihren historischen Ursprung in der Entwicklung von Software. Nicht zuletzt bei einem Mangel an Motivation von Mitgliedern eines Teams, greifbaren Resultaten, Ressourcen wie Finanzmitteln oder der Klarheit in der Gestaltung des Projekts selbst, bietet sich Scrum als zuverlässige Alternative für eine aufstrebende Projektverwirklichung an. Verantwortet wird es stets von kleineren bzw. einzelnen Teams. Eine professionelle Skalierung ermöglichen beispielsweise Nexus oder Large Scale Scrum (LeSS).

I. Ereignisse
Das bedeutendste Event im Scrum ist der Sprint [09], dem immer eine Vision vorausgeht. Es handelt sich um die verbindliche Zeitspanne einer Iteration (Dauer: ein bis vier Arbeitswochen) zur potenziellen Auslieferung eines Produkts. Kennzeichnend ist sein durchgängiger, ununterbrochener Charakter. Ein Sprint kann als übergeordneter Container angesehen werden, der weitere spezifische Aktivitäten enthält. Dazu zählen unter anderem seine Vor- sowie seine Nachbereitung bzw. Organisation. Ihm geht regelmässig mindestens ein Sprint [00] voraus. Jeder Sprint ist als ein «Kontinuierlicher Verbesserungsprozess» (KVP) [10] zu begreifen.

Im Sinne einer bindenden Struktur dienen Ereignisse generell der Projektstabilisierung. Das Planning bestimmt im Vorfeld den zeitlichen Rahmen, die erforderlichen Mittel sowie nicht zuletzt die passende Arbeitsumgebung – so das Raumkonzept. Das Scrum-Team stellt sich dabei als Repräsentanz der Gesamtheit aller Verantwortlichkeiten dar. Präzision und Konsistenz der von dieser ausgehenden Planung wirken sich entscheidend auf den Erfolg oder Misserfolg eines Projekts aus.

Unterschieden werden dabei zwei Planungsphasen: Innerhalb der ersten Zusammenkunft (Planning 1) wird die Substanz von häufig nur aus zwei Sätzen bestehenden User Stories ermittelt, um daraus Items und Tasks abzuleiten. Abhängig von der Dauer eines Sprints umfasst das Planning eine bis zu acht Stunden.

Das zweite Meeting (Planning 2) ist auf ein weiteres Konkretisieren sowie Detaillieren von Aufgaben ausgerichtet. Nach dem Scrum Guide 2020 soll aus ihm «ein deutlich sichtbares Echtzeitbild der Arbeit» hergeleitet werden. Genutzt werden dazu Scrum Task Boards. Diese Ausplanung [07] ist ausgerichtet auf das Design in der Umsetzung der am höchsten gewichteten Stories.

Abgebildet wird der Plan für den Sprint – dieser folgt dem «Wofür?», also dem Sprintziel [15] – im Product Backlog. Qualitative Kriterien werden daneben in der so genannten «Definition of Done» (DoD, ein Hilfsmittel) [08] abgebildet. Sie unterliegt einer Absprache des gesamten Scrum-Teams, woraus eine Bestärkung sowohl des Zusammenhalts eines Teams als besonders auch dessen interner Kommunikation resultiert.

Im Daily Scrum [11], ein tägliches Treffens zum Informationsaustausch und zur Statusprüfung («Controlling»), kommt es ebenfalls zur Arbeit mit Taskboards, die den Ist-Zustand – Probleme, Hindernisse und Erfolge also – abbilden. Sein Ziel ist es insbesondere, eine Prognose zur Bearbeitung der offenen User Stories zu ermöglichen. Ein Daily Scrum sollte als so genanntes Stand-up-Meeting durchgeführt werden. Auf seiner Grundlage erfolgt eine Justierung von Aufgaben [13] und gleichzeitig eine wechselseitige Zuschreibung von Verantwortlichkeiten im Team.

Der Scrum Guide weist zum Sprint Planning folgende, in jedem Fall abzuhandelnde, zielorientierte Themen auf, mittelbar formuliert als Fragen

• Warum ist dieser Sprint wertvoll?
• Was kann in diesem Sprint abgeschlossen werden?
• Wie wird die ausgewählte Arbeit erledigt?

Im Sprint Review [16] werden den Stakeholdern [01] Inkremente [14], die von diesen abzunehmen sind, präsentiert. Diskutiert wird zudem über Organisatorisches und den allgemeinen Stand in der Produktentwicklung. Der Product Owner lädt zu dieser «Zeremonie» ein.

In der Sprint Retrospective [17] wird der letzte Sprint durch das gesamte Projektteam sowie den Stakeholdern betrachtet und ausgewertet (Evaluation). Im Idealfall soll sich daraus eine Optimierung eines möglicherweise folgenden Sprints [18] ergeben. Auch hier sind sowohl die Stakeholder als auch das Scrum-Team beteiligt.

II. Rollen
Ein Scrum-Team umfasst feste Rollen: den Product Owner [02], den Scrum Master [03] sowie das Development Team [06]. Nach den Vorgaben des Scrum Guides variiert seine Mitgliederzahl zwischen drei und neun. Dieser beschreibt seine Grösse wie folgt: «Klein genug, um flink zu bleiben, gross genug, um wichtige Aufgaben in einem Sprint – dem wertschöpfenden Projektprozess also – zu erledigen.»

Verantwortlich für die Rollenvergabe vor dem Sprint sind die eigentlichen Projektinitiatoren. Als kritisch anzusehen sind allerdings in der Praxis nicht selten anzutreffende Doppelrollen. Die Zusammensetzung des Teams muss einen selbstorganisierenden und funktionsübergreifenden Charakter aufweisen. Resultieren sollen daraus Entscheidungen, die auf dem gesamten Team basieren, und auch dessen durchschlägige Verantwortung für diese.

Individuelle Kompetenzprofile sollen sich nach Möglichkeit ergänzen. Diversität, nicht nur im Sinne einer gewährleisteten Pluridisziplinarität, sondern etwa auch in puncto einer ausgewogenen Geschlechterverteilung sowie Herkunft, ist dabei von zentraler Bedeutung. Dies gilt zudem für die individuellen Denkpräferenzen.

Der Product Owner ist der Produkteigner. Es handelt sich um eine Person, nicht um ein Gremium. Er vertritt sämtliche Interessen der Stakeholder. Dies geschieht durch eine sichtbare und verständliche Kommunikation. Er formuliert auch das so genannte Produktziel, eine verbindliche Bestimmung der Eigenschaften des Produkts (neues Konzept im aktuell gültigen Scrum Guide) und ist verantwortlich für die Maximierung dessen Werts. Erforderlich ist für seine Rollenausübung, dass nicht nur der Scrum Master sowie das Development Team, sondern die gesamte Organisation seine Entscheidungen zu den Produktanforderungen respektieren.

Beim Scrum Master handelt es sich ebenfalls um nur eine Person. Seine Hauptaufgabe als Dienstleister dem Product Owner, dem Development Team, aber auch der gesamten Organisation gegenüber, besteht in der korrekten Durchführung des Scrum-Regelwerks in Theorie und Praxis. Es besteht eine obligatorische Erreichbarkeit seiner Person als Garant für das Vermeiden oder das Lösen von Problemen während des gesamten Scrum-Prozesses. Er agiert nicht etwa konventionell in der Rolle eines Projektmanagers, stellt demnach auch keine herkömmliche Autorität zur Steuerung des Vorgehens dar. Vielmehr sind es die Moderation, Vermittlung und Unterstützung, die seine Rolle bestimmend kennzeichnen.

Besonders durch Selbstorganisation ist das Development Team gekennzeichnet. Praktisch wirkt sich dies auf die Gewichtung von Aufgaben aus. Orientierungsmarke, die wiederum das Selbstmanagement erheblich begünstigt, ist stets das Produktziel – ergo der fest umrissene künftige Zustand des Produkts. Dieses stellt sich naturgemäss als grösste Herausforderung für das Entwicklerteam dar.

Stakeholder, zunächst eher «im Hintergrund» angesiedelt, wirken während des gesamten Scrum-Prozesses auf das Projektteam ein. Sie lassen sich konkret als Anspruchsgruppe ausmachen, die – abstrakt – als Anforderungen des Markts zu betrachten ist. Endkunden mit ihren Kundenwünschen zählen dazu. Eine eigene Rolle im engeren Sinne nehmen Stakeholder nach dem Scrum Guide zwar nicht ein. Praktisch wirken sie aber als wesentlich Beteiligte, auf sie gehen die Items, kommuniziert über User Stories und gegebenenfalls auch Epics, zurück.

III. Artefakte
Ursprünglich aus der Modellierungssprache für Software sowie anderer Systeme stammend beschreibt der Begriff Artefakt einen Modellzustand. Dieser ergibt sich als Ergebnis aus einem Arbeitsprozess. Scrum unterscheidet zwischen drei Artefakten:

Product Backlog [04]: Aufführung des Auftragsbestands bzw. der im Projekt geltenden Anforderungen und Aufgaben. Gepflegt und weiterentwickelt wird der Product Backlog durch den Product Owner. Für den Projekterfolg stellt sich ein gut organisierter sowie priorisierter Product Backlog – der Bedarf wird nicht in absoluten Personalstunden, sondern durch Estimating zur Vermeidung von Vakua in relativen Storypoints geschätzt – als essenziell dar. Das Ziel von Schätzungen ist keine Sicherheit, sondern Klarheit. Grundlage sind insoweit das «Wie?» und das «Wie viel?».
Im Übrigen ergeben sich Entscheidungen des Product Owners aus der Reihenfolge der entsprechenden Einträge. Diese Pflege und Weiterentwicklung des Product Backlog wird als Refinement [12], gelegentlich auch noch als Grooming bezeichnet.

Sprint Backlog [05]: Visualisierung der Fortschritte bzw. Verfeinerung der Anforderungen. Der Sprint Backlog dient der Ausrichtung auf den nächsten Sprint (Iteration) und damit auf das nächste Teilprodukt (Inkrement). Die Verantwortung für den Sprint Backlog liegt beim Development Team.

Product Increment [14]: Produkt bzw. eben Teilprodukt eines Sprints. Beim Product Increment handelt es sich um das angestrebte, keinesfalls gesicherte (Zwischen-)Ergebnis am Ende von Iterationsschleifen. Jedes Product Backlog findet sich in der Summe bisheriger Arbeiten wieder. Notwendigerweise folgende Sprints verdeutlichen, dass ein «werdendes», in Entstehung befindliches Produkt zugrunde liegt.

Kein universeller Lösungsansatz
Die Hauptvorteile in der Anwendung von Scrum liegen in seinen kurzen Kommunikationswegen sowie in dem zugrunde liegenden minimalistischen Regelwerk. Zudem stellt es sich als ein konsequenter und kontinuierlicher Verbesserungsprozess dar. Es bildet jedoch weder den gesamten Ablauf eines Projekts ab noch gibt es konkrete Handlungsanweisungen. Dadurch können im Team nicht zuletzt problematische Priorisierungen entstehen. Zuletzt – Scrum versteht sich nicht als universeller Lösungsansatz.