Was ist eigentlich Scrum?

Scrum ist ein Ansatz für Projektmanagement, der nach dem Agilen Manifest ausgerichtet ist. Das Agile Manifest ist eine Beschreibung der Grundwerte des agilen Projektmanagements:

• Individuen und ihre Interaktionen stehen über Prozessen und Werkzeugen
• Funktionierende Software steht über einer umfassenden Dokumentation
• Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung.
• Reagieren auf Veränderung steht über dem Befolgen eines Plans.

Scrum Methode & Prozess

Scrum basiert auf der Theorie empirischer Prozesssteuerung oder kurz “Empirie”. Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Basis des Bekannten getroffen werden. Scrum verfolgt einen iterativen, inkrementellen Ansatz, um Prognosesicherheit zu optimieren und Risiken zu kontrollieren.

Drei Säulen

Drei Säulen tragen jede empirische Prozesssteuerung: Transparenz, Überprüfung und Anpassung.

Transparenz

Transparenz erfordert, dass die Tasks nach einem gemeinsamen Standard definiert werden, damit die Betrachter ein gemeinsames Verständnis des Gesehenen teilen.

Überprüfung 

Scrum-Anwender müssen die Scrum-Artefakte und den Fortschritt regelmäßig in Bezug auf die Erreichung des Sprint-Ziels überprüfen, um Probleme und Abweichungen zu erkennen. Ihre Untersuchungen sollten nicht so häufig erfolgen, dass sie die Arbeit behindern.

Anpassung 

Wenn feststellt wird, dass die Ergebnisse von den akzeptablen Grenzwerten abweichen und dass das resultierende Produkt so nicht akzeptabel sein wird, muss das Team Anpassungen vornehmen.

Rollen im Scrum

Im Scrum unterscheidet man grundsätzlich zwischen:

• Rollen
• Aktivitäten
• Artefakte

Zunächst zu den Rollen:  

Product Owner

Er ist im ständigen Kontakt mit den Stakholdern, dem Entwicklungsteam und dem Scrum-Master. Der Product Owner ist für das Product Backlog verantwortlich. Es ist eine Auflistung aller Anforderungen und gewünschten Ziele, die das Produkt erfüllen soll und auch nach welcher Priorität.

Scrum Master

Der Scrum Master ist gleichzeitig Moderator, Unterstützer und Problemlöser. Er sorgt dafür, dass alle nach den Scrum Werten und Säulen handeln. Er hilft dem Team die Artefakte zu nutzen und sorgt dafür, dass die Scrum Events regelkonform und effektiv durchgeführt werden.

Das Entwicklerteam

Dieses Team ist die operative Einheit. Es ist selbst organisiert und cross-functional. Das bedeutet, dass das Team jede nötige Fähigkeit besitzt, um die geplanten Backlog-Elemente umzusetzen. Das Entwicklungsteam besteht optimaler Weise zwischen 3 bis 9 Personen. Scrum-Master und Product Owner zählen hier normalerweise nicht dazu, außer einer der beiden Rollen hat zusätzlich noch eine Entwickler-Funktion.

Weitere Rollen:

• Stakeholder- Sind die Auftraggeber des Produktes.
• Scrum-Mentor- Unterstützt den Scrum-Master und das Entwicklungsteam im ganzen Prozess

Events im Scrum

Sprint

Ein kurzer Entwicklungszyklus, in dem das Team potenziell auslieferungsfähige Produktfunktionalität erstellt. Sprints, dauern in der Regel zwischen einer und vier Wochen. Sprints können auch eintägig sein, aber nicht länger als vier Wochen dauern. die Sprint-Dauer kann sich im Verlauf des Projekts ändern, jedoch ändert sich hierdurch auch die Velocity.

Sprint Ziel

Das Sprint-Ziel ist ein übergeordneter Zweck für den Sprint, der durch die Implementierung der Product-Backlog-Einträge erreicht werden kann. Es gibt dem Entwicklungsteam Orientierung, warum sie dieses Produktinkrement bauen. Das Sprint-Ziel wird während des Sprint Planning festgelegt.

Das Sprint-Ziel bietet dem Entwicklungsteam eine gewisse Flexibilität in Bezug auf die im Sprint zu implementierender Funktionalität. Das Sprint-Ziel kann aber auch jedes andere verbindende Element sein, welches das Entwicklungsteam – statt in verschiedene Richtungen zu laufen – zur Zusammenarbeit motiviert.

Sprint Planning

Ein Meeting zu Beginn jedes Sprints, in dem sich das Scrum-Team auf ein Sprint-Ziel verpflichtet. Für dieses Meeting ist eine Time-box von 8 Stunden bei einem 4 Woche Sprint angesetzt. Bei kürzeren Sprints wird weniger Zeit benötigt. Außerdem werden gemeinsam die Anforderungen ermittelt, die dieses Ziel unterstützen und den Teil des Sprints werden, sowie die einzelnen Tasks, die für die Fertigstellung der jeweiligen Anforderungen erledigt werden müssen.

Daily Scrum

Ein 15-minütiges Koordinations- und Synchronisierungsmeeting, das täglich in einem Sprint abgehalten wird. die Mitglieder des Entwicklungsteams geben an, was sie am Vortag fertiggestellt haben, was sie am aktuellen Tag fertigstellen werden und ob ihnen irgendwelche Hindernisse im Weg stehen.

Sprint-Review

Ein Meeting am Ende jedes Sprints, das durch den Product Owner eingeleitet wird und in dem das Entwicklungsteam den Stakeholdern die im Sprint fertiggestellte, einsatzfähige Produktfunktionalität demonstriert. Hierfür ist eine Time-box von 4 Stunden vorgesehen. Bei kürzeren Sprints wird die Zeit dementsprechend angepasst.

Product-Increment

Die einsetzbare Produktfunktionalität, die den Stakeholdern am Ende des Sprints demonstriert wird und die potenziell an die Kunden ausgeliefert werden kann.

Sprint-Retroperspektive

Ein Meeting am Ende jedes Sprints, in dem das Team seine eigenen, individuellen Prozesse überprüft. Dabei geht es weniger um die Wahrnehmung des Teams, während des Sprints. Folgende Fragen könnten als Beispiel in der Retroperspektive gestellt werden:

• Was ist gut gelaufen? Was nicht?
• War ich über- oder unterfordert?
• Wie war die Zusammenarbeit im Team?
• Was lief weniger gut?
• Was lernen wir für die Zukunft daraus?
• Haben wir uns an den Scrum-Werten orientiert?
• Gibt es offene Fragen oder Anregungen?

Artefakte im Scrum

Product-Backlog/Refinement

Das Backlog ist eine Ansammlung von Anforderungen, die der Kunde (Stakeholder) sich für das Produkt wünscht und die er mit dem Product-Owner abgestimmt hat.

Um diese Ansammlung von Anforderungen zu priorisieren, bespricht und einigt sich der Product-Owner mit dem Entwicklungsteam im Refinement, welche Anforderung den höchsten Aufwand hat. Somit wird dann das Backlog priorisiert. Das Entwicklungsteam wird immer mit einbezogen. Im Scrum wird immer mit der höchsten Priorität begonnen. Der Scrum-Master unterstützt in der Regel die Verfeinerung des Product-Backlogs, damit die Gruppe fokussiert und aufgabenorientiert bleibt.

Sprint Backlog 

Das Sprint Backlog ist ebenfalls eine Liste. Es macht die Arbeit sichtbar, die das Entwickler-Team in einem Sprint erledigt. Es enthält alle Product Backlog Items, die in diesem Sprint bearbeitet werden und die dazugehörigen Tasks. Hier sind nun die an den höchsten priorisierten Aufgaben, die während des gesamten Sprints zu erledigen sind und regelmäßig während des Sprints im Daily-Scrum besprochen werden. Das Sprint Backlog wird während des Sprint Plannings erstellt. Neue Aufgaben können jederzeit während eines laufenden Sprints ergänzt werden.

Product-Roadmap

Eine Product Roadmap beschreibt über einen Zeitraum (meist ein Jahr) den Weg des Unternehmens, um die Vision Wirklichkeit werden zu lassen. Heißt also, es handelt sich um ein Dokument in welchem festgehalten ist, was in einem zukünftigen Zeitraum von der Produktentwicklung umgesetzt wird. Eine Roadmap soll die Ressourcen des Unternehmens geplant auf ein gemeinsames Ziel konzentrieren. Die Product Roadmap ist dabei ein strategisches Werkzeug für das Produktmanagement.

Release-Plan

Ein Releaseplan gibt die Features wieder, die im nächsten Sprint erarbeitet werden sollen, und gibt ein ungefähres Datum für das Release vor. Der Plan sollte die Verantwortlichkeiten, Ressourcen und Aktivitäten beinhalten, die für das Release benötigt werden.

Scrum ist auf die 12 agilen Prinzipien ausgerichtet. Diese Prinzipien bilden einen Satz von Richtlinien, die Projektteams bei der Implementierung agiler Projekte unterstützen. Die 12 Prinzipien findet ihr hier.

Vorteile von Scrum

Scrum hat gegenüber den klassischen Entwicklungsmethoden viele Vorteile.

Skalierbarkeit

Die Scrum Prozesse werden in verschiedenen Arbeitsperioden abgearbeitet. Dadurch kann sich das Team immer auf ein Feature konzentrieren. Dieses kann dann einfacher auf den Benutzer angepasst werden und das Team kann in Bezug auf Design, Umfang, Funktionalität einfacher und transparenter skalieren.

Erwartungen des Kunden erfüllen

Der Kunde kann seine Erwartungen festlegen und gibt den Wert an, den jede Anforderung an das Projekt mit sich bringt. Das Team kann diese dann einschätzen und der Product Owner legt seine Priorität fest. Dieser überprüft während des Sprints auch, ob die Anforderungen eingehalten werden und gibt dem Team Feedback.

Flexibel auf Änderungen reagieren

Auf Kundenwünsche und Marktentwicklungen kann schnell und flexibel reagiert werden. Durch die agile Arbeitsweise kann sich den wechselnden Anforderungen in Projekten angepasst werden.

Kürzere Markteinführungszeit

So kann der Kunde vor vollständiger Fertigstellung das Produkt bereits nutzen.

Höhere Software-Qualität

Durch die agile Arbeitsweise kann eine höhere Qualität der Software sichergestellt werden, da nach jeder Iteration eine funktionale Version ausgeliefert wird.