Informationen zu Scrum und Tipps für den Einstieg

Viele denken, Scrum und Agile seien dasselbe, da sich bei Scrum alles um kontinuierliche Verbesserungen dreht – eines der Kernprinzipien von Agile. Jedoch handelt es sich bei Scrum um ein Framework zur Bewältigung von Aufgaben, während Agile eine Philosophie beschreibt. Bei der Philosophie von Agile ist der Fokus auf eine kontinuierliche und schrittweise Verbesserung durch kleine und regelmäßige Releases gelegt. Man kann als Einzelner nicht wirklich "agil werden". Die Hingabe des gesamten Teams ist nötig, um einen neuen Denkansatz zur Wertschöpfung für den Kunden zu finden. Doch ein Framework wie Scrum kann euch helfen, diese neue Denkweise zu verfolgen und die tägliche Kommunikation sowie die täglichen Aufgaben auf Agile-Grundsätze auszurichten.

Worin der Unterschied zwischen Agile und der Definition von Scrum liegt, kannst du im Scrum-Leitfaden und im Agile Manifest nachlesen. Im Agile Manifest werden vier Werte erläutert:

• Individuen und Interaktionen haben Vorrang vor Prozessen und Tools.
• Funktionierende Software hat Vorrang vor umfassender Dokumentation
• Die Zusammenarbeit mit den Kunden hat Vorrang vor Vertragsverhandlungen
• Reagieren auf Veränderungen hat Vorrang vor dem Befolgen eines Plans.

Die Definition von Scrum beruht auf Empirismus und der Lean-Denkweise. Empirismus steht dafür, dass Wissen mit Erfahrung einhergeht und Entscheidungen auf Grundlage von Beobachtungen getroffen werden. Durch die Lean-Denkweise konzentriert man sich verstärkt auf das Wesentliche, während unwichtiges wegfällt. Scrum ist ein heuristisches Framework, denn es basiert auf kontinuierlichem Lernen und einer stetigen Anpassung an sich ändernde Faktoren. Es berücksichtigt, dass Teams zu Beginn eines Projekts noch nicht alles wissen können und sich erst durch Erfahrung weiterentwickeln. Scrum ist so aufgebaut, dass sich Teams neuen Bedingungen und Benutzeranforderungen ganz von selbst anpassen können. Durch den flexiblen Prozess, der das Festlegen neuer Prioritäten erlaubt, sowie kurze Release-Zyklen können Teams fortlaufend dazulernen und sich verbessern.

Scrum gibt zwar eine Struktur vor, ist jedoch kein völlig starres System. So kann die konkrete Umsetzung des Frameworks an die individuellen Anforderungen eines Unternehmens angepasst werden. Es gibt viele Theorien darüber, welche konkreten Arbeitsweisen Scrum-Teams zum Erfolg führen. Atlassian unterstützt agile Teams nun seit mehr als zehn Jahren bei der Bewältigung ihrer Aufgaben und wir haben die Erfahrung gemacht, dass eine klare Kommunikation, Transparenz sowie eine Hingabe für kontinuierliche Verbesserung stets im Mittelpunkt stehen sollten, gleich welches Framework ihr nutzt. Alles andere bleibt euch überlassen.

• Das Produkt-Backlog ist die Hauptliste mit den zu erledigenden Aufgaben. Sie wird vom Product Owner oder Produktmanager verwaltet. Diese dynamische Liste von Features, Anforderungen, Verbesserungen und Fehlerbehebungen fließt in das Sprint-Backlog ein. Das ist im Grunde genommen die "To-do-Liste" des Teams. Auf das Produkt-Backlog wird fortlaufend zurückgegriffen und es wird ständig neu priorisiert. Die Verwaltung übernimmt der Product Owner, denn wenn wir Erkenntnisse gewinnen oder sich der Markt verändert, sind manche Aufgabenelemente womöglich nicht mehr relevant oder Probleme lassen sich auf andere Weise lösen.
• Unter dem Sprint-Backlog versteht man eine Liste an Elementen, User Storys oder Fehlerbehebungen, die ein Entwicklerteam zur Implementierung im aktuellen Sprint-Zyklus auswählt. Vor jedem Sprint entscheidet das Team im Sprint-Planungsmeeting (auf das wir später eingehen), an welchen Elementen aus dem Produkt-Backlog es in einem Sprint arbeiten will. Ein Sprint-Backlog kann flexibel sein und sich während eines Sprints weiterentwickeln. Das grundlegende Sprint-Ziel jedoch – d. h. was das Team mit dem aktuellen Sprint erreichen will – muss erfüllt werden.
• Inkrement (oder Sprint-Ziel) ist das nutzbare Endprodukt, das aus einem Sprint hervorgeht. Wir bei Atlassian präsentieren das "Inkrement" normalerweise bei einer Demo am Sprint-Ende, in der das Team zeigt, was es in dem Sprint zustande gebracht hat. Vielleicht habt ihr das Wort "Inkrement" noch nie gehört. Damit gemeint sind oft die Aufgaben, die ein Team erledigen will, ein Meilenstein, ein Sprint-Ziel oder gar eine Vollversion oder ein ausgeliefertes Epic. Das hängt ganz davon ab, was ein Team erreichen möchte und welche Sprint-Ziele es festgesetzt hat. Beispielsweise beschließen manche Teams, ihren Kunden am Ende jedes Sprints einen Release bereitzustellen. Ihr angestrebtes Ziel lautet also "ausliefern". Für andere Teams ist dieses Ziel womöglich unrealistisch. Nehmen wir an, ihr arbeitet an einem serverbasierten Produkt, das ihr nur einmal im Quartal an den Kunden ausliefern könnt. Trotzdem könnt ihr zweiwöchige Sprints festlegen und es euch zum Ziel setzen, bereits einen Teil der Version, die ihr am Schluss als Ganzes ausliefern wollt, abzuschließen. Doch je länger ein Software-Release dauert, umso höher ist das Risiko, dass die Software misslingt.

Wie ihr seht gibt es viele Varianten, selbst bei den Artefakten, die euer Team für sich bestimmen kann. Daher ist es wichtig, offen zu bleiben für die Entwicklung neuer Wege, auch die zur Handhabung eurer Artefakte. Vielleicht habt ihr euch ein Ziel gesetzt, das für euer Team stressige Korrekturarbeiten mit sich bringt. Dann müsst ihr einen Schritt zurückgehen und euer Ziel neu definieren.

Wir stellen euch die wichtigsten Zeremonien vor, die Scrum-Teams nutzen können:

1. Organisation des Backlogs: Für dieses Ereignis, das auch Backlog-Grooming genannt wird, ist der Product Owner verantwortlich. Der Product Owner ist vor allem dafür zuständig, dass das Produkt sich der Produktvision entsprechend entwickelt, und markt- und kundenbezogene Veränderungen zu verfolgen. Dazu führt er eine Liste, in der Feedback von Benutzern und dem Entwicklerteam eingetragen werden. So können Prioritäten festgelegt und die Übersicht bewahrt werden, damit eine Bearbeitung der Punkte zu gegebener Zeit möglich ist. Mehr über die sinnvolle Pflege eines Backlogs erfahrt ihr hier.

2. Sprintplanung: Bei diesem Meeting plant das gesamte Entwicklungsteam, welche Aufgaben während des aktuellen Sprints zu erledigen sind (Umfang). Dieses Meeting wird vom Scrum Master geleitet. Das Team entscheidet über das Sprintziel. Spezifische User Storys werden dann aus dem Produkt-Backlog zum Sprint hinzugefügt. Diese Storys sind immer in Einklang mit dem Ziel und müssen laut Einschätzung des Scrum-Teams realistisch sein (d. h., dass sie während des Sprints umgesetzt werden können).
   
   Am Ende des Meetings muss für alle Scrum-Mitglieder klar sein, was im Sprint erreicht werden kann und wie das Inkrement realisierbar ist.

3. Sprint: Ein Sprint ist der tatsächliche Zeitraum, in dem das Scrum-Team am Abschluss des Inkrements arbeitet. Typischerweise dauert ein Sprint zwei Wochen. Manche Teams finden einwöchige Sprints besser zu bewältigen und wieder andere legen einen Monat fest, um ein wichtiges Inkrement auszuliefern. Dave West von Scrum.org empfiehlt, Sprints umso schneller abzuschließen, je komplexer die Aufgaben und je mehr Unbekannte vorhanden sind. Doch das liegt ganz bei eurem Team. Wenn etwas nicht funktioniert, solltet ihr euch nicht davor scheuen, Änderungen vorzunehmen. In dieser Zeit kann der Umfang der Aufgaben wenn nötig gemeinsam von Product Owner und Entwicklerteam neu bestimmt werden. Das ist der Knackpunkt des erfahrungsbasierten Ansatzes von Scrum.
   
   Alle Ereignisse – von der Planung bis hin zur Retrospektive – finden während des Sprints statt. Wenn ein zeitlicher Rhythmus für einen Sprint festgelegt wurde, muss dieser über die gesamte Entwicklung hinweg beibehalten werden. So können Teams aus ihren Erfahrungen lernen und diese Erkenntnisse auf geplante Sprints anwenden.

4. Daily Scrum oder Stand-up-Meeting: Darunter versteht man ein tägliches, sehr kurzes Meeting, das praktischerweise immer zur selben Zeit (meist morgens) und am selben Ort stattfindet. Viele Teams wollen das Meeting auf 15 Minuten beschränken. Das soll jedoch nur zur Orientierung dienen. Man spricht auch von einem "täglichen Stand-up-Meeting", was verdeutlicht, dass die Besprechung wirklich nur sehr kurz sein sollte. Im Daily Scrum sollen alle Teammitglieder auf denselben Stand gebracht und auf das Sprint-Ziel ausgerichtet werden sowie einen Plan für die nächsten 24 Stunden erhalten.
   
   Das Stand-up-Meeting bietet Gelegenheit, Bedenken zu äußern, die beim Erreichen des Sprint-Ziels und bezüglich Hindernissen bestehen.
   
   Eine gängige Methode für Stand-up-Meetings sieht vor, dass jedes Teammitglied drei Fragen zum Erreichen des Sprint-Ziels beantwortet:
   
   • Was habe ich gestern gemacht?
   • Was will ich heute tun?
   • Gibt es irgendwelche Hindernisse?
   
   Wir haben jedoch beobachtet, dass viele schnell dazu neigen, einfach ihre Kalendereinträge für den gestrigen und den kommenden Tag vorzulesen. Der Grundgedanke hinter Stand-up-Meetings ist jedoch, dass ablenkende Gespräche auf ein tägliches Meeting beschränkt werden, damit das Team sich im weiteren Tagesverlauf auf seine Aufgaben konzentrieren kann. Wenn das Meeting also zum reinen Kalendervorlesen wird, scheut euch nicht, für Schwung zu sorgen und kreativ zu werden.

5. Sprint-Review: Am Ende des Sprints kommt das Team in einer informellen Sitzung zusammen, um sich eine Demo des Inkrements anzusehen oder das Inkrement unter die Lupe zu nehmen. Das Entwicklerteam präsentiert die Backlog-Elemente, die jetzt "Erledigt" und für Feedback von Stakeholdern und Teamkollegen freigegeben sind. Der Produktinhaber kann entscheiden, ob das Inkrement freigegeben wird, was in den meisten Fällen geschieht.
   
   In diesem Review-Meeting überarbeitet der Produktinhaber auch das Produkt-Backlog auf der Grundlage des aktuellen Sprints. Das Ergebnis kann dann in die nächste Sprintplanungssitzung einfließen. Im Falle eines einmonatigen Sprints solltest du deinen Sprint-Review auf maximal vier Stunden beschränken.

6. Sprint-Retrospektive: Bei einer Retrospektive dokumentiert und diskutiert das Team darüber, was in einem Sprint, einem Projekt, bei bestimmten Personen oder Beziehungen, bei Tools oder auch bestimmten Zeremonien funktioniert hat und was nicht. Das soll dem Team die Möglichkeit geben, sich nicht auf Misserfolge, sondern auf Erfolge zu konzentrieren und herauszustellen, was beim nächsten Mal besser laufen muss.