Was ist Scrum?
Scrum ist eine Art der Organisation von Aufgaben und Teams, um Produkte zu entwickeln und Projekte zu managen. Es besteht aus drei Grundelementen: Rollen, Meetings und Werkzeuge.
Diese Methode (oder auch “Rahmenwerk”) kam Anfang der 2000er Jahr in der Softwareentwicklung auf. Bis dato genutzte Organisationsstrukturen mit starren Abläufen, festen Plänen und hierarchischen Teams passten nicht in die sich ständig verändernde Umwelt der Softwareentwicklung. Es wurde ein flexibler Workflow entwickelt, der neue Erkenntnisse laufend einarbeitet und durch permanentes Feedback der Auftraggeber:innen das Endprodukt stetig verfeinert.
Die Prinzipien und Abläufe wurden im Rahmen des Agilen Manifests als Scrum-Rahmenwerk niedergeschrieben. Kern des Scrum-Guide sind Prinzipien wie Transparenz, stetige Überprüfung und Anpassung im laufenden Prozess, sowie definierte Rollen und Abläufe innerhalb eines Projektes. In diesem Wiki-Artikel werden die Scrum-Basics beleuchtet, weiter unten sind Links zu ausführlichen Seiten verlinkt.
Rollen in Scrum
Im Scrum gibt es drei unterschiedliche Rollen: den Product Owner, den Scrum Master und den Entwickler, beziehungsweise das Entwicklungsteam. Der Product Owner legt das Produktziel fest und priorisiert die Aufgaben. Er ist es auch, der die Außenkommunikation übernimmt. Der Scrum Master stellt sicher, dass die Scrum-Prinzipien eingehalten werden, leitet die Meetings und ist Mediator zwischen den Teams und Mitarbeitern. Die eigentliche Arbeit am Produkt übernehmen die Entwickler in einem oder mehreren Entwicklungsteams.
Sprints und Meetings
Doch wie sieht Scrum im Daily Doing eigentlich aus? Dabei kommt man um folgende Stichpunkte nicht herum:
- Sprints
- Scrum-Meeting
- Review
- Retrospective
- Dailys
- Product Backlog Refinement
Zentraler Bestandteil neben den Rollen sind die sogenannten Sprints, in denen eine Abfolge von Meetings festgelegt ist. Ein Sprint ist eine definierte Zeiteinheit, das können Stunden, Tage oder Wochen sein, je nach Größe und Komplexität eines Projektes. In den Meetings wird über den Fortschritt gesprochen und Maßnahmen ergriffen, um das Projekt zu steuern und auf eventuell unvorhergesehene Ereignisse zu reagieren. In jedem Sprint wird ein Teilziel des Projektes erreicht, mehrere Sprints hintereinander führen schließlich zum fertigen Produkt oder zum Projektziel. Meetings werden vom Scrum-Master vorbereitet und geleitet, die Entwickler stellen ihre Fortschritte vor oder sprechen über Hindernisse, Probleme und Stolpersteine.
Zu Beginn einer Projektphase steht das Sprint Planning-Meeting, in dem das Projekt in einzelne Bestandteile heruntergebrochen und Aufgaben definiert werden. Hier werden auch die Länge und die Anzahl der Sprints festgelegt.
Im Daily Scrum wird jeden Tag in etwa 15 Minuten innerhalb des Entwicklerteams besprochen, welcher Fortschritt erzielt wurde und welche Aufgaben anstehen. Dieses Meeting findet in der Regel ohne den Scrum Master statt.
Am Ende eines Sprints steht das Review, in dem die erzielten Ergebnisse präsentiert werden. Hier kann das Produkt vom Product Owner und einem möglichen Auftraggeber begutachtet werden, Feedback wird gegeben und entweder wird der Teils als abgeschlossen gekennzeichnet oder es geht in die Optimierung. Es ist möglich, dass einzelne Teile eines Projektes Produkte sind, die in irgendeiner Form bereits genutzt oder verkauft werden. In den folgenden Sprints werden dann Features erarbeitet und Bugs behoben.
Im Sprint Retrospective reflektieren alle Beteiligten über den Prozess und identifizieren Verbesserungsmöglichkeiten, insbesondere in der Organisation und im Ablauf. Auch dieses Meeting findet regelmäßig am Ende eines Sprints statt.
Eine weitere Meeting-Art ist das Product Backlog Refinement. Dies ist das einzige aller Scrum Meetings, das keiner Struktur folgt. Es ist ein direkter Austausch von Product Owner und Entwickler, um bestimmte Anfragen und Ideen bereits im Vorfeld eines Meetings oder auch “on the run” anzusprechen und abzuklären.
Scrum Organisation
Der Ablauf eines Projektes im Scrum ist nicht nur zeitlich und personell organisiert, sondern ist bis auf jede in sich geschlossene Aufgabe unterteilt. Dies dient der Übersicht, der Priorisierung und dem Abschätzen des Zeitaufwandes und den damit einhergehenden (zeitgebundenen) Kosten. Über allem steht das Product Backlog, eine Art Board, auf dem die verschiedenen Aufgaben (Items) analog zu Haftnotizen eingetragen sind. Auf dem Board können die Items je nach Bearbeitungsstand verschoben werden. Im Sprint Backlog werden die Aufgaben für den aktuellen Sprint “gezogen” und verteilt. Hier entscheidet das Entwicklungsteam gemeinsam mit dem Product Owner, welche Items umgesetzt werden. Im Sprint Review wird über den Fortschritt gesprochen, über Aufgaben, die eventuell mehr Ressourcen benötigen als geplant.
Das Product Backlog dient als zentraler Speicher für alle anstehenden Aufgaben und Ideen eines Projekts oder Produkts. Der Product Owner ist dafür verantwortlich, es zu pflegen und zu priorisieren, oft in einem digitalen Board, das für das Team und Stakeholder einsehbar ist. Hier können “Karten” von einer Spalte in eine andere verschoben werden, zum Beispiel von “ToDo” zu “In Progress” oder zu “Warte auf Feedback”. So können alle Beteiligten den Stand einer bestimmten Aufgabe verfolgen.
Product Backlog Items sind die einzelnen Einträge im Backlog. Sie können User Stories, Features oder Epics sein, die den erwarteten Kundennutzen, den Mehrwert für das Unternehmen und Messgrößen enthalten. Jedes Item hat auch Akzeptanzkriterien, die erfüllt sein müssen, sowie Abhaklisten und ein Verzeichnis der verantwortlichen und beteiligten Mitarbeiter:innen.
Neben dem Backlog und seinen Items brauchen die Items noch ein paar weitere Merkmale.
Die Definition of Ready (DoR) legt fest, wann eine Aufgabe bereit ist, bearbeitet zu werden, während die Definition of Done (DoD) beschreibt, wann eine Aufgabe als erledigt gilt. Das Produkt Inkrement sind die während eines Sprints erzielten Arbeitsergebnisse, die im Review vorgestellt und besprochen werden. Wird eine Aufgabe nicht wie geplant in einem Sprint fertig gestellt, rückt das Item zurück auf das Backlog und wird zum nächsten Sprint erneut besprochen, eventuell mit angepassten Zielen, Teilzielen und Anforderungen, sodass es im nächsten Sprint bearbeitet werden kann.
Zu Beginn des Projektes, wenn das Backlog erstellt und die Items definiert werden, wird auch eine Schätzung erstellt, wie aufwändig ein Item ist. So können die Teams Story Points verwenden und diese im Planning Poker auf die Aufgaben verteilen, um den Aufwand von Aufgaben abzuschätzen und dem Product Owner ein Feedback zu geben.
Stärken und Schwächen von Scrum
Scrum fördert die Zusammenarbeit und bietet klare Strukturen für die Entwicklung von Produkten und Projekten. Der Prozess bietet Flexibilität und ermöglicht es Teams, sich und das Projekt kontinuierlich zu verbessern. Die regelmäßigen Meetings und Reviews helfen, den Fortschritt zu überwachen und Hindernisse frühzeitig zu identifizieren, eventuell sogar Zielanpassungen im laufenden Prozess vorzunehmen. Insgesamt schafft Scrum Transparenz und fördert eine iterative Vorgehensweise, die es Teams ermöglicht, sich an veränderte Anforderungen anzupassen und maßgeschneiderte, stets Produkte zu liefern. Allerdings erfordert die erfolgreiche Anwendung von Scrum gut organisierte Teams und eine konsequente Umsetzung der Prinzipien, sowie eine gute Kommunikationsfähigkeit der Teamleader, Product Owner und Scrum Master. Sehr gute Soft Skills sind hier ebenso wichtig und förderlich wie Fachkenntnisse. Zudem kann die Komplexität der Implementierung eine Herausforderung darstellen, insbesondere in größeren Organisationen. Auch muss das System konsequent umgesetzt und verfolgt werden.
Quellen:
https://digitaleneuordnung.de/blog/scrum-methode/
https://www.scrum.org/
https://www.scrumstudy.com/whyscrum/scrum-principles
https://digitaleneuordnung.de/blog/agiles-manifest/