Scrum in der Praxis
Perfekt für unser kleines Team, auch wenn es nicht zu 100% Scrum ist [Erfahrungsbericht]
- 19. Januar 2024
Scrum ist in der Softwareentwicklung und agilen Projekten kaum mehr wegzudenken. Das Framework kommt in nahezu allen Softwareentwicklungs-Projekten zum Einsatz und hat die Art der Arbeit grundliegend verändert. In der Praxis driften die Arbeitsweisen jedoch von Unternehmen zu Unternehmen weit auseinander. Wir nutzen in unserem kleinen Team Scrum nun schon seit über 4 Jahren, daher wollen wir in diesem Blog-Beitrag unsere Erfahrungen teilen. Vielleicht helfen unsere Erfahrungen ja dem ein oder anderen Gründerteam, Scrum bei sich erfolgreich einzuführen.
Was ist Scrum?
Scrum ist ein Framework zur Entwicklung komplexer Produkte. Es wurde von Jeff Sutherland und Ken Schwaber seit den frühen 1990ern erfunden und seither fortlaufend weiterentwickelt. Softwarelösungen wurden in dieser Zeit immer umfangreicher und konventionelle Vorgehensweisen stießen bei der Produktentwicklung immer wieder an ihre Grenzen, da beispielsweise Feedback der Nutzer erst zu einem sehr späten Zeitpunkt einfließen konnte oder Anforderungen zu Beginn der Entwicklung noch nicht komplett bekannt waren und in späteren Projektphasen zu Problemen führten.
Zur Umsetzung von Scrum sind drei Rollen definiert:
Product Owner: Er ist für die Produktvision, die Ziele und die Anforderungen verantwortlich. Er ist meist Schnittstelle zu den Stakeholdern und stellt sicher, dass das Produkt den gewünschten Mehrwert für die Nutzenden erreicht.
Scrum Master: Er ist eine Art Coach und Schiedsrichter in einem. Der Scrum Master sorgt dafür, dass das Scrum-Framework eingehalten wird und unterstützt alle Teammitglieder dabei, Hindernisse bei Seite zu schaffen und gute Rahmenbedingungen für die Realisierung des Projektes zu schaffen.
Entwicklungsteam: Im Entwicklungsteam sollten alle Kompetenzen vertreten sein, um anstehenden Arbeiten zu absolvieren. Es ist für die Umsetzung der Anforderungen verantwortlich.
Diese drei Rollen treffen sich zu regelmäßigen Terminen und pflegen dabei sogenannte Artefakte.
Die Artefakte bilden Product-Backlog, Sprint-Backlog und Inkrement. Während die Backlogs meist in Form von Listen geführt werden, bildet das Inkrement den Teil des Produktes, der in einem Sprint fertiggestellt wurde. Das Produkt selbst ist somit wesentlicher Bestandteil des Ablaufs. Um das Produkt weiterzuentwickeln trifft sich das Team regelmäßig zum sogenannten Planning. Hierbei wird das Sprint-Ziel festgelegt und Anforderungen aus dem Backlog herausgegriffen, die für dieses Ziel notwendig sind und in einem Sprint erreichbar sind. Ein Sprint ist dabei ein ein bis vierwöchiger Zeitraum, an dem die Punkte aus dem Planning umgesetzt werden. Das Team trifft sich dabei täglich kurz, um Ergebnisse zu besprechen und nächste Schritte zu planen. Grundlage für diese Schritte bildet das Sprint-Backlog, das im Planning aus den Anforderungen entstanden ist. Darin haben die Entwickler die einzelnen Aufgaben definiert, die zur Erreichung der Anforderung notwendig sind.
Am Ende des Sprints sollte ein neues Produkt-Inkrement fertig sein und wird in einer Review im Team, aber auch mit Stakeholdern besprochen. Zuletzt reflektiert das Team in einer Retrospektive die vergangene Arbeit, sammelt unerledigte oder neu entstandene Aufgaben und definiert Maßnahmen, um die Zusammenarbeit zu verbessern. Durch all diese Maßnahmen entstehen regelmäßig testbare Zwischenergebnisse im Projekt und in der Regel wird ein Scrum-Team immer besser, je länger es zusammenarbeitet.
Häufige Irrtümer
Scrum wird oft als Alternative Wasserfall-, oder dem V-Modell gleichgesetzt. Hier gilt es vorsichtig zu sein, denn Scrum beschreibt lediglich die prinzipielle Arbeitsweise und gibt keine Vorgaben über Projektphasen und Reihenfolgen. So ist es z.B. möglich Scrum in das Wasserfall-Modell zu integrieren oder nur Teile des Projektes in Scrum umzusetzen. Wer Scrum nutzt, sollte sich also dennoch Gedanken darüber machen, welche Schritte für die Vervollständigung des Projektes notwendig sind und welches Vorgehensmodell dafür am besten geeignet ist.
Ein weiterer weit verbreiteter Irrtum ist, dass jedes Scrum Team automatisch auch agil ist. Zwar ist das in den meisten Fällen richtig und Scrum wurde mit der Intention entwickelt, agiles Arbeiten zu optimieren, aber es kann prinzipiell auch in konventionellen Projekten zum Einsatz kommen. Wir beispielsweise nutzen es auch für kleinere, konventionelle Projekte, um Arbeitspakete zu verteilen.
Wie fange ich am besten an?
Scrum ist relativ schnell zu verstehen. An sich ist dieser Blog kaum den langen Text wert, da sich Scrum in wenigen Sätzen komplett erklären lässt. Grundlage hierfür bildet der Scrum-Guide. Im Prinzip braucht man also nur die knapp 13 Seiten lesen und weiß die wichtigsten Grundzüge, um zu starten. Den Scrum-Guide solltet ihr also auf jeden Fall mindestens einmal lesen!
Bevor man das macht, empfehlen wir jedoch sich mit einem anderen Thema zu befassen: AGILITÄT. Glücklicherweise sind auch hier die wichtigsten Grundzüge kurz und prägnant in 4 Leitsätzen und 12 Prinzipien im Agilen Manifest zusammengefasst. (https://agilemanifesto.org/iso/de/manifesto.html) Das Agile Manifest ist ein Muss für alle, die wirklich agil arbeiten wollen.
Ansonsten ist Scrum einfach zu implementieren. Rollen definieren, Termine aufsetzen, Product Backlog füllen und los. Scrum ist so konzipiert, dass es immer auf Verbesserung bedacht ist. Es ist völlig normal, wenn die ersten Sprints etwas holprig laufen. In der Regel sind Anfangsschwierigkeiten nach wenigen Sprints beseitigt und das Team beginnt immer besser zusammenzuarbeiten. Wer die Möglichkeit hat, sollte natürlich mindestens ein erfahrenes Teammitglied haben, idealerweise einen Scrum-Master, der alle dabei unterstützt das Framework zu nutzen.
Scrum bei uns in der IT-Projektschmiede
„Wir nutzen Scrum!“ – Das sagt so ziemlich jedes Unternehmen heutzutage von sich. Bei genauerem hinsehen, stellt sich jedoch oft heraus, dass Scrum nur zu Teilen genutzt wird. Die Erfinder von Scrum sagen selbst, dass sie diese Abwandlungen nicht als Scrum bezeichnen würden. Beliebtester Punkt, der im Alltag nicht zur Anwendung kommt ist die Retrospektive. Schade, wie wir finden.
Aus unserer Sicht ist die Retrospektive ein sehr wertvoller Termin, bei dem Verbesserungspotenziale erkannt und Unstimmigkeiten schnell beseitigt werden können, bevor sie im weiteren Verlauf des Projektes zu größeren Problemen führen. Auch wir hatten am Anfang einige Vorbehalte gegenüber der Retrospektive – heute können wir uns nicht mehr vorstellen, wie es Ohne funktionieren soll. Selbst bzw. vor allem mit Kunden ist es von großem Mehrwert einen festen Raum zu haben, in dem man auch mal schlechter laufende Dinge ansprechen kann. Natürlich sollte alles konstruktiv bleiben und auch positive Dinge sollten in Retrospektiven angesprochen werden.
Zugegebenermaßen müssen wir uns beim Thema Scrum aber auch an die eigene Nase fassen, denn genaugenommen weichen auch wir vom klassischen Modell ab. Als kleines Team muss bei uns Product Owner und Scrum Master in einer Person gebündelt werden. Das hat bislang aber auch in dieser Konstellation immer gut funktioniert.
5 Tipps für Gründerteams
Abschließend noch ein paar Tipps, falls ihr bei euch im Gründerteam Scrum nutzen wollt:
- Mindestens ein Teammitglied sollte sich ausgiebig damit befassen und als Scrum Master fungieren
- Der Scrum Master kann mit der Zeit auch gerne mal durchwechseln. Das gibt oftmals neuen Schwung
- Sprecht mit anderen. Wie gesagt nutzt fast jedes Unternehmen Scrum und somit können sie euch den ein oder anderen Tipp mitgeben
- Lest wie in Kapitel 3 beschrieben zuerst das Agile Manifest und den Scrum-Guide. Oft braucht es gar keine langen Bücher oder Kurse. Das Wesentliche findet ihr darin
- Traut euch Termine zu Timeboxen. Meistens ist der Effekt der effektiveren Termine schon nach dem ersten Mal deutlich sichtbar