Scrum im Selbststudium – Teil 3: Warum ist die regelmäßige Überprüfung und Anpassung erfolgversprechender als Vorabanalyse und detaillierte Planung?

Willkommen zum 3. Teil der „Scrum im Selbststudium“-Artikelreihe. Die Übersicht zu allen Teilen findest du am Ende dieses Beitrags.

Starten wir von Anfang an:

Was ist Scrum?

Der Scrum Guide definiert Scrum folgendermaßen:

„Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.“ – Scrum Guide, 2020

Diese Definition verwendet die abstrakten Begriffe „komplexes Problem“, „adaptive Lösungen“ und „leichtgewichtiges Rahmenwerk“. Hinter diesen Begriffen verbergen sich die Antworten auf die Fragen:

• Wann sollte Scrum eingesetzt werden?
• Warum funktioniert Scrum?
• Wie funktioniert Scrum?

Um zu beantworten, was Scrum ist, werden wir uns von diesen drei Fragen leiten lassen.

Wir beginnen mit der ersten Frage:

Die Lösung von komplexen Problemen profitiert von Scrum

Jede Produktentwicklung beginnt mit einer Idee. Traditionell gleicht dann der Weg zum Endprodukt einem stufenartigen Vorgehen. Da Informationen oder Entwicklungsarbeiten sozusagen von einer Stufe zur nächsten Stufe fließen, wird dieses Vorgehen auch als Wasserfall bezeichnet.

Die Stufen im Detail:

• Es beginnt damit, dass ein Produktmanager die Verantwortung für die Umsetzung der Idee übernimmt. Er führt Marktanalysen durch, beauftragt Machbarkeitsstudien, erstellt einen groben Anforderungskatalog, setzt eine Budgetgrenze und legt Meilensteine der Entwicklung fest.
• Auf der nächsten Stufe wird für die Umsetzung ein Entwicklungsprojekt ins Leben gerufen. Die Verantwortung für den Erfolg dieses Projekts übernimmt ein Projektmanager. Er wird mit der Aufgabe betreut, alle Aufgaben in der Entwicklung zu verwalten und zu koordinieren.
• Mit der Hilfe von Requirement Engineers oder Business-Analysten sammelt er alle Anforderungen im Detail, die an das Produkt gestellt werden, und erstellt einen Projektplan.
• Nachdem auf der letzten Stufe die Anforderungen hinreichend geklärt wurden, ergänzt ein Solution-Architekt den Plan um das Design einer technischen Realisierung. Dabei wird auch über die zu verwendenden Technologien bei der Umsetzung entschieden.
• Der Projektplan enthält nun neben den detaillierten Anforderungen an das Produkt auch die Details zur technischen Implementierung. Auf Basis dieses Projektplans legen Produktmanager und Projektleiter fest, wie lang die Entwicklung dauern darf und welches Budget notwendig ist.
• Die Umsetzungsstufe besteht daraus, dass der Projektmanager um Ressourcen bei der Leitung der Entwicklungsabteilung bittet und ein Team von Entwicklern zusammenstellt, das unter der Vorgabe des Architekten die Lösung entwickelt.
• Die nächste Stufe gestaltet sich gleichermaßen, nur geht es diesmal nicht mehr um die Entwicklung, sondern um Tests und Qualitätssicherung.
• Entspricht das Produkt den Qualitätsstandards, wird es erstmalig an die Nutzer ausgeliefert. Sobald das Produkt von Nutzern verwendet wird, wird es einem anderen Team zur Wartung, zum Betrieb und für eventuellen Support übergeben. Wurden bis dahin die Budgetgrenze und der Liefertermin eingehalten, wurde das Entwicklungsprojekt erfolgreich abgeschlossen.

Dieses wasserfallartige Vorgehen bei der Entwicklung von Produkten funktioniert immer dann, wenn jeder Teil des Plans perfekt umgesetzt wurde und innerhalb des veranschlagten zeitlichen Rahmens für diese Stufe bleibt. Um das sicherzustellen, sollten während der Umsetzung keine Veränderungen an die Anforderungen oder in der Umgebung stattfinden. Dieses Vorgehen eignet sich für Problemstellungen bei Fachexperten, die Arbeiten bereits kennen und gut vorhersehen können, um sie im Projektplan festzulegen. Bei komplizierten Fragestellungen verspricht es hohe Qualitätsstandards und ermöglicht es, die Kosten bei der Produktion zu minimieren.

Allerdings sind heutzutage die Entwicklung und der Betrieb von Produkten in vielen Aspekten komplexer. Die Reaktion des Markts bei der Einführung des Produkts, die Interaktionen innerhalb eines Teams und auftretende technische Probleme sind nur einige von unzähligen Beispielen für diese Komplexität. Deshalb kann bei Produktentwicklung und Betrieb nicht mit Sicherheit vorhergesagt werden, was geschieht. Die starre Abarbeitung eines vorgegebenen Projektplans ignoriert diese Realität. Und die einmalige Veröffentlichung eines Produkts ist nicht mehr ausreichend, um die Nutzer lange zufriedenzustellen. Eine Software wie Windows 95, die im Jahr 1995 als benutzerfreundlich galt, begeistert heute, gut 25 Jahre nach ihrer Einführung, kaum noch Anwender. Das Verständnis von Nutzerfreundlichkeit hat sich mit der Zeit gewandelt. In einer solchen Situation ist es daher notwendig, regelmäßig Überprüfungen durchzuführen und Anpassungen am Produkt vorzunehmen, um die Nutzer langfristig zu begeistern.

Dies beantwortet die eingangs gestellte Frage: „Wann sollte Scrum eingesetzt werden?“
Die Antwort lautet: Immer dann, wenn es notwendig ist, regelmäßig den Fortschritt bei der Lösung eines Problems zu überprüfen, um gegebenenfalls Anpassungen an der Lösung vorzunehmen. Das folgende Beispiel wird diesen zentralen Punkt weiter verdeutlichen.

Warum sind die regelmäßige Überprüfung und Anpassung erfolgversprechender als Vorabanalyse und detaillierte Planung?

Das Thermostat-Gleichnis

Angenommen, du bist verantwortlich, den Raum deines Teams konstant auf 21 Grad zu halten. Der Raum bietet jedoch keine Möglichkeit, die Temperatur im Tagesverlauf abzulesen und anzupassen. Allerdings versichert uns der Facilitymanager, wenn wir ihm alle Parameter nennen, die die Temperatur beeinflussen, kann er das zentrale Heiz- und Kühlsystem so programmieren, dass die Temperatur des Raums während des Tages konstant 21 Grad beträgt.

Welche Parameter fallen dir ein? Die Anzahl der Menschen im Raum, die aktuelle Wettervorhersage, die Anzahl der geöffneten Fenster und die Aktivitäten der Menschen im Raum gehören auf jeden Fall dazu. Egal, wie lange du darüber nachdenkst, ich behaupte, du wirst niemals alle Parameter bestimmen können. Noch schlimmer: Der Wert eines Parameters kann sich auch im Tagesverlauf unvorhersehbar ändern. Denke nur daran, dass Menschen vielleicht unvorhergesehen den Raum früher verlassen müssen oder sich die Sonne doch nicht blicken lässt, obgleich es angekündigt war.

Offenbar ist dieser Ansatz nicht geeignet, um für angenehme Raumtemperatur zu sorgen.

Die einfache Lösung: ein Thermostat.

Ein Thermostat vergleicht die aktuelle Temperatur mit der Wunschtemperatur. In regelmäßigen Abständen berechnet das Thermostat die Differenz zwischen Ist- und Solltemperatur und reagiert entsprechend. Dadurch können alle Variablen ignoriert werden. Für die Regelung der Raumtemperatur mit einem Thermostat spielt es keine Rolle, ob jeder pünktlich erscheint, früher gehen muss oder die Wettervorhersage sich bewahrheitet.

Das Thermostat ist eine schöne Metapher. Es ermöglicht uns, die Ursache-Wirkungs-Beziehung zu ignorieren, indem es uns von allen Unbekannten entkoppelt und stattdessen eine Feedbackschleife einführt. Dieses Erfolgsprinzips können wir uns auch in der Produktentwicklung bedienen, wenn wir Scrum verwenden.

Anpassungsfähigkeit erreichen wir mit einem iterativen und inkrementellen Ansatz

Das Scrum-Rahmenwerk erkennt die Notwendigkeit an, regelmäßig den Fortschritt bei der Lösung eines Problems zu überprüfen, um Anpassungen an der Lösung vorzunehmen.

„Scrum verwendet einen iterativen, inkrementellen Ansatz zur Optimierung der Vorhersagbarkeit und zur Risikokontrolle.“ – Scrum Guide, 2020

Dieser iterative und inkrementelle Ansatz ermöglicht die Adaptivität der Lösung.

• Die Iterativität entsteht durch festgelegte Zeiträume, sogenannte Sprints, die nicht überschritten werden dürfen, bis es zur nächsten Überprüfung kommt.
• Inkrementell bedeutet, dass das Produkt schrittweise erweitert wird. Dabei bezeichnen wir mit dem Inkrement ein neues Stück, das innerhalb des Sprints gefertigt wurde und jetzt zum Produkt hinzugefügt werden kann.

„Jedes Increment ist additiv zu allen vorherigen Increments und gründlich geprüft, um sicherzustellen, dass sie alle zusammen funktionieren. Um einen Mehrwert zu erzielen, muss das Increment verwendbar sein.“ – Scrum Guide, 2020

Der letzte Satz ist hierbei entscheidend und macht den Unterschied zu einem wasserfallartigen Vorgehen aus. Sowohl in Scrum als auch im Wasserfall-Vorgehen wird die Arbeit in kleinere Bestandteile zerlegt, um sie beherrschbarer zu machen. Bei Entwicklung nach dem Wasserfall-Modell erfolgt die Zerlegung jedoch in Aktivitäten (Analyse, Lösungsdesign, Umsetzung, Test, Auslieferung) und in Scrum in neue funktionierende Versionen des Produkts. Würden die einzelnen Stufen im Wasserfall-Vorgehen als Inkremente aufgefasst, dann wären diese additiv zu allen vorherigen Stufen, aber keine dieser Stufen wäre für sich genommen durch einen Nutzer verwendbar.

Nur die wirkliche Verwendbarkeit des Inkrements kontrolliert das Risiko in der Produktentwicklung. Nur wenn die Nutzer die Lösung in ihren Händen halten, kann mit Sicherheit entschieden werden, ob die Lösung das Problem der Anwender zu ihrer Zufriedenheit löst.

Die Adaptivität der Lösung ist einer von zwei wesentlichen Unterschieden zum Wasserfall-Vorgehen. Der zweite ist die Teamstruktur eines Scrum-Teams:

• „Scrum setzt auf Personengruppen, die gemeinsam über alle Fähigkeiten und Fachkenntnisse verfügen, um die Arbeit zu erledigen und solche Fähigkeiten im Bedarfsfall zu teilen oder zu erwerben.“ – Scrum Guide, 2020
• „Das Scrum-Team ist umsetzungsverantwortlich (responsible) für alle produktbezogenen Aktivitäten.“ – Scrum Guide, 2020
• „Es ist von der Organisation so aufgebaut und befähigt, dass es seine Arbeit selbst steuert.“ – Scrum Guide, 2020

Das bedeutet, Scrum-Teams sind interdisziplinär, d. h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint mindestens ein Inkrement zu erstellen. Und Scrum-Teams managen ihre Arbeit selbst. Das heißt, sie entscheiden intern, wer was wann und wie macht. Dadurch passiert Folgendes:

„Das gesamte Scrum-Team ist ergebnisverantwortlich (accountable), in jedem Sprint ein wertvolles, nützliches Increment zu schaffen.“ – Scrum Guide, 2020

Dem Ansatz von interdisziplinären und sich selbst managenden Teams verdankt Scrum seinen Namen. Er bezieht sich auf die Arbeit „The New New Product Development Game“ von Hirotaka Takeuchi und Ikujirō Nonaka aus dem Jahr 1986. Die bemerkten, dass die Unternehmen Fuji Xerox, Honda und Canon besonders schnell auf Marktveränderungen reagierten. Im Unterschied zu anderen Unternehmen setzten sie dabei auf interdisziplinäre Teams, deren Mitglieder von Anfang bis Ende des Projekts zusammenarbeiteten. Der Prozess verlief dabei nicht wasserfallartig in festgelegten, stark strukturierten Phasen, sondern ergab sich aus dem Zusammenspiel der Teammitglieder. Wie beim Rugby wurde der Ball innerhalb der Mannschaft weitergegeben, während sie sich als Einheit auf dem Spielfeld bewegte. Im Rugby wird dies als Scrum bezeichnet, was sich Ken Schwaber und Dr. Jeff Sutherland zum Vorbild nahmen. Sie stellten Scrum zum ersten Mal im Jahr 1995 auf der OPPSLA-Konferenz in Austin, Texas, vor. Der erste Scrum Guide wurde im Jahr 2010 veröffentlicht. Seither wird er in regelmäßigen Abständen aktualisiert. Auf der offiziellen Seite des Scrum Guides findest du auch alle vergangenen Versionen und Übersetzungen des Scrum Guides.

Fazit: Das Thermostat und Scrum lösen komplexe Probleme adaptiv durch die Schaffung einer Feedbackschleife.
Im nächsten Teil beleuchten wir, warum sich empirische Ansätze zur Lösung komplexer Probleme bewährt haben.

Wenn du Fragen hast, schreibe sie gerne in die Kommentare hier im Blog oder auf unserem Colenet-Linkedin-Account.

Hier findest du alle Teile der Reihe „Scrum im Selbststudium“:

Teil 1: Agile Projekte sind erfolgreicher 

Teil 2: Scrum in 11 Schritten im Schnelldurchlauf erklärt

Teil 3: Warum ist die regelmäßige Überprüfung und Anpassung erfolgversprechender als Vorabanalyse und detaillierte Planung?

Teil 4: Zur Lösung komplexer Probleme hat sich ein empirischer Ansatz bewährt

Teil 5: Die Grundlage eines funktionierenden empirischen Prozesses ist Vertrauen

Teil 6: Die Scrum Artefakte stellen Transparenz her

Teil 7: Die mögliche Zukunft – Das Product-Backlog

Teil 8: Die Gegenwart – Das Sprint Backlog

Teil 9: Die Vergangenheit – Das Produkt-Inkrement

Teil 10: Scrum Events erlauben, die Artefakte zu überprüfen und anzupassen

Teil 11: Sprint – Erstellung eines Inkrements

Teil 12: Sprint Planning – Planung der Arbeit des Sprints

Teil 13: Daily Scrum – Tägliche Überprüfung des Fortschritts in Richtung des Sprint‐Ziels und Justierung der geplanten Arbeit

Teil 14: Sprint Review – Überprüfung der Sprint-Ergebnisse und weitere Planung

Teil 15: Sprint Retrospektive – Aus dem vergangenen Sprint lernen und Verbesserungen planen

Teil 16: Das Scrum-Team und seine Verantwortung

Teil 17: Der Product Owner maximiert den Wert des Produkts

Teil 18: Die Entwickler schaffen jeden Sprint ein nutzbares Inkrement

Teil 19: Der Scrum Master verantwortet die Effektivität des Scrum-Teams