Das Scrum Framework - Wie du Produkte agil entwickeln kannst!
Überblick
Agiles Arbeiten ist heutzutage in aller Munde. In sehr vielen Unternehmen werden die eigenen Arbeitsweisen, die Vorgehensweisen der Projekte und sogar Organisationsstrukturen hinterfragt. Das eigenverantwortliche Arbeiten tritt immer mehr in den Vordergrund, genauso wie die starke Fokussierung auf den Kunden. Die Schnelllebigkeit des Marktes zwingt Unternehmen dazu ihre aufwändig hergestellten 5-Jahres-Pläne schneller zu verwerfen, als sie an Gültigkeit besaßen. Der Trend geht also weg von großen und langfristigen Plänen hin zu kürzeren und fokussierten Iterationen. In diesen Iterationen werden dann kleinere Ergebnisse produziert, diese werden dann aber unmittelbaren Feedbacks des Nutzers oder Kunden ausgesetzt. Durch dieses schnelle Feedback ist eine direkte Anpassung in der Produktentwicklung möglich.
Ein agiles Mindset, verschiedene agile Praktiken und Frameworks wie z.B. Scrum können Unternehmen dabei unterstützen flexibler und adaptiver zu werden. Durch die starke Einbindung des Kunden und das Einsetzen kleiner eigenverantwortlicher und crossfunktionaler Teams können Produkte entwickelt werden, die qualitativ hochwertig sind und Marktrelevanz aufweisen.
Das Scrum Framework
Scrum ist ein Framework für agile Produktentwicklung mit festen Rollen, vorgegebenen Meetings und bestimmten Arbeitsergebnissen (Artefakte genannt). Wenn ich in Projektmanagement-Trainings etwas über Scrum und agiles Arbeiten erzähle, sind viele Teilnehmer darüber verwundert, wie viel Struktur und Regeln beispielsweise Scrum vorgibt. Das ist auch eines der ersten Punkte, auf die ich hinweise. Agiles Arbeiten heißt nicht, dass nicht geplant wird und nur „Chaos“ herrscht (O-Ton aus dem Training), im Gegenteil: Es wird sehr viel geplant. Nur der Zeithorizont für den geplant wird, ist viel kürzer als im plangetriebenen Vorgehen (auch Wasserfallmodell genannt).
Scrum Framework – Eine Übersicht
Es gibt genau 3 Rollen im Scrum Framework (andere Rollen wie den Projektmanager kennt Scrum nicht):
Product Owner
Verantwortlich für das Produkt und für dessen Wertmaximierung
Verantwortlich für die Sortierung des Product Backlogs – entscheidet also an was als Nächstes gearbeitet wird
Scrum Master
Wächter der Scrum Regeln (deswegen auch die Pfeife :D)
Prozessverantwortlicher im Scrum Team
Development Team
Selbstorganisiertes und crossfunktionales Team
Umsetzer im Scrum Team
Bestehend aus 3-9 Leuten
Es gibt 5 timeboxed (wichtiges Element agilen Arbeitens) Events: Der Sprint
1-4 Wochen langer Zyklus
Container für alle anderen Events
Länge des Sprints wird anfangs festgelegt und bleibt in der Regel dann auch bestehen
Sprint Planning
Maximal 8 Stunden (bei einem 4-wöchigen Sprint) lange Planungssession
Bestehend aus 2 Teilen
Was wird im Sprint erarbeitet? – Der Product Owner stellt die wichtigsten Items (Anforderungen, Bug-fixes, Improvements usw.) vor und das Development Team zieht sich daraus eine gewisse Menge an Arbeit in den Sprint (Pull-Prinzip)
Wie wird es umgesetzt? – Das Development Team entwickelt einen Umsetzungsplan für die geplanten Items
Daily Scrum
Maximal 15-minütiges „Mini“-Meeting
Tägliche Synchronisation des Development Teams
Immer zur gleichen Zeit und am gleichen Ort
Sprint Review
Maximal 4-stündiges Meeting am Ende eines Sprints
Demo des fertigen Ergebnisses
Offenes Meeting mit Teilnahme verschiedener Stakeholder (z.B. Kunde)
Wichtiges Event für den Erhalt von Feedback auf das Produkt
Sprint Retrospektive
Maximal 3-stündiges Meeting am Ende eines Sprints
Fokus auf die Verbesserung der Zusammenarbeit des Teams
Vergleichbar mit einem Lessons Learned-Meeting
Das Ergebnis sollte mindestens ein mögliches Verbesserungs-To Do sein für den kommenden Sprint
Es gibt 3 Artefakte im Scrum Framework:
Product Backlog
Ständig priorisierte und endlose Aufgabenliste
Enthält alle anfallenden produktbezogenen Aufgaben (Product Backlog Items genannt)
Wichtigsten Items sind ganz oben, eher unwichtigere Items weiter unten
Sprint Backlog
Vorgenommene Arbeit für den kommenden Sprint
Auszug aus dem Product Backlog
Wird nach jedem Sprint wieder geleert
Gehört dem Development Team
Increment
Fertiggestelltes Sprintergebnis
Bestehend aus dem Ergebnis des aktuellen Sprints + der Ergebnisse aller vorherigen Sprints in integrierter Form
Anwachsendes Produkt – inkrementelle Entwicklung
Der Scrum Zyklus
Ich fange beim Erklären des Scrum Frameworks gerne bei dem Product Owner an. Denn der Product Owner sollte die Vision für das zu entwickelnde Produkt im Kopf haben. Bei komplexen Projekten und Problemstellungen ist es nicht möglich, den Scope/Inhalt im Voraus genau zu planen. Aus diesem Grund muss es so etwas wie einen Leitstern geben (Product Vision), damit die Ausrichtung der Produktentwicklung klar ist. Der Product Owner ist für das sogenannte Product Backlog verantwortlich.
Das Product Backlog ist eine ständig priorisierte Aufgabenliste, mit den wichtigsten Aufgaben (Items) ganz oben und den weniger Wichtigen weiter unten. Diese Liste an Aufgaben enthält alle Arbeiten, die für die Umsetzung des Produkts anfallen. Das Product Backlog ist eine endlose Liste, die sich kontinuierlich entwickelt und ständig angepasst wird, aufbauend auf den gewonnenen Erfahrungen.
Die zweite Rolle im Scrum Framework ist der Scrum Master. Er/sie ist für die Einhaltung der Scrum Regeln verantwortlich. Man könnte den Scrum Master als den Hüter der Prozesse und Regeln bezeichnen. Der Scrum Master ist im besten Fall ein guter Moderator und kann allen Beteiligten den Wert der Einhaltung der Regeln deutlich machen.
Das erste Scrum Event (Meeting) im Scrum Zyklus ist der Sprint selbst. Der Sprint ist quasi ein Container und beinhaltet alle anderen Scrum Events. Der Sprint hat eine feste Taktung (Sprintlänge), die anfangs festgelegt wird und dann bestehen bleibt. Die Sprintlänge ist dabei abhängig von Umfeld und Branche. Das heißt, dass sich kürzere Sprintlängen (1 oder 2 Wochen) bei z.B. Marketingfirmen anbieten und Längere (3 oder 4 Wochen) im z.B. SAP-Umfeld.
Das zweite Scrum Event im Scrum Framework ist das Sprint Planning. Auch dieses Event ist timeboxed und geht ganze 8 Stunden, bei einem 4-wöchigen Sprint. Wie schon gesagt ist das Planen auch im agilen Vorgehen ein essenzieller Bestandteil. Timeboxing wiederum ist ein wichtiges Instrument im agilen Arbeiten, da es auf der einen Seite den Druck erhöht zu einem bestimmten Zeitpunkt fertig zu sein und auf der anderen Seite den Fokus auf das Erreichen des eigentlichen Meeting-Ziels massiv erhöht. Schluss also mit den ewig langen Meetings, die ständig überzogen werden und kaum Mehrwert bieten. :)
Die Sprintplanung ist ein Scrum Event, welches am Anfang des Zyklus durchgeführt wird. Hier wird die Arbeit des gerade beginnenden Sprints geplant. Das gesamte Scrum Team nimmt hieran Teil und ist involviert. Die Sprintplanung besteht aus 2 Teilen:
Was wird im Sprint erarbeitet? Im ersten Teil stellt der Product Owner die kommenden Aufgaben/Items vor. Das Development Team (3. und letzte Scrum Rolle) zieht sich dann im Pull-Prinzip eine gewisse Menge Arbeit aus dem Product Backlog heraus. Es ist wichtig zu wissen, dass die Umsetzer der Aufgaben auch entscheiden, wie viel sie sich für den Sprint vornehmen. Auf die vorgenommene Menge „comittet“ sich dann das Team.
Wie wird es erarbeitet? Im zweiten Teil der Sprintplanung überlegt sich das Development Team wie genau die vorgenommen Items umgesetzt werden können. Dieser Umsetzungsplan kommt auch von den Umsetzern und wird nicht vorgegeben.
Das Development Team oder zu Deutsch Entwicklungsteam besteht aus 3-9 Entwicklern. Es ist ein selbstorganisiertes und crossfunktionales Team. Crossfunktional bedeutet, dass alle notwendigen Skills im Team vorhanden sind, sodass Abhängigkeiten nach Außen möglichst reduziert werden. Das Development Team ist das Umsetzungsteam des Scrum Teams und ist verantwortlich für das eigenverantwortliche Managen ihrer täglichen Arbeit. Deswegen gibt es auch eine tägliche Abstimmung namens Daily Scrum.
Das Daily Scrum ist eine 15-minütige tägliche Synchronisation des Development Teams. Das kurze Meeting findet jeden Tag zur gleichen Zeit und am gleichen Ort statt. Hier bespricht sich das Team für den Tag mit folgenden 3 Fragen:
Was habe ich gestern gemacht?
Was mache ich heute?
Gibt es Hindernisse oder Probleme für mich?
In dieser kurzen Abstimmung werden Hindernisse aufgezeigt, deren konkrete Lösung aber außerhalb des Dailys liegt, damit es auch kurz und knapp bleibt.
Am Ende des Sprints findet das 4. Scrum Event statt, die sogenannte Sprint Review. Diese ist bei einem 4-wöchigen Sprint maximal 4 Stunden lang. Hier wird das fertige Sprintergebnis, das sogenannte Increment, demonstriert und live vorgestellt. In diesem Demo-Meeting sind Personen außerhalb des Scrum Teams explizit gewünscht, sodass wertvolles Feedback gesammelt werden kann. Mit diesem Feedback wird dann das Product Backlog, wenn nötig, angepasst und justiert.
Das Scrum Artefakt lncrement, also das fertige Sprinterzeugnis, ist das integrierte Ergebnis aller schon durchgeführten Sprints plus des Ergebnisses des aktuellen Sprints. Wichtig zu verstehen ist, dass in Scrum inkrementell entwickelt wird, das heißt Stück für Stück.
Das letzte Scrum Event ist die Sprint Retrospektive. Diese ist bei einem 4-wöchigen Sprint maximal 3 Stunden lang. Im Gegensatz zur Sprint Review geht es nicht um das Produkt, sondern um die Zusammenarbeit des Scrum Teams. Die Verbesserung des gemeinsamen Arbeitens wird in diesem Meeting beleuchtet. Ziel ist es konkrete Maßnahmen zu entwickeln, um die Zusammenarbeit zu verbessern. Diese Maßnahmen oder auch Improvements genannt werden dann im Zuge der Sprintplanung eingeplant.
Hinweis:
Nach dem Sprint ist vor dem Sprint! Es gibt keine Pause zwischen 2 Sprints. Es geht nach Beendigung des Sprints praktisch am nächsten Tag ohne Übergang in den Nächsten.
Buchempfehlungen für das Scrum Framework
Wenn du noch tiefer in das Thema Scrum einsteigen möchtest, kann ich dir ein paar Buchempfehlungen mit auf den Weg geben:
[Falls Du dich mit den oben stehenden Links für eines der Produkte entscheiden solltest, erhalte Ich (ohne Mehrkosten für Dich) eine kleine Provision. Damit würdest Du mich und den Blog unterstützen.]
Comments