Was ist Scrum?
Vom Rugby-Sport ins Unternehmen: Der Begriff „Scrum“ kommt aus dem Englischen und bedeutet so viel wie „Gedränge“ oder „Gewühl“. Gemeint ist eine Rugby-Formation bei Standards, in der sich die Spieler beider Mannschaften Schulter an Schulter gegenüberstehen und versuchen, das gegnerische Team wegzuschieben, um den in der Mitte liegenden Ball zu sichern. Jedes Teammitglied trägt somit zum Teamerfolg bei. Die Anzahl der am Scrum teilnehmenden Spieler ist begrenzt. So nehmen nur die Spezialisten des Teams am Gedränge teil.
Hier soll es aber nicht um Rugby-Bälle, blutige Gesichter und Drop Goals gehen. Der Sport, namentlich Scrum, hat es ins Büro geschafft. Der Begriff wird für eine agile Projektmanagement-Framework verwendet, die zeigt, worauf es im Team ankommt: Flexibilität, Dynamik und Absprachen.
Die Scrum-Methode lebt von ihrem iterativen Prozess. Die Kurzfassung: Das Scrum-Team besteht aus Scrum Master, Product Owner und mehreren Entwicklern. Der Product Owner überblickt das Product Backlog mit all seinen Aufgaben, die im Entwicklungsprozess erledigt werden müssen. Diese Teilaufgaben führen die Entwickler in sogenannten Sprints durch. Das sind kurze, fest definierte Zeiträume von bis zu vier Wochen, in denen die Teilaufgaben umgesetzt, getestet und evaluiert werden. Der Scrum Master stellt einen möglichst reibungslosen Ablauf sowie die Einhaltung der Prozessregeln (Scrum Guide) sicher.
Im Vergleich zur klassischen Projektmanagement-Methode gibt es beispielsweise keine Projektphasen oder eine Projektleitung. Der Fokus liegt auf den kleinteiligen Sprints mit einem festen Zeithorizont.
Je nach Projekt und Branche macht die Anwendung von Scrum nicht immer Sinn. Anstatt die Methode zu ändern, wenden einige Unternehmen Scrum einfach angepasst an. Es entstehen Fehlpraktiken, Mythen, erdachte Geschichten. Ich habe die wichtigsten Scrum-Mythen zusammengestellt – und aufgeklärt!
1. Scrum ist wie die Wasserfall-Methode, nur besser
Dieser Mythos wird klarer, wenn die Unterschiede zwischen Scrum und Wasserfall genauer bekannt sind.
Das Wasserfallmodell war das klassische Projektmanagement der vergangenen Jahre. Ein Unternehmen sammelt zu Beginn alle Anforderungen und definiert diese möglichst bis ins kleinste Detail aus. Im Laufe des Projekts fließt jede Phase in die nächste, wie bei einem Wasserfall – daher kommt auch der Name der Methode. Die einzelnen Phasen haben klare Start- und Endpunkte, es gibt keine Möglichkeit, Phasen einzeln rückgängig zu machen. Das Projekt ist erst am Ende final abgeschlossen.
Im Gegensatz zum Wasserfall-Modell gibt es bei der Scrum-Methode neben einem langfristigen Plan mehrere Sprints, die zum finalen Produkt führen. Bei Scrum liegt der Fokus also eher auf der Entwicklung der Produktinkremente, nicht ausschließlich um das finale Produkt. Durch die kleinteilige Struktur ist die Scrum-Methode flexibler und weniger fehleranfällig.
Die hohe Planungssicherheit ist der größte Vorteil der Wasserfall-Methode. So werden auch umfangreiche Projekte zuverlässig durchgeführt. Auf der anderen Seite zeigen sich dadurch Fehler meist erst am Ende eines Projekts.
Die Scrum- ist demnach nicht besser, sondern schlichtweg anders als die Wasserfall-Methode – Mythos widerlegt! Für jedes Projekt muss im Vorfeld individuell entschieden werden, welche agile Methode die für die Ziele des Unternehmens passende ist.
2. Mit Scrum entfällt die Dokumentation
Aufgrund der kurzen Sprints wird häufig angenommen, dass eine Projekt-Dokumentation bei der Scrum-Methode nicht vonnöten sei. Im klassischen Projektmanagement liegt der Fokus in der Anfangsphase auf der strukturierten und detaillierten Dokumentation. Bei Scrum startet das Team mit der Lösungsentwicklung und dokumentiert, für einen besseren Überblick, während das Projekt entsteht. So schafft das Scrum-Team Transparenz über offene, anstehende und bearbeitete Aufgaben.
Durch die Dokumentation in Scrum lassen sich Projektschritte leichter nachvollziehen und Fehlerquellen schneller zurückverfolgen. Der Mythos ist also falsch. Egal für welche Methode sich das Team entscheidet, es wird immer dokumentiert. Bei dem einen Projekt früher und mehr, bei dem anderen später und weniger.
3. Mit Scrum arbeiten Teams schneller
Durch Scrum können Teams schneller auf Veränderung im Projekt reagieren und erhalten sich so die Flexibilität, die komplexe Aufgaben benötigen. Klar strukturierte Scrum-Events sorgen für Transparenz und optimieren die Kommunikation der am Projekt Beteiligten, die sich jederzeit Feedback einholen können. Dadurch lassen sich Probleme und Anpassungswünsche schneller erkennen und die Fertigstellung des Projekts rückt näher.
In puncto Schnelligkeit: Agilität bedeutet aber nicht automatisch höhere Effizienz. Diese ist eher als Nebeneffekt zu verstehen.
4. Scrum braucht keine Planung
Auch bei Scrum spielt die Planung eine zentrale Rolle. Allerdings gibt es dort keine längere Planungsphase im Vorfeld, mit der genau viele das Wort “Planung” definieren. Die Planung findet stattdessen größtenteils parallel zur Entwicklung statt.
Der Workflow sieht folgendermaßen aus:
Zu Beginn eines Sprints findet das sogenannte Sprint Planning statt. Nach der Festlegung eines Sprint-Ziels entscheidet das Team, wie es dieses erreichen möchte und „zieht“ sich die dafür benötigten Aufgaben (Product Backlog Items) in den kommenden Sprint-Plan, dem Sprint Backlog.
Der Mythos ist also falsch, wie allein schon der Begriff „Sprint Planning“ aussagt. Es gibt bei Scrum nicht den einen großen Plan, sondern einzelne Pläne für den jeweiligen Sprint. Diese ermöglichen eine Feedbackrunde nach jedem Sprint-Ende und das Team bleibt flexibel bei der Umsetzung.
5. Scrum ist nur für die Softwareentwicklung geeignet
Seinen Ursprung hat Scrum tatsächlich in der Softwareentwicklung. Die Methode funktioniert aber nicht nur in der IT, sondern lässt sich auch bei den unterschiedlichsten Projekten anwenden. Also überall dort, wo eine klare Produktvision erst nach und nach in der Entwicklungsphase weiterentwickelt wird.
Gerade die Werte von Scrum (Mut, Fokus, Offenheit, Respekt und Commitment) und die Flexibilität des Scrum-Frameworks finden überall Anwendung. Methoden-Bausteine wie die Retrospektive verbessern die Produktqualität, unabhängig von der Branche. Denn sie verbessert die Feedback-Kultur und fördert den transparenten Teamprozess. Unzählige Projekte beweisen: Scrum geht weit über die Softwareentwicklung hinaus.
6. Scrum bedeutet Meeting-Stress
Nach dem Scrum Guide hat jedes Scrum-Ereignis (Daily, Sprint Planning, Sprint Review und Retrospective) eine Maximaldauer und festgelegte Themenbereiche. In der Praxis sind die Meetings sogar oft kürzer als geplant, da nur die richtigen Personen zur richtigen Zeit teilnehmen. Die Folge: Die Meetings sind viel fokussierter – Effizienz ist das Zauberwort.
Mit der Scrum-Methode vermeidet das Team stressige Situationen durch unnötig in die Länge gezogene Meetings und arbeitet zielgerichtet und klar an den Zielen.
7. Mit Scrum kann man große Änderungen in letzter Sekunde umsetzen
Kurz vor dem Go-Live noch einige Änderungen im Entwicklungsprozess vornehmen zu können – davon träumt wohl jedes Management. Aber werden diese dann auch noch rechtzeitig umgesetzt?
Bei Scrum funktioniert das teilweise. Grundsätzlich können während eines Sprints zusätzliche Product Backlog Items aufgenommen und noch innerhalb der Sprintzeit umgesetzt werden. Das Scrum-Team wählt dafür die Items aus, die für den jeweiligen Sprint geeignet sind – also verständlich definiert und „ready“.
Kurzfristige große Änderungen entsprechen aber selten den Anforderungen von „ready”. Somit ist es bei Scrum nicht immer garantiert, dass kurzfristige Wünsche, exakt den Vorstellungen entsprechend umgesetzt werden können.
Fazit
Der größte Mythos ist zugleich Ursache für alle oben genannten Mythen: Scrum ist eine der am weitesten verbreiteten Projektmanagement-Methoden, Scrum geht immer.
Das ist jedoch so nicht richtig. Nicht für jedes Projekt, Unternehmen oder jede Branche ist die Scrum-Methode geeignet. Scrum muss passen und darf nicht passend gemacht werden! Ansonsten entstehen Missverständnisse und Fehlpraktiken, weil Teams zu sehr vom Scrum-Framework abweichen.
Je nach strategischen Zielen, Risiken, Komplexität der Projekte oder Kosten sollten Teams die passende Projektmanagement-Methode auswählen. Dafür braucht es das nötige Know-how über die verschiedenen Alternativen, eine ausreichende Aufklärung innerhalb des Teams und die Bereitschaft, Lehren zu ziehen und Methoden gegebenenfalls. zu wechseln.
