Agil mit Scrum
Dezember 3, 2018
Aus dem Unterricht des CAS Mobile Business & Ecosystems mit Ari Byland berichtet Tobias Frana.
Um agil mit Scrum zu sein braucht es selbstorganisierte, offene Teams, damit im komplexen Umfeld der Softwareentwicklung die hohen Anforderungen des Business erfüllt werden können.
Ari Byland hat uns eingeladen, zwei Tage die agile Arbeitsmethode Scrum kennenzulernen. Viele Studierende waren interessiert, was der Unterschied zu herkömmlichen Methoden ist – wie zum Beispiel der Wasserfall-Methode.
Nach der kurzen Vorstellungsrunde von Ari forderte er uns auf, eine Achse im Klassenraum zu bilden. Bei der ersten Übung sollten wir uns entlang der Erfahrung von Software-Entwicklungsprojekten aufstellen. Ari hat uns auch gebeten miteinander zu sprechen, um zu erfahren, ob wir an der richtigen Stelle stehen. Die Achse verlief nicht ganz gerade, eher wie ein Wollegarn, welches sich an einem Ende verknotet hat. Aber das Ergebnis war klar. Nur wenige in der Klasse haben (viel) Erfahrung in Software-Projekten.
Die zweite Übung war sehr ähnlich. Wir wurden gefragt, wie viel Erfahrung wir mit Scrum haben. Das Ergebnis war sehr ähnlich wie bei der ersten Frage. Bei der dritten Übung stellten wir uns entlang der Wohndistanz zur HWZ auf. Die Achse wurde durchmischt und die Teilnehmer haben wieder miteinander gesprochen, wie weit weg sie von der HWZ wohnen.
Aber weshalb haben wir diese Übungen überhaupt durchgeführt? Wenn man Scrum kennt, ist die Antwort einfach. Scrum unterscheidet sich grundsätzlich zu anderen Methoden, in der Art, wie man miteinander arbeitet. Es gibt viele Checkpoints, wie beispielsweise das Daily Scrum. Dabei berichtet man seinen Arbeitskollegen regelmässig über den Fortschritt. Falls jemand Probleme bei der Umsetzung hat, kann dies direkt im Team besprochen werden. Dazu folgt später mehr in diesem Blog.
Erste Gruppenarbeit
Ari hat uns für die Einführung beauftragt, uns in Teams mit maximal 5 Teilnehmer aufzuteilen. Es sollten möglichst verschiedene Skills (technische und nicht-technische) vertreten sein. Der Auftrag war diesmal, ein Tier-Maskottchen für unser Team auszuwählen. Ausserdem sollten wir die Mehrwerte von Teamarbeit und drei Dinge aufschreiben, welche wir in der Klasse zum Thema Scrum lernen wollten.
Nun war es Zeit für eine nächste Übung. Wir erhielten eine kurze Einführung zur Case Study “Animal Website”. Danach hatten wir 30 Minuten Zeit, die Anforderungen für eine Website zu überprüfen. Nach der Gruppenarbeit hatten alle Teams Zeit, ihre Ergebnisse zu präsentieren. Ari stellte seine analoge Uhr auf dem Dozententisch auf und los ging es mit der Gruppenarbeit.
Die Teams besprachen die Anforderungen, begannen teilweise auch schon zu priorisieren. Nach etwa 15 Minuten erwähnte Ari, dass die Erwartung ist, dass man am Ende eine funktionierende Website zum gewählten Maskottchen präsentieren soll. Dies verursachte etwas Hektik im Klassenraum und die bis dahin strukturierte Arbeit wurde auf den Kopf gestellt. Ein Team hat einen Prototypen der Website in Powerpoint aufgebaut. Andere Teams haben sich bekannte Content Management Systeme wie WIX oder WordPress zu Hilfe genommen. Zum Schluss dieser Aufgabe haben die Teams die Ergebnisse präsentiert und im Nachgang ihre Erfahrungen ausgetauscht. Konkret wurde diskutiert, wie man vorgegangen ist, was gut lief und was eher nicht.
Nach dieser Gruppenübung legten wir mit dem Theorieblock zu agilen Arbeitsmethoden und konkret hiervon mit dem Scrum-Framework los. Die weiteren Gruppenarbeiten wurden dabei immer wieder zwischen die Theorieblöcke geschoben, was für die Aufnahme der vielen Theorie gut war.
Grundlagen von Scrum
Das agile Manifest
Mit dem agilen Manifest werden die Werte der agilen Softwareentwicklung festgehalten.
“Wir erschliessen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
- Individuen und 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
Das heisst, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.”
Die 12 Prinzipien
Die folgenden Prinzipien sind entsprechende Leitsätze für die agile Arbeit:
- Zufriedenstellung des Kunden durch frühe und kontinuierliche Auslieferung von wertvoller Software
- Agile Prozesse nutzen Veränderungen (selbst spät in der Entwicklung) zum Wettbewerbsvorteil des Kunden
- Lieferung von funktionierender Software in regelmässigen, bevorzugt kurzen Zeitspannen
- Nahezu tägliche Zusammenarbeit von Fachexperten und Entwicklern während des Projektes
- Bereitstellung des Umfeldes und der Unterstützung, welche von motivierten Individuen für die Aufgabenerfüllung benötigt wird
- Informationsübertragung nach Möglichkeit im Gespräch von Angesicht zu Angesicht
- Als wichtigstes Fortschittmass gilt die Funktionsfähigkeit der Software
- Einhalten eines gleichmässigen Arbeitstempos von Auftraggebern, Entwicklern und Benutzern für eine nachhaltige Entwicklung
- Ständiges Augenmerk auf technische Exzellenz und gutes Design
- Einfachheit ist essenziell
- Selbstorganisation der Teams bei Planung und Umsetzung
- Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Effizienzsteigerung
Komplexität von Software-Entwicklung
Um zu verstehen, weshalb gerade Scrum sich gut für Software-Entwicklungsprojekt eignet, kann das Stacey-Diagramm von Ralph Stacey beigezogen werden.
Das Stacey-Diagramm beinhaltet die zwei Achsen Anforderungen und Technologie. Software-Entwicklungsprojekte haben meist die Situation, dass die Technologie viele Herausforderungen bietet und die Anforderungen an die neue Lösung sehr gross sind. In diesem Fall bewegen wir uns im Bereich eines komplexen Umfelds. Das Unbekannte überwiegt in diesem Fall das Bekannte.
Folgende Unterscheidungen werden im Stacey-Diagramm abgebildet:
- Simple: everything is known
- Complicated: more is known than unknown
- Complex: more is unknown than known
- Chaotic: very little is known
Quelle: https://www.scrum.org/resources/scrum-framework-poster
Scrum aber rein auf Software-Entwicklungsprojekte zu reduzieren wäre falsch. Es gibt durchaus weitere Anwendungsbereiche, in welchem es angewendet werden kann:
- Forschung & Markt-Identifizierung
- Hardware
- Prozessentwicklung
- Verwaltung von organisatorischen Abläufen
- Marketing
Scrum: Begriffsklärung
Der Begriff Scrum stammt aus dem Mannschaftssport Rugby und formuliert das Gedränge der Mannschaft, welches zu Beginn einer Spielsituation durchgeführt wird.
Source: scrum.org
Scrum in a Nutshell
- Das Team plant innerhalb von 30 Tagen oder weniger eine funktionierende Software auszuliefern
- Das Team erstellt die Software
- Das Team präsentiert seine Arbeit, um Feedback dazu zu erhalten
- Das Team passt den Plan auf Basis des Feedbacks für den nächsten Zyklus an
Wiederholen…
Scrum Werte
Die folgenden fünf Punkte bilden die Scrum Werte:
- Mut
- Fokus
- Engagement
- Respekt
- Offenheit
Unterschied zu herkömmlichen Entwicklungsmethoden
Bei den traditionellen Entwicklungsmethoden wird ein strikter Plan verfolgt. Dabei erfolgt meist eine Analyse der Situation, es werden Konzepte geschrieben und neue Services designed, in die Entwicklung übergeben, getestet und schlussendlich ausgeliefert. Ein Feedback, ob die Entwicklung sinnvoll und gut war, stellt sich erst mit dem fertigen Produkt heraus.
Scrum verfolgt mit seinem iterativen Ansatz einen stetigen Prozess, mit denselben Disziplinen. Die Reihenfolge der einzelnen Aufgaben ist jedoch innerhalb einer Iteration frei. Zum Ende einer Iteration wird immer ein Produktinkrement bereitgestellt. Das Ergebnis ist, dass fortlaufend die Entwicklung des Produkts sichtbar ist und von Iteration zu Iteration nachgebessert werden kann.
Source: scrum.org
Vergleich der Wasserfall- und Scrum-Methode
Wie in der folgenden Grafik sichtbar ist, bietet Scrum insbesondere in den folgenden vier Punkten wesentliche Vorteile:
- Sichtbarkeit, da bei Scrum nach jedem Sprint ein Review durchgeführt wird und somit die Ergebnisse sichtbar sind
- Möglichkeit, Änderungen vorzunehmen, da auch hier nach jedem Review der nächste Sprint neu priorisiert werden kann
- Geschäftswert, da mit jedem Sprint ein funktionierendes Produkt Inkrement ausgeliefert wird, welches theoretisch releasefähig ist
- Risiko, da aufgrund der Sichtbarkeit Probleme früh erkannt werden und nicht erst am Schluss
Source: professionalscrum.ch
Das Scrum Framework
Drei Hauptelemente von Scrum
Rollen
- Product Owner
- Entwicklungsteam
- Scrum Master
Artefakte
- Product Backlog
- Sprint Backlog
- Increment
Events
- Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Die folgende Grafik zeigt den Scrum-Prozess-Flow:
Source: scrum.org
Product Owner
- Maximiert den Wert des Produkts
- Verwaltet das Product Backlog
- Wählt, was und wann freigegeben werden soll
- Repräsentiert Interessengruppen und Kunden gegenüber dem Entwicklungsteam
Entwicklungsteam
- Erstellt das Produkt Inkrement
- Funktioniert in einer Reihe von Sprints
- Organisiert sich selbst und seine Arbeit
- Arbeitet mit dem Product Owner zusammen, um den Wert zu maximieren
Scrum Master
- Fördert und unterstützt Scrum, so wie es im Scrum Guide definiert ist
- Hilft jedem, die Scrum-Theorie, Werte, Praktiken und Regeln zu verstehen
- Bietet Beratung und Unterstützung für das Scrum Team und die Organisation
Product Backlog
Product Backlog:
- Die einzige Quelle der Wahrheit über bestellte mögliche Änderungen am Produkt
- Minimal, aber ausreichend
- Eigentum und verwaltet durch den Product Owner
- Öffentlich, verfügbar und transparent
Product Backlog Item:
- Transparente Einheit der zu erbringenden Leistungen
- Angemessene Grösse
- Kann in einem einzigen Sprint abgeschlossen werden
- Jeder einzelne ist idealerweise diskret und ohne Abhängigkeiten
- Enthält klare Akzeptanzkriterien
- Antwort darauf, was wahr sein wird, wenn es funktioniert
Sprint Backlog
- Der Fortschritt innerhalb des Sprints muss transparent sein
- Eigentum und Leitung des Entwicklungsteams
- Prozessverbesserungen können sich auf das gesamte Scrum Team auswirken und sollten gemeinsam durchgeführt werden
- Vom Entwicklungsteam während des gesamten Sprints angepasst, wenn Arbeit entsteht
Increment
- Das Inkrement ist die Summe aller Product Backlog Elemente, die während des Sprints abgeschlossen wurden
- Das Produkt ist die Summe aller Inkremente
- Es ist verwendbar und es funktioniert
- Es ist potenziell releasefähig
- Es muss erledigt sein
- Gemäss den Standards des Scrum-Teams
- ohne, dass noch Arbeit übrig ist
Sprint
- Ein Gefäss für alle Aktivitäten und die anderen Scrum-Ereignisse
- Der Schwerpunkt liegt auf der Entwicklung von Aktivitäten
- Beginnt mit dem Sprint Planning
- Endet mit der Sprint Retrospective
- Dauert 30 Tage oder weniger, um ein regelmässiges Feedback zu ermöglichen
Sprint Planning
- Das Product Backlog wird überprüft
- Ein Sprintziel wird erstellt (warum)
- Das Sprint Backlog wird erstellt (was und wie)
- Das gesamte Scrum Team nimmt teil
Daily Scrum
- Das Daily Scrum bietet eine Gelegenheit für das Entwicklungsteam, den Fortschritt auf dem Weg zum Sprint-Ziel zu überprüfen
- Es wird ein Plan für die nächsten 24 Stunden erstellt
- Die Zusammenarbeit wird dabei optimiert
- Das Meeting dauert täglich 15 Minuten
- Es findet jeweils am gleichen Ort zur selben Zeit statt
Sprint Review
- Ein gemeinsames Meeting, um das Produkt-Inkrement anzusehen
- Das Scrum Team zeigt den Stakeholdern die Umsetzungen
- Die Anwesenden dürfen Feedback geben, was als Leitfaden für die nächsten Schritte dient
- Das Ziel ist, keine Folien, sondern funktionierende Software zu präsentieren
- Das Product Backlog wird mit den Erkenntnissen aus dem Sprint Review durch das Feedback der Teilnehmer aktualisiert
Sprint Retrospective
Das Scrum Team bespricht die folgenden Punkte:
- Was lief gut im Sprint?
- Was kann verbessert werden?
- Was verbessern wir im nächsten Sprint?
Weitere wichtige Elemente in Scrum
Timebox
Eines der weiteren wichtigen Elemente in Scrum bildet die Timebox. Die folgende Tabelle zeigt auf, wie viel Zeit man maximal für den jeweiligen Scrum Event aufwenden soll. Die Timebox sollte dabei durch eine Person (meist den Scrum Master) kontrolliert werden.
Source: scrum.org
Product Backlog Refinement
- Refinement bedeutet:
- Planung des Product Backlogs bis zu einem verwertbaren Detaillierungsgrad
- Aufrechterhaltung einer rollierenden Backlog-Betrachtung
- Der Plan ist, dass 10% der Entwicklungsteam-Kapazität für das Refinement aufgewendet werden soll
- Top priorisierte Product Backlog Items sind gut verständlich und einfach für das Sprint Planning auszuwählen
- Die Items sind “ready”
Definition of Done
- Die Definition von Erledigt ist ein gemeinsames Verständnis von Vollständigkeit – sie spiegelt die Release-Qualität wider
- Muss allgemein verstanden und vereinbart werden, um die Transparenz zu erhöhen
- Es ist der minimale Arbeitsaufwand, den ein Entwicklungsteam für ein Product Backlog Item leisten muss
- Hilft dem Product Owner und jedem zu verstehen, wann etwas erledigt ist
Monitoring Sprint Progress
Das Monitoren über den Sprint Fortschritt ist grundsätzlich für das Entwicklungsteam gedacht. Es soll das Team als selbstorganisierte Einheit unterstützen. Das Monitoring ist eine Indikation für den Sprint-Fortschritt und falls der Umfang mit dem Product Owner besprochen werden sollte.
Sprint Burndown Chart
Das Sprint Burndown Chart dient dem Entwicklungsteam, graphisch den Fortschritt im Sprint zu sehen. Das Burndown Chart funktioniert so, dass in der X-Achse die Zeit und in der Y-Achse der Umfang des Sprints dargestellt wird. Der Umfang des Sprints kann je nach dem unterschiedlich sein. Man kann beispielsweise die Anzahl Sprint Backlog Items als Messeinheit verwenden. Es kann aber auch die Schätzgrösse, wie die Storypoints angewendet werden.
Das Burndown-Chart verläuft horizontal entlang der Tage des Sprints. Sobald ein Sprint Backlog Item abgeschlossen ist, reduziert sich das Sprint Burndown Chart um die Messgrösse. Auf folgendem Bild ist ein Beispiel eines Burndown Chart ersichtlich:
Sprint Burndown Chart. Soruce: scrum.org
Velocity
Die Velocity dient dazu, ein Mass für die pro Sprint gelieferten Product Backlog Items zu erhalten. Sie wird primär vom Entwicklungsteam verwendet. Die Velocity hilft zu erfahren, wie viel Arbeit man in den Sprint nehmen kann. Weiter kann die Velocity vom Product Owner verwendet werden, um eine Prognose auf Product Backlog-Ebene zu erstellen.
Selbstorganisation
Das Scrum Framework setzt sehr stark auf selbst organisierte Einheiten. Es gibt dabei keine Stelle, auch nicht der Scrum Master, welche dem Team Vorgaben erteilt. Idealerweise definiert jedes Scrum Team für sich selbst, wie es das Ziel erreichen kann. Hier einige Beispiele zum Thema Selbstorganisation. Ein Entwicklungsteam:
- wählt einen realistischen und herausfordernden Arbeitsaufwand für den Sprint
- stellt klärende Fragen an den Product Owner
- bestimmt, wie es die Anforderungen am besten erfüllen kann
- entscheidet selbst, wer was wann macht
- entscheidet selbst, wer im Team gebraucht wird und wer nicht
- bittet bei Bedarf um Hilfe bei, wenn ein Hindernis aufkommt
- definiert und verbessert seine technischen Praktiken
- wählt seinen eigenen Scrum Master aus
Schätzen
Schätzungen sind in Scrum ein weiteres, wichtiges Element. Die Product Backlog Items werden durch das Entwicklungsteam geschätzt. Das führt dazu, dass Umfang der Story besser eingestuft werden kann, als wenn dies durch eine Einzelperson erfolgt.
Eine dieser Schätzeinheiten sind die Story Points. Sie basieren auf Grösse, Aufwand sowie Komplexität und nicht auf Dauer. Sie stehen numerisch relativ zueinander. Jedes Team schätzt unterschiedlich, da andere Personen und andere Referenzeinheiten verwendet werden können. Eine beliebte Schätzeinheit ist eine Anlehnung an die Fibonacci-Folge. Sie addiert jeweils die aktuelle und letzte Einheit zusammen (0, 0.5, 1, 2, 3, 5, 8, 13, …). Bei Scrum wird nach der 13 häufig die Folge angepasst und auf maximal 100 reduziert. Dabei werden die Zahlen 20, 40 und 100 verwendet. Zudem gibt es noch die Fragezeichen und Kaffee-Einheit (Letzteres, um eine Pause beim Planning Poker einzufordern).
Planning Poker
- Jeder Entwickler hat ein Deck mit Schätzkarten
- Der Kunde bzw. Product Owner liest eine User Story vor und sie wird kurz diskutiert
- Jeder Entwickler wählt individuell eine Karte aus, die seiner Einschätzung entspricht
- Die Karten werden gleichzeitig umgedreht, so dass alle sie sehen können.
- Unterschiede werden im Team diskutiert (vorallem die Ausreisser wie ein Unterschied im Team von 2 zu 8)
- Nach der Diskussion wird erneut geschätzt, bis eine gewisse Übereinstimmung der Schätzung erfolgt
SAFe – Scaled Agile Framework
Nach dem eigentlichen Theorieblock zu Scrum hatte die Klasse die Möglichkeit, weitere Fragen zu stellen. Eine davon war, wie man denn die Planung für Gross-Projekte, Applikationen mit vielen Teams oder Programmen vornehmen kann. Ari hat uns hierzu das Scaled Agile Framework “SAFe” kurz vorgestellt.
Weiterführende Informationen zu diesem Framework sind auf folgender Seite aufrufbar:
https://www.scaledagileframework.com/#
SAFe: Scaled Agile Framework