Scrum in der Softwareentwicklung in Theorie und Praxis

Ein Artikel von Dunja Koelwel | 27.02.2020 - 13:33

2001 wurden im sogenannten „Code-of-Ethics“ die Scrum-Werte unter den Stichwörtern Focus, Courage, Openess, Respect und Commitment festgehalten. Sie erläutern den Anspruch von Anwendern, stets schneller als mit anderen Techniken hervorragende Ergebnisse zu liefern. Außerdem wollen die Anwender im Team auch große Herausforderungen angehen, offen kommunizieren und das Gegenüber achten. Und am Ende ist erklärtes Ziel, die gemeinsam gesetzte Aufgabe zu erfüllen.

Um diesem Anspruch gerecht zu werden, setzt Scrum erstens auf das Herunterbrechen großer Projekte auf kleine Einheiten. Die zweite Devise ist die kontinuierliche und auf Erfahrung gestützte Verbesserung des Produkts während der Entwicklung. Konkret bedeutet dies: weniger Fokus auf das Endprodukt, sondern auf Zwischenergebnisse; weniger Bürokratie und Dokumentation, mehr Zeit und Raum für Innovationen. Björn Kibbel, Manager Development & Integration Services bei innobis, IT- und SAP-Dienstleister für Banken und andere Finanzdienstleister, erklärt dazu: „Durch die übersichtliche Projektorganisation, die stets transparenten, aber nicht überladenen Berichte und flexiblen Anpassungsmöglichkeiten während der Entwicklung, entfaltet sich in Scrum-Projekten eine besonders hohe Motivation bei allen Beteiligten.“

Bastian Siedek, Consultant bei Innobis,ergänzt: „Die Scrum-Methode ist zwar nicht neu, sie hat sich aber erst in den letzten Jahren durchgesetzt. Ich habe sie schon in meinem Studium vor über zehn Jahren kennengelernt. Inzwischen löst sie immer mehr die Wasserfall-Methode ab. Allerdings können beide Methoden auch kombiniert werden. Einzeltasks eines Projektabschnitts können in einem hybriden Modell in Arbeitsphasen – sogenannten Sprint Zyklen – bearbeitet werden.“

 
 

Das Vorgehen: Vision, Product Backlog und Sprints

Statt umfassender Lasten- und Pflichtenhefte, erstellen Auftraggeber und -nehmer zu Beginn eines Scrum-Projekts eine Vision, d. h. eine grobe Zielvorstellung. Diese ist kein komplexes Schriftstück, sondern steckt lediglich den Rahmen des Projekts ab. Darauf folgt ein Austausch über erste Details.

Sobald einzelne Elemente und Merkmale des Produkts geklärt sind, werden konkrete Anforderungen und Funktionalitäten abgeleitet, sortiert und priorisiert. So entsteht eine Liste – das sogenannte Product Backlog. Je weiter fortgeschritten das Projekt ist, desto spezifischer wird diese Liste.

In den einzelnen Arbeitsphasen, den bereits oben erwähnten Sprints, widmet sich das Entwicklungsteam fest abgesteckten Aufgaben. Sowohl das Zeitfenster als auch der Umfang der Aufgaben ist eng begrenzt. In der Praxis kommt es gelegentlich dazu, dass Sprints abgebrochen werden. Das gehört zum Prozess. Nicht immer ist vorher abzusehen wie sich die Entwicklung gestaltet. Und es kommt auch vor, dass sich die Vorstellungen des Auftraggebers ändern.

Wichtig ist in solchen Fällen ein souveräner Umgang mit der Situation. Nachdem die Aufgabe neu aufgesetzt ist, kann der nächste Sprint starten. Alle Aktivitäten werden im sogenannten Sprint Backlog festgehalten. Siedek ergänzt: „Im Sprint Backlog können sich Entwickler und Tester einen Überblick über die Teilaufgaben verschaffen, um das Sprint Ziel zu erreichen. Auch neue Mitglieder eines Scrum-Teams erhalten rasch Informationen zum aktuellen Stand des Projekts.“

 
 

„Die Scrum-Methode ist zwar nicht neu, sie hat sich aber erst in den letzten Jahren durchgesetzt. Inzwischen löst sie immer mehr die Wasserfall-Methode ab. Allerdings können beide Methoden auch kombiniert werden.“

Bastian Siedek, Consultant bei Innobis

Die Akteure: Product Owner, Scrum Master und das Entwicklungsteam

Scrum-Teams sind vorrangig in drei Rollen organisiert. Der Product Owner vertritt die Interessen des Kunden, des Auftraggebers und letztendlich der Nutzer (insgesamt also der Stakeholder). Er legt die Anforderungen fest und priorisiert die To-dos im Projektverlauf. Der Produktverantwortliche muss stets den Stand des Projekts kennen sowie Auslieferungszeitpunkte und Kosten im Blick behalten.

Der Scrum Master übernimmt dabei eine übergeordnete Funktion. Er implementiert bei den Projektbeteiligten die spezifischen Regeln und achtet auf deren Einhaltung. Kibbel erläutert: „Oberste Maxime ist es für mich, dass die Zusammenarbeit von allen Kollegen harmonisch und produktiv ist. Bei Störungen von außen schütze ich die Projektbeteiligten, z. B. wenn zusätzliche Aufträge innerhalb wichtiger Phasen erledigt werden sollen. Dafür muss ich stets die Struktur der Arbeitstreffen überblicken. Wenn alles gut und routiniert läuft, übernehme ich die Aufgaben eines Change Managers. So begleite ich den Prozess bis zum Schluss, d. h. bis die Software dem Kunden final übergeben ist.“

Die Entwicklungsteams zeichnen sich dadurch aus, dass sie hoch qualifiziert und bestenfalls interdisziplinär aufgestellt sind. Die Größe eines Entwicklungsteams variiert zwischen fünf und zehn Personen. Kibbel meint: „Wenn Scrum eingesetzt wird, fällt es besonders den Teams, die bereits eine ähnliche Unternehmenskultur gewöhnt sind, leicht, die Arbeitsweise zu antizipieren. Eine solche Kultur basiert z. B. auf flachen Hierarchien verbunden mit einer offenen und ehrlichen Kommunikation. Wir bei innobis nutzen Scrum auch deshalb, weil es widerspiegelt wie wir arbeiten – selbstständig, kreativ und ergebnisorientiert.“

 

Die Gretchenfrage: „Nun sag, Scrum oder nicht Scrum?“ Welches Vorgehen ist das richtige?

Nachdem die Scrum-Basics (Konzept, Vorgehen, Akteure) ausführlich dargestellt wurden und auch die Experten ihre Erfahrungen aus der Praxis ergänzt haben, bleibt die Frage: Welches Vorgehensmodell ist für die Aufgabenstellung, das Unternehmen/den Auftraggeber, das Team etc. am besten geeignet? Wann sollte die klassisches Wasserfall-Methode, wann eine agile Methode wie Scrum zum Einsatz kommen? Denn beide Varianten haben Vor- und Nachteile und ihre jeweiligen legitimen und sinnvollen Anwendungsbereiche.

Für eine klassische Methode – das sei noch einmal erwähnt – sprechen durchaus gewichtige Faktoren: in erster Linie die prioritäre Einhaltung des Budget- und Zeitrahmens, eine klare Definition von Zielen und Lösungen sowie eindeutige personelle Strukturen mit festen Verantwortungen. Wer Stabilität, Planbarkeit und straffe Richtlinien benötigt, ist hiermit gut beraten. Außerdem ist nicht zu unterschätzen, dass das technologische Risiko bei dieser bekannten und etablierten Methode gering ausfällt.

Dagegen sind drei Gründe für den Einsatz einer agilen Methode – vornehmlich Scrum als inkrementelles, iteratives und adaptives Vorgehen – anzuführen: Im Schnitt lässt sich eine bessere Softwarequalität bei kürzeren Einführungszeiten im Projekt und einer gleichzeitigen Risikominimierung erreichen. Wenn Scrum zum Projektziel passt, sich alle Beteiligten auf die Grundfesten der oben beschriebenen Scrum-Werte verständigt haben und ein Team mit individuellen, spezialisierten Skills besteht, laufen Scrum-Projekte ungemein erfolgreich. Im Vorteil gegenüber anderen Ansätzen wie dem klassischen Wasserfall-Vorgehen ist Scrum insbesondere in dynamischen Umfeldern mit häufigen Änderungen der Anforderungen, bei Nutzung innovativer Technologien und kurzen Planungszyklen.

Bevor ein neues Projekt aufgesetzt wird, lohnt es sich, sich über das passende Projektmanagement Gedanken zu machen und gegebenenfalls der Rat einer professionellen Projektmanagementberatung einzuholen ist, bevor eine Entscheidung zur Methode fällt. Denn die richtige Methode bestimmt den Projektverlauf und das Ergebnis maßgeblich mit.

Autor: Björn Kibbel, Manager Development & Integration Services bei Innobis