Scrum ist ein Projektmanagement-Ansatz, der beispielsweise innerhalb der agilen Softwareentwicklung zur Anwendung kommt. Das hehre Ziel von Entwicklern, die diese Arbeitsweise nutzen ist es, schnell und kostengünstig eine hochwertige Software zu generieren. Dabei setzt Scrum auf möglichst wenige statische Regeln, festgesetzte Pläne und Ziele.
Die Scrum-Methode ist zwar nicht neu, sie hat sich aber erst in den letzten Jahren durchgesetzt. Inzwischen löst sie immer mehr die Wasserfallmethode 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.
Der Anspruch von Scrum-Anwendern und ihr Konzept
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 das erklärte 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.
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.
Das Vorgehen: Vision, Product Backlog und Sprints
Statt umfassender Lasten- und Pflichtenhefte, erstellen Auftraggeber und -nehmer zu Beginn eines Scrum-Projekts eine Vision, das heißt 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. Es gehört zum Prozess, dass in der Praxis gelegentlich Sprints abgebrochen werden. 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. 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 so rasch Informationen zum aktuellen Stand des Projekts.
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. Oberste Maxime muss es sein, dass die Zusammenarbeit von allen Kollegen harmonisch und produktiv ist. Bei Störungen von außen sind die Projektbeteiligten zu schützen. Das kann der Fall sein, wenn zusätzliche Aufträge innerhalb wichtiger Phasen erledigt werden sollen. Dafür ist vom Scrum Master stets die Struktur der Arbeitstreffen zu überblicken. Wenn alles gut und routiniert läuft, kann dieser die Aufgaben eines Change Managers übernehmen. So begleitet er den Prozess bis zum Schluss, das heißt bis die Software dem Auftraggeber 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. 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 zum Beispiel auf flachen Hierarchien, verbunden mit einer offenen und ehrlichen Kommunikation. Die Beteiligten arbeiten selbstständig, kreativ und ergebnisorientiert.
3 Anmerkungen zur Praxis
Zum Einsatz einzelner Scrum-Bausteine in kleineren Projekten: Sobald eine gewisse Komplexität an Themen und Anzahl an Personen vorhanden ist, ist es nützlich, Scrum einzusetzen. Besonders praxistauglich in überschaubaren Projekten ist, dass schon der Einsatz einzelner Bausteine gewinnbringend ist
So kann Scrum beispielsweise innerhalb eines Entwicklerteams dazu genutzt werden, alle Aufgaben über ein Taskboard zu visualisieren und den Projektbeteiligten zuzuordnen.
Das gewährleistet stets einen guten Überblick darüber, wer was bearbeitet. Im Daily jeden Morgen können sich die Kollegen zusätzlich kurz in etwa einer halben Stunde über den Status austauschen und bei Bedarf auch Schwierigkeiten und Herausforderungen diskutieren. Das zeigt: Es braucht nicht immer die komplette Palette an Scrum-Techniken, sondern nur die, die einen echten Mehrwert liefern.
Auch die Kombination verschiedener Techniken ist mit Scrum möglich. Ein Vorteil von Scrum sind die vielen unterschiedlichen Techniken und Werkzeuge, die sich miteinander kombinieren lassen. In der Praxis lässt sich etwa erfolgreich die Technik des Planungspokers zum Schätzen von Anforderungen in Story Points - einer Maßeinheit zur Einschätzung des Gesamtaufwands - einsetzen. Schwierig wird es nur, wenn der Kunde ein anderes Verfahren nutzt, also etwa die Schätzung in Projekttagen. Dann müssen die Schätzungen zu einem Zeitpunkt X konsolidiert werden, um einen Überblick zum budgettechnischen Stand zu erhalten.
Zum Aspekt, Projekten nur einen äußerlichen Scrum-Anstrich zu geben, ist anzumerken: Scrum ist generell eine gute Methode, um in vergleichsweise kurzer Zeit die gesteckten Projektziele zu erreichen. Allerdings ist es wichtig, dass das Vorgehen nicht halbherzig betrieben wird, also nur, um nach Außen den Schein eines Scrum-Projekts zu wahren.
Es kommt darauf an, wie das Projekt grundsätzlich aufgezogen wird und dass Scrum konsequent umgesetzt wird. Wenn aber zum Beispiel klassische Fachkonzepte schon vollständig vorliegen oder die Entwickler die Umsetzung nach der Wasserfallmethode angehen, dann sollte diese Arbeitsweise maßgeblich sein. Nichtsdestotrotz sind kleinere Anpassungen an das jeweilige Haus und das Team und die oben beschriebenen Kombinationen bei einzelnen Techniken möglich und sinnvoll.
Scrum oder nicht Scrum?
Nachdem die Scrum-Basics (Konzept, Vorgehen, Akteure) ausführlich dargestellt und durch drei Anmerkungen aus der Praxis ergänzt wurden, bleibt die Frage: Welches Vorgehensmodell ist für die Aufgabenstellung, das Unternehmen/den Auftraggeber, das Team etc. am besten geeignet? Wann sollte die klassisches Wasserfallmethode und 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. Das sind 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.
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 im Vorteil.
Bevor ein neues Projekt aufgesetzt wird, lohnt es sich, sich über das passende Projektmanagement Gedanken zu machen und gegebenenfalls den Rat einer professionellen Projektmanagementberatung einzuholen, bevor eine Entscheidung zur Methode fällt. Denn die richtige Methode bestimmt den Projektverlauf und das Ergebnis maßgeblich mit.