SCRUM wurde ursprünglich für die Softwaretechnik entwickelt, wird aber inzwischen in vielen anderen Bereichen eingesetzt und gilt seit über 20 Jahren als Alternative zu den traditionellen Projektplanungsmethoden wie z.B. das bekannte Wasserfall-Modell:
Dieses verdankt seinen Namen seiner strikten top-down-Planung, von oben nach unten, eben wie ein Wasserfall. Jede Phase hat vordefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen. In Meilensteinsitzungen am jeweiligen Phasenende werden die Ergebnisdokumente verabschiedet. Zu den wichtigsten Dokumenten zählen dabei das Lastenheft sowie das Pflichtenheft. In der betrieblichen Praxis gibt es viele Varianten des reinen Modells. Es ist immer noch ein traditionell weit verbreitetes Vorgehensmodell.
Die Hauptkritik an dieser Vorgehensweise besteht in der geringen Flexibilität. Der komplette Projektplan wird meist am Anfang festgelegt und dann über eine viel zu lange Zeit stur beibehalten. Man hat am Ende zwar ein Ergebnis, aber inzwischen haben sich oft die Kundenwünsche oder Marktanforderungen verändert.
Scrum als Alternative zu traditionellen Methoden behauptet, ein wesentlich flexibleres Verfahren mit ständiger Rückkopplung zu bieten. In einem „agilen Manifest“ wurden schon im Jahre 2001 die folgenden Werte festgelegt:
Die Methode berücksichtigt, dass ein wesentlicher Teil der Anforderungen in einem Projekt zu Beginn noch unklar ist. Diese Unklarheit soll beseitigt werden, indem der gesamte Ablauf in immer wieder neu bestimmte Zwischenergebnisse aufgeteilt wird. Anhand dieser sollen sich dann fehlende Anforderungen und Lösungstechniken effizienter finden lassen.
Die Methode sieht unterschiedliche Rollen vor,
Die Planung eines Projekts wird iterativ, d.h. in kleineren Schritten, entwickelt. Der langfristige Plan wird in einem Product Backlog festgehalten und kontinuierlich verfeinert bzw. verbessert. Ein Detailplan, das Sprint Backlog, wird immer nur für den jeweils nächsten Zyklus, den sogenannten Sprint erstellt.
Fortschritte und Hindernisse eines Projektes werden regelmäßig und für alle sichtbar festgehalten. Anforderungen an das Produkt, Pläne und Vorgehen werden kontinuierlich und detailliert angepasst. Dadurch wird die Aufgabe in kleinere und weniger komplexe Bestandteile strukturiert, die als Inkremente bezeichnet werden.
Ein Sprint ist ein Arbeitsabschnitt, in dem ein Teil der Produktfunktionalität bearbeitet wird. Er beginnt mit einem Sprint Planning und endet mit Sprint Review und Sprint-Retrospektive.
Sprints folgen unmittelbar aufeinander. Während eines Sprints sind keine Änderungen erlaubt, die das Sprintziel beeinflussen. Ein Sprint umfasst ein Zeitfenster von ein bis vier Wochen und darf nicht verlängert werden – er ist zu Ende, wenn die Zeit abgelaufen ist. Unerledigte Arbeiten werden auf den nächsten Sprint verschoben.
Ein Sprint kann vorzeitig vom Product Owner abgebrochen werden, wenn das Sprint-Ziel nicht mehr erreicht werden soll, beispielsweise wenn sich die Zielvorgaben für die Kundschaft oder die Marktbedingungen geändert haben.
Das Product Backlog ist eine geordnete Auflistung der Anforderungen an das Produkt. Es wird ständig weiterentwickelt. Der Product Owner ist für die Pflege des Product Backlogs verantwortlich.
Der Product Owner stellt dem Entwicklungsteam die im Product Backlog festgehaltenen Produkteigenschaften in einer mit Prioritäten versehenen Reihenfolge vor. Es sollte so vorbereitet sein, dass die Einträge für den nächsten Sprint geordnet und gefüllt sind.
Das gesamte Scrum Team arbeitet im ersten Teil der Planung daran, ein gemeinsames Verständnis für die im Sprint zu erledigende Arbeit zu entwickeln. Außerdem einigt sich der Product Owner mit dem Entwicklungsteam auf die Kriterien, die am Ende des Sprints darüber entscheiden, ob die neue Funktionalität fertig ist oder nicht. Ziel ist ein auslieferbares Produkt, das hinreichend getestet ist, um für die Benutzer freigegeben werden zu können.
Anschließend prognostiziert das Entwicklungsteam die Anzahl der Product Backlog-Einträge, die es im nächsten Sprint bearbeiten will. Die Entscheidung, wie viele Einträge hier umgesetzt werden, liegt allein beim Team, während die Entscheidung über die Reihenfolge allein beim Product Owner liegt.
Im zweiten Teil der Sprint Planung plant das Entwicklungsteam im Detail, welche Aufgaben (Tasks) zum Erreichen des Sprintziels und zur Lieferung der prognostizierten Product Backlog-Einträge notwendig sind.
Das Ergebnis ist das Sprint Backlog: der detaillierte Plan für den nächsten Sprint. Er enthält die für den Sprint geplanten Product Backlog-Einträge und die Aufgaben zu deren Umsetzung. Das Sprint Backlog wird laufend nach der Erledigung einer (Teil-)Aufgabe von den Team-Mitgliedern aktualisiert und dient zur Übersicht des aktuellen Bearbeitungsstands. Um es für alle sichtbar zu machen, wird häufig ein Taskboard als Technik genutzt.
Zu Beginn eines jeden Arbeitstages trifft sich das Entwicklungsteam zu einem max. 15-minütigen meeting, dem Daily Scrum, bei dem Scrum Master und Product Owner häufig anwesend, jedoch nicht unbedingt aktiv beteiligt sind. Zweck des Daily Scrum ist allein der Informationsaustausch. Hier geht es darum, sich einen Überblick über den aktuellen Stand der Arbeit zu verschaffen. Dazu hat sich bewährt, dass jedes Teammitglied mit Hilfe des Taskboards sagt, was es seit dem letzten Daily Scrum erreicht hat, was es bis zum nächsten Daily Scrum erreichen möchte, und was dabei im Weg steht.
Beim Daily Scrum kann offensichtlich werden, dass die Erledigung einer Aufgabe länger als geplant dauert. Dann soll der Task in kleinere Aufgaben aufgeteilt werden, die dann auch von anderen Mitgliedern des Entwicklungsteams übernommen werden können.
Treten beim Daily Scrum Fragen auf, die sich nicht innerhalb der strikten 15-Minuten-Vorgabe beantworten lassen, so werden sie entweder dem Scrum Master übergeben, oder ihre Beantwortung wird auf ein späteres Meeting verlegt.
Das Sprint Review steht am Ende des Sprints. Das Entwicklungsteam präsentiert seine Ergebnisse, und es wird überprüft, ob das zu Beginn gesteckte Ziel erreicht wurde. Hier ist die Beteiligung von Kunden und Anwendern wichtig.
Es ist Aufgabe des Product Owners, die entwickelten Funktionalitäten zu begutachten. Anhand der im Sprint Planning festgelegten Bedingungen entscheidet er, ob sie abgenommen werden können oder nicht. Dabei soll er keine Kompromisse eingehen. Ein Team hat auch dann sein Ziel verfehlt, wenn es eine „fast fertige“, aber noch nicht getestete Funktionalität liefert. In diesem Fall werden die nicht fertiggestellten Teile in das Product Backlog aufgenommen und vom Product Owner neu priorisiert.
Das Sprint Review soll maximal eine Stunde je Sprint-Woche dauern.
Die Sprint-Retrospektive steht am Ende eines Sprints. Hierbei überprüft das Scrum Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter und effektiver zu machen. Der Scrum Master soll das Scrum Team darin unterstützen, gute Praktiken und Verbesserungen zu finden, die im nächsten Sprint umgesetzt werden.
Das Team soll seine Arbeitsweise offen und ehrlich überprüfen können. Dazu müssen Kritik und unangenehme Wahrheiten auch offen geäußert werden können, einschließlich der Gefühle und Empfindungen der Teammitglieder. Die Retrospektive soll daher in einem geschützten Raum ablaufen. Stakeholder dürfen nur auf Einladung dazukommen.
Die Sprint-Retrospektive soll maximal 45 Minuten je Sprint-Woche dauern.
Das Scrum Framework kennt die Rollen Product Owner, Entwicklungsteam, Scrum Master und Stakeholder.
Der Product Owner ist für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts verantwortlich. Er erstellt, priorisiert und erläutert die zu entwickelnden Produkteigenschaften und beurteilt, welche Eigenschaften am Ende eines Sprints fertiggestellt wurden. Ihm allein obliegt die Entscheidung über das Produkt, seine Eigenschaften und die Reihenfolge der Implementierung.
Zur Festlegung der Produkteigenschaften verwendet der Product Owner das bereits erwähnte Product Backlog. Darin trägt er in Zusammenarbeit mit dem Entwicklungsteam und den Stakeholdern die Anforderungen an das Produkt ein. Als Produktverantwortlicher hält er regelmäßig Rücksprache mit den Kunden, den sog. Stakeholdern, um deren Bedürfnisse und Wünsche besser zu verstehen. Dabei muss er die Interessen und Anforderungen unterschiedlicher Stakeholder verstehen und abwägen.
Das Entwicklungsteam ist für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich. Es trägt die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards und organisiert sich selbst. Nach dem Scrum-Konzept soll es sich von niemandem, auch nicht vom Scrum Master, vorschreiben lassen, wie es Backlog-Einträge umzusetzen hat. Es sollte in der Lage sein, das Ziel eines jeweiligen Sprints ohne größere äußere Abhängigkeiten zu erreichen. Deshalb ist eine interdisziplinäre Besetzung des Entwicklungsteams wichtig. Gute und schlechte Ergebnisse werden nie auf einzelne Teammitglieder, sondern immer auf das Entwicklungsteam als Einheit zurückgeführt. Das ideale Teammitglied ist sowohl Spezialist als auch Generalist.
Zu den weiteren Aufgaben eines Entwicklungsteams zählt die Schätzung des Umfangs der Einträge im Product Backlog. Außerdem werden in der Sprint Planung die für einen Sprint ausgewählten Einträge aus dem Product Backlog in einzelne Arbeitsschritte, sogenannte Tasks, heruntergebrochen. Deren Bearbeitung soll in der Regel nicht länger als einen Tag dauern. Das Ergebnis ist das Sprint Backlog.
Der Scrum Master hat sozusagen eine Art Gesamtverantwortlichkeit. Er arbeitet mit dem Entwicklungsteam zusammen, gehört aber selbst nicht dazu. Er führt die Scrum-Regeln ein, überprüft deren Einhaltung und kümmert sich um die Behebung von Störungen und Hindernissen. Dazu gehören mangelnde Kommunikation und Zusammenarbeit sowie persönliche Konflikte im Entwicklungsteam, Störungen in der Zusammenarbeit zwischen Product Owner und Entwicklungsteam sowie Störungen von außen, beispielsweise Aufforderungen der Fachabteilung oder des Managements zur Bearbeitung zusätzlicher Aufgaben während eines Sprints. Der Scrum Master soll gegenüber dem Entwicklungsteam eine dienende Funktion haben. Er erteilt keine Arbeitsanweisungen. Weder beurteilt er die Teammitglieder, noch belangt er sie disziplinarisch. Er ist vielmehr als Coach für den Prozess und die Beseitigung von Hindernissen verantwortlich.
Die Stakeholder sind Rollen außerhalb von Scrum. Dabei kann es sich um Kunden, Anwender oder auch das Management des Unternehmens handeln.
Es ist Aufgabe des Product Owners, darauf zu achten, dass die Kunden ihr Wunschprodukt erhalten. Deshalb sollte er mit den Kunden im engen Austausch stehen. Die Kunden sollten schon nach den ersten Sprints Gelegenheit haben, sich Zwischenergebnisse anzuschauen und dazu Feedback zu geben.
Anwender sind diejenigen Personen, die das Produkt später benutzen sollen. Ein Anwender kann, muss aber nicht zugleich Kunde sein. Die Rolle der Anwender ist für das Scrum Team von besonderer Bedeutung, denn nur sie können das Produkt aus der Perspektive des Nutzers beurteilen. Anwender und Kunden sollten beim Sprint Review und bei der Aktualisierung des Product Backlogs hinzugezogen werden, um das Produkt zu erproben und Feedback zu geben.
Dem Management wird die Verantwortung zugeschrieben, dafür zu sorgen, dass die Rahmenbedingungen stimmen. Dazu gehört die Bereitstellung der erforderlichen Arbeitsmittel, aber auch generell die Unterstützung für den eingeschlagenen Kurs. Das Management ist dafür verantwortlich, das Scrum-Team vor externen Arbeitsanforderungen zu schützen, passende personelle Besetzungen zu finden sowie dem Scrum Master dabei behilflich zu sein, Hindernisse auszuräumen.
Oft sind „agile“ Softwareprojekte nur hybride Formen des „Wasserfallmodells“.
Man kann die Scrum-Regeln sehr bürokratisch und kleinteilig handhaben. Dadurch würden allerdings die behaupteten Vorteile der Methode, insbesondere ihre größere Flexibilität und ständige Rückkopplung mit den Anforderungen der Kunden und Anwender verfehlt. Die Methode versteht sich eher als eine Art spirituelles Konzept, das durch akribische Überwachung seiner Regeln konterkariert würde.
Auch kann man das Product Backlog mit technischen Problemen überfrachten oder durch von außen kommende Terminsetzungen „aus dem Takt“ bringen.
In vielen Firmen werden die Regeln nicht in der nach der reinen Lehre vorgesehenen Form umgesetzt. In diesen Fällen ist es wichtig, die veränderten Regeln festzuhalten und allen Beteiligten zu kommunizieren und sicherzustellen, dass die Regeln nicht im Widerspruch zur Scrum-Methodik stehen.
In der Praxis erhalten die Product Owner häufig nicht die Vollmacht, die notwendigen Entscheidungen verbindlich zu treffen – abweichend von der Rollenkompetenz, die in Scrum eigentlich vorgesehen ist. Häufig werden Product Owner auch mit fremden Aufgaben überlastet.
Team-Mitglieder haben bisweilen Schwierigkeiten, die interdisziplinären Anforderungen zu akzeptieren. Dahinter steht jedoch der Gedanke, dass ein interdisziplinär ausgerichtetes Team den Unwägbarkeiten eines Projektes wesentlich besser gewachsen ist als eine Sammlung individueller Talente. Beispielsweise können Aufgaben bei Schwierigkeiten leichter geteilt oder übernommen werden. Fällt jemand aus, geht man davon aus, dass ein interdisziplinäres Team besser in der Lage ist, die fehlende Expertise zu kompensieren.
Die Verständigung mit den Stakeholdern ist ein weiteres Problemfeld, oft dadurch befördert, dass die Regeln der Arbeitsweise zumindest den Stakeholdern nicht (hinreichend) bekannt sind. Der Kontakt zur Kundschaft oder zu den Anwendern droht dann zum Störfeuer der Projektarbeit zu werden. Es bleibt ein Stück hohe Kunst, diesen Rückkopplungsprozess konstruktiv für die Projektarbeit zu organisieren.
Durch Software unterstützte Projektplanung bedeutet auch immer die Möglichkeit zu einer Überwachung der einzelnen Arbeitsschritte. Deshalb empfiehlt sich der Abschluss einer Betriebsvereinbarung.
Zunächst sollte sich das Unternehmen entscheiden,
Auf der Basis dieser Informationen lässt sich dann der Entwurf für eine Betriebsvereinbarung erstellen.
 |
Karl Schmitz, Dezember 2020 |
 tse Hamburg | 388 / 287 |