Scrum – The Rules of the Game (Day 2)
Dezember 6, 2017
Aus dem Unterricht des CAS Mobile Business mit Ari Byland berichtet Andreas Unternährer.
Learnings Day 1
Zum Anfang haben wir den Vortag Revue passieren lassen und die wichtigsten Learnings gesammelt:
- Priorisierung Backlog ist wichtig
- Kompliziert vs. komplex: Bei komplexen Problemstellungen empfiehlt sich das iterative Vorgehen
- Disziplin ist wichtig, Regeln einhalten
- Visualisierung hilft den Fortschritt zu sehen
- Rollen: Product Owner, Scrum Master, Development Team
- Scrum kommt aus der Soft-Ware-Entwicklung
- Scrum Framework
- Mit Scrum kann Risiko minimiert und frühzeitig Wert generiert werden
Vertiefung Rollen
Es folgte ein etwas harter Einstieg in eine Gruppenarbeit, mit dem Ziel, die Rollen im Scrum abzutiefen. Dabei sind folgende Erkenntnisse zusammengetragen worden:
Der Product Owner ist Servant-Leader und nicht Assistent des Development Teams. Er definiert die Features und Funktionalitäten und verantwortet das Product Backlog. Er steht dem Development-Team wenn immer nötig zur Verfügung.
Das Development Team besteht aus 3 bis 9 crossfunktionalen Mitgliedern, die sich selber organisieren. Es gibt keinen Chef, der die Arbeit zuteilt. Das Team spricht sich ab, wer was übernimmt. Es werden in jedem Sprint Requirements definiert, Funktionalitäten designed, codiert und getestet.
Der Scrum Master führt das Scrum Team nicht inhaltlich, aber methodisch. Er schaut auf die Einhaltung von Regeln und unterstützt die Selbstorganisation des Teams sowie deren Produktivität. Er räumt Hindernisse aus dem Weg, die das Team nicht selber schafft und schaut, dass es optimale Bedingungen vorfindet.
Aus der Optik aller drei Rollen haben wir in drei Gruppen visualisiert, wie Scrum funktioniert:
Vertiefung Events
Auch die Events haben wir genauer betrachtet:
Der Sprint Planning Event hat zwei Hauptinhalte: Was können wir im nächsten Sprint liefern und wie können wir die Lieferung sicherstellen. Meistens findet es einen Tag nach dem Sprint Retrospective statt und das ganze Scrum Team nimmt daran teil. Der Product Owner gibt aus dem Product Backlog priorisierte Items in den Sprint. Das Team entscheidet, wie viel sie schaffen und das Sprint Backlog wird entsprechend angepasst.
Sprint Planning Event Flow:
Beim Daily Scrum trifft sich das Development Team ein Mal pro Tag für 15 Minuten. Es werden der Fortschritt bzgl. Zielerreichung und der Tagesplan kurz besprochen. Das Team entscheidet, was in den nächsten 24 Stunden geschieht. Der Product Owner ist nur situativ dabei und hat dann nur eine passive Rolle.
Im Sprint Review wird auf den letzten Sprint zurückgeschaut und beurteilt, ob die Lieferung der geforderten Qualität entspricht. Zu diesem Event lädt der Product Owner das ganze Scrum-Team und die Stakeholder ein. Er zeigt auf, was im Sprint erledigt wurde und was nicht. Das Development Team nutzt u.U. die Gelegenheit, eine Demoversion des Produktes zu zeigen. Die Stakeholder können Veränderungen der Marktsituation oder Präzisierungen einbringen. Als Resultat wird das Product Backlog angepasst.
Bei der Sprint Retrospective wird besprochen, was gut und was nicht gut gelaufen ist. Dabei wird der Scrum-Fortschritt, das Verhalten im Team, welche Tools im Einsatz sind, welche es braucht und die Klärung der Definition of Done diskutiert. Er findet i.d.R. einen Tag nach dem Sprint Review statt. Aufgrund der Diskussionen wird entschieden, ob bei den Methoden und Techniken etwas angepasst und ob die Definition of Done angehoben werden muss.
Pro Sprint und Event werden unterschiedliche Zeitdauern empfohlen:
Mastering Scrum
Weitere Themen, die bei Scrum ein wichtige Rolle spielen, sind Selbstorganisation, Cross-Functional und wer bzw. wie Hindernisse aus dem Weg geräumt werden können.
Produktive Selbstorganisation nutzt die Skills im Team zum Vorteil des Fortschrittes. Jeder bringt seine Stärken ein und durch Schwarmintelligenz oder die Dynamik der Herde wird die Richtung bestimmt.
Durch die multi-disziplinäre Zusammensetzung des Teams kommen die einzelnen Team-Mitglieder über ihr Spezialgebiet hinaus, da sie von den anderen Neues lernen. Jeder lernt dazu und kann vom Know-how des andern profitieren. Der Fokus verschiebt sich von der individuellen Pflichterfüllung zum Gesamterfolg des Teams.
Alles, was den Fortschritt des Teams behindert oder verlangsamt und nicht durch das Team aus der Welt geschaffen werden kann, sind Hindernisse, denen sich der Scrum Master annehmen muss.
Planung mit Scrum
Im Scrum wird ständig und fortlaufend geplant und nicht nur am Anfang. Es ist eine Aktivität und nicht bloss ein Dokument. Zudem dient die Planung nicht der Kontrolle sondern der Unterstützung der Veränderung.
Planungshorizonte:
Es werden zwei Typen von Release-Planung unterschieden: Date Target Planning (der Zeitpunkt der Auslieferung ist fix) vs. Feature Target Planning (der Umfang ist fix).
Fazit und Ausblick
Scrum und Agilität kann nicht einfach so eingeführt werden. Es bedeutet ein Kulturwandel, der vom Management initialisiert und unterstützt werden muss. Alte Organisationen scheitern an den bestehenden Strukturen und Hierarchien. Die Einführung gelingt i.d.R. nur Top-Down und Schritt für Schritt.