Skip to main content

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

March 8, 2023
Scaled Professional Scrum Master Training Simon Flossmann

Willkommen zum 3. Artikel der „Scrum im Selbststudium“-Artikelreihe. Solltest du den letzten Artikel verpasst haben, findest du ihn hier

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?“ 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.

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

Angenommen, du bist verantwortlich, den Raum deines Teams konstant auf 21 Grad zu halten. Der Raum besitzt kein Thermostat und auch 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. Er 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.

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.

Das Thermostat und Scrum lösen komplexe Probleme adaptiv durch die Schaffung einer Feedbackschleife.

Wenn du Fragen hast, schreibe sie in die Kommentare. Wenn der Artikel für dich hilfreich war, dann gib ihm einen Daumen nach oben. Morgen geht es weiter mit Teil 4: Zur Lösung komplexer Probleme hat sich ein empirischer Ansatz bewährt.

 


What did you think about this post?