Agiles Projektmanagement mit SCRUM (Teil 2)

I. Rollen

Ein SCRUM-Team umfasst feste Rollen: den Product Owner [02], den SCRUM Master [03] sowie das Development Team [06] – letztlich aber auch die Gruppe der Stakeholder [01], wenn diese auch nicht eigens im „SCRUM-Guide“ definiert ist. Nach dessen Vorgaben variiert die Mitgliederzahl von Teams zwischen drei und neun Personen. Dieser beschreibt seine Größe wie folgt: „Klein genug, um flink zu bleiben, groß 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 von Teams muss einen selbstorganisierenden und funktionsübergreifenden Charakter aufweisen. Im Idealfall resultieren daraus Entscheidungen, die auf dem gesamten Team basieren, und auch dessen durchschlägige Verantwortung für diese.

Individuelle Kompetenzprofile sollen sich zudem 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 eines Produkts, 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 nun 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 – vgl. die Ausführungen zum „SCRUM-Guide“ im Teil I. Durch seine obligatorische Erreichbarkeit ist er Garant für das Vermeiden bzw. das Lösen von Problemen während des gesamten SCRUM-Prozesses.

Er agiert nicht konventionell in der Rolle eines Projektmanagers, stellt demnach auch keine herkömmlicheS. 9 Autorität zur Steuerung des Vorgehens dar. Vielmehr sind es die Moderation, Vermittlung und Unterstützung, die seine Rolle bestimmend kennzeichnen.

Besonders durch seine 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äß als größte Herausforderung für das Entwicklerteam dar. Bis zur gegenwärtig verbindlichen Ausgabe des „SCRUM-Guide“ stand allein das Sprintziel im Vordergrund.

Stakeholder, zunächst eher „im Hintergrund“ angesiedelt, wirken während des gesamten SCRUM-Prozesses auf das Projektteam ein. Sie lassen sich als Anspruchsgruppe ausmachen, die – in einem abstrakten Sinne – als Summe der Anforderungen am Markt zu betrachten ist. Endkunden mit ihren jeweiligen Kundenwünschen zählen etwa dazu. Eine eigene Rolle im engeren Sinne nehmen Stakeholder nach dem „SCRUM-Guide“ zwar nicht ein. In der Praxis sind sie wesentliche Beteiligte – auf sie gehen die Items, kommuniziert über User Stories und gegebenenfalls auch Epics, zurück.

Die Konkretisierung einer Vision erfolgt regelmäßig durch Anwendungsfälle (User Cases). Inwieweit man zum Kundenbeziehungsmanagement bzw. zur Pflege von Kundenbeziehungsprozessen bereits ein Customer-Relationship-Management-System – Kurzform: CRM-System – einsetzt, stellt sich insoweit zunächst als sekundär dar. Im Hinblick auf skalierte SCRUM-Prozesse erfahren in der Definition von Marktanforderungen ferner Capabilities und Features eine gesonderte Berücksichtigung.

Der Grund dafür: Produkte und Wertschöpfungsketten weisen in der Wirklichkeit einen äußerst hohen Grad an Komplexität auf, so dass nicht selten auch dritte, am Entwicklungsprozess scheinbar zunächst gar nicht oder nur mittelbar beteiligte Gruppen umfassend in ihren jeweiligen Interessen zu berücksichtigen und im Zweifel sogar auch in den Prozess einzubinden sind.

Eine professionelle Skalierung lässt sich allein auf der Grundlage fortentwickelter Rahmenwerke realisieren. Nexus oder Large Scale Scrum (LeSS) gehören zu den diesbezüglich bekanntesten Varianten. Das entscheidende Kriterium für deren Anwendungseffizienz ist eine stetige Auswertung des jeweiligen Geschäftswerts, also des über den substanziellen Wert hinausgehenden Mehrwerts für Stakeholder – beispielsweise zur Bekanntheit und dem Ruf einer Marke.

II. Ereignisse

Das bedeutendste Event im SCRUM ist der Sprint [09], dem immer eine Vision vorausgeht. Es handelt sich um die verbindliche Zeitspanne einer Iteration zur potenziellen Auslieferung eines Produkts. Seine Dauer beträgt ein bis vier Arbeitswochen. Kennzeichnend für ihn ist ein durchgängiger, ununterbrochener Charakter. Jedoch kann ein Sprint bei seinem absehbaren Scheitern auch abgebrochen werden, wobei in unmittelbaren Anschluss ein Rückblick erfolgt und daraufhin die Planung eines neuen Sprints ansetzt.

Ein Sprint kann gewissermaßen als ein übergeordneter Container angesehen werden, der weitere spezifische Aktivitäten enthält. Dazu zählen unter anderem seine Vor- sowie Nachbereitung bzw. eine adäquate Organisation. Ihm geht regelmäßig mindestens ein Sprint [00] voraus. Jeder Sprint ist als ein kontinuierlicher Verbesserungsprozess [10] – Kurzform: KVP – zu begreifen.S. 10

Abb. Der Scrum-Prozess im Detail – Rollen, Ereignisse und Artefakte

Legende zur Abbildung

Im Sinne einer bindenden Struktur, gemeint sind die in der Einleitung angeführten Zeremonien, dienen Ereignisse generell einer Projektstabilisierung. Das Planning bestimmt im Vorfeld den zeitlichen Rahmen, die erforderlichen Mittel sowie nicht zuletzt die passende Arbeitsumgebung bzw. das Raumkonzept (siehe „Mindmapping“ aus: Die Kaufleute für Büromanagement 03/2021). 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. Maßgeblich ist insoweit seine innere Kommunikation.

Unterschieden werden zwei Planungsphasen: Innerhalb der ersten Zusammenkunft (Planning 1) wird die Substanz von bis zu 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) zielt auf ein weiteres Konkretisieren sowie Detaillieren von Aufgaben ab. Nach dem „SCRUM-Guide“ 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.S. 11

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 [08] – Kurzform: DoD, ein Hilfsmittel – abgebildet. Sie unterliegt einer Absprache des gesamten SCRUM-Teams, woraus sich eine Bestärkung sowohl des Zusammenhalts eines Teams als besonders auch dessen interner Kommunikation ergibt.

Im Daily SCRUM [11], ein tägliches Treffens zum Informationsaustausch und zur Statusprüfung (Monitoring bzw. Controlling, vgl. Glossar im Teil I), kommt es ebenfalls zur Arbeit mit Task Boards, die den Ist-Zustand – Probleme, Hindernisse und Erfolge also – beinhalten. Sein Kernziel ist es, eine Prognose zur Bearbeitung der offenen User Stories zu ermöglichen. Ein Daily SCRUM wird als so genanntes Stand-up-Meeting durchgeführt. 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, lösungsorientierte Themen, mittelbar formuliert als Fragen, auf:

1. Warum ist dieser Sprint wertvoll?

2. Was kann in diesem Sprint abgeschlossen werden?

3. 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 bedeutenden 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 im engeren Sinne beteiligt.

III. Artefakte

Ursprünglich aus der Modellierungssprache für Software sowie anderer Systeme stammend, beschreibt der Begriff Artefakt einen Modell-Zustand. Dieser ergibt sich stets als das Ergebnis aus einem Arbeitsprozess. SCRUM unterscheidet zwischen drei Artefakten:

1. 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 – die Bedarfe werden nicht in absoluten Personalstunden, sondern durch Schätzung zur Vermeidung von Leerläufen in relativen Storypoints bewertet – als essenziell dar. Das Ziel von Schätzungen ist keine Sicherheit, sondern Klarheit. Grundlage sind insoweit das Wie? und das Wie viel?

   Info

   Planning Poker

   Basis ist ein spezielles Kartenset für jedes Mitglied eines Development Teams. Der Product Owner stellt pro Product Backlog Item (PBI) eine Nachfrage zu dessen Aufwand. Die Mitglieder legen daraufhin jeweils die Karten mit ihren individuellen Schätzwerten offen. Diskussionen über den niedrigsten und höchsten Wert sowie fortlaufende Wiederholungen für das aktuelle und weiterer PBI dienen dem Konsens.S. 12

   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.

2. 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.

3. 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“, also in der Entstehung befindliches Produkt zugrunde liegt.

SCRUM-Werte

Agile Teams sind auf eine konsequent umgesetzte transparente Zusammenarbeit ihrer Mitglieder angewiesen. Diese basiert bei SCRUM, dem wohl bekanntesten Framework im leichtgewichtigen Projektmanagement, auf folgenden, obligatorisch zu teilenden fünf Werten bzw. Wertvorstellungen:

Selbstverpflichtung

Im Sinne einer Arbeitsgemeinschaft verstehen SCRUM-Teams sich als Einheit. Ihre Mitglieder verbindet deren jeweilige Selbstverpflichtung (engl. Commitment) nicht nur zur Kooperation, sondern eben zur beschriebenen Kollaboration. Es gilt, die kollektive Intelligenz sowie das individuelle Innovationspotenzial zu bündeln.

Fokus

Erst die obligatorische Konzentration auf das Ziel des jeweiligen Sprints, die Entwicklungsphase eines Teilergebnisses, ermöglicht ein effizientes Vorgehen zur Lösung von Problemen. Durch die enge „Taktung“ von Iterationsschleifen fallen dabei weniger Hindernisse an.

Offenheit

Kommunikationswege sind im SCRUM-Prozess klar zu gestalten, jedes Teammitglied muss vorbehaltlos seine Position offenlegen sowie darstellen können. Offenheit meint zudem das Bestreben, sich konsequent neuen Herausforderungen stellen zu wollen.

Respekt

Die scheinbare Selbstverständlichkeit dieses Wertes unterstreicht nur dessen Bedeutung. Der gegenseitige Respekt sollte sämtliche Ebenen eines Unternehmens durchdringen. Da unternehmerische Positionen nicht den vorgesehenen Rollen des Rahmenwerks entsprechen, bedeutet eine Verwirklichung dieser Wertvorstellung immer auch die Konfrontation mit bestehenden hierarchischen Mustern. Im Idealfall können diese durch eine Veränderung der Corporate Culture aufgelöst werden.

Mut

Mut (engl. Courage) ist gleichsam die Voraussetzung für einen anderen Wert: die Offenheit. Er stellt auf die Befähigung des Einzelnen zum pragmatischen Handeln in volatilen sowie ambivalenten Situationen ab und beinhaltet die Bereitschaft zu einem dementsprechenden Risiko. Ein mögliches Scheitern muss von vorneherein miteinkalkuliert werden.

Solange diese Werte nicht konsequent geteilt werden, bleibt es bei reinen „Worthülsen“. SCRUM setzt auf einen gemeinsamen Erkenntnisgewinn als Voraussetzung für einen kontinuierlichen Verbesserungsprozess. Der Austausch von Wissen, dessen Wert sich durch Gebrauch erhöht und im Gegensatz zur Nutzung sonstiger Ressourcen durch diesen nicht verringert, ist essenziell für ein erfolgreiches agiles Arbeiten.

Die SCRUM-Werte bilden das Fundament des Framework, darauf basierend stellen sich seine drei Säulen Transparenz, Überprüfung und Anpassung als formale Voraussetzungen für den angestrebten kontinuierlichen Verbesserungsprozess (KVP) dar.

Transparenz

Als Voraussetzung für Transparenz ist eine offene Kommunikation sowie die umfassende Bereitschaft der Prozessbeteiligten zum Teilen von Wissen nötig.

Überprüfung

Sämtliche Ergebnisse müssen einer Überprüfung standhalten.

Anpassung

Zur Steigerung der Arbeitseffizienz ist eine fortlaufende Anpassung der zugrunde liegenden Rahmenbedingungen erforderlich.

Fundstelle(n):
BÜRO 11/2021 Seite 8
KIEHL YAAAH-93745