Wenn ich über agile Methodiken sprechen, nimmt Scrum als eine Form der Selbstorganisation von Teams einen großen Stellenwert ein. Nicht, weil ich denke, dass dies die ultimative agile Arbeitsweise wäre, sondern, weil es sehr verbreitet ist und dort sehr viele Elemente zu finden sind, die auch in anderen agilen Kontexten genutzt werden. Es ist einfach ein sehr geeignetes Beispiel, wenn ich meine Überlegungen zu Arbeitsroutinen, Beschäftigung mit Qualität Reflexion in der Zusammenarbeit darlegen will. Um in anderen Artikeln nicht jeweils Scrum als Ganzes erklären zu müssen, soll dieser Artikel die Entstehung, die wesentlichen Element und deren Zusammenspiel kurz erläutern.
Zusammengefasst kann man sagen, dass Scrum von einem festen, multifunktional besetzten Team ausgeht, das sich die Arbeit selbst einteilt und in relativ kleinen Arbeitsschleifen (Iteration bzw. „Sprint“) von üblicherweise zwei bis vier Wochen umsetzt. Ziel ist es, jeweils sofort nutzbare Ergebnisse („Inkrement“) an die Kund:innen ausliefern zu können. Ständiges Feedback von diesen sowie das Reflektieren auf die eigene Arbeitsweise ermöglichen ein kontinuierliches Lernen und Anpassen an immer wieder wechselnde Anforderungen. Im Gegensatz zum klassischen Projektmanagement gibt es dabei keine:n Projektmanager:in oder Abteilungsleiter:in, die die Arbeit steuern, sondern das Team bestimmt alleine, auf welche Art und Weise sowie mit welcher Arbeitslast sie die Sprints bewältigen wollen. Die Grundprinzipien sind im sogenannten Scrum-Guide festgehalten.
Entstehungskontext
Bereits vor über 20 Jahren hat sich in der Softwareentwicklung gezeigt, dass Produktentwicklung mit der sogenannten „Wasserfallmethode“, bei der zu Beginn eines Projektes die Anforderungen mit der Kundin oder dem Kunden festgelegt und dann systematisch abgearbeitet wurden, selten zufriedenstellende Ergebnisse produzierte. Zu lange Produktentwicklungszyklen, unzureichende Anforderungserhebung sowie Produktdesigns, die an den tatsächlichen Bedarfen der Kund:innen vorbeigingen, führten zu großen Akzeptanzproblemen bei der Kundschaft und Frustration bei den Programmierer:innen. Vor diesem Hintergrund veröffentlichten 17 renommierte Softwareprogrammierer 2001 (alles Männer) das „agile Manifest“, das neue Grundsätze für die Produktentwicklung definierte und dabei vor allem die Kundi:nnen stärker in den Mittelpunkt rückte (siehe dazu https://agilemanifesto.org/).
Die grundsätzliche Forderung hinter dem Manifest war eine Flexibilisierung des Entwicklungsprozesses, der weniger vorherbestimmt ablaufen und sich die Ergebnisse eher aus dem gesamten Prozess ergeben sollten. Parallel dazu und in der Folge entwickelten sich verschiedenen agile Arbeitsweisen heraus, die inzwischen über die reine Softwarenentwicklung hinaus genutzt werden. Mit der Methode „Scrum“, als der bekanntesten agilen Praktiken, wurde diese Idee im Anschluss besonders populär und wird heute oftmals auch mit dem Begriff „agiles Arbeiten“ gleichgesetzt. „Scrum“ kommt dabei eigentlich aus dem Sport, genauer: Rugby, bei dem sich ein Team zu Beginn jedes Angriffs engzusammendrängt, um das nächste Manöver auszuhandeln und dann umzusetzen. Entsprechend muss man sich auch das Arbeiten im Scrum-Kontext vorstellen: ein sehr enges und intensives Arbeiten auf das nächste, schon in Sichtweite liegendes Ziel.
Die einzelnen Scrum-Elemente
Eines der zentralen Ideen bei Scrum ist, die Softwareprogrammierung konzentriert in einem Team von max. neun Personen so erledigen zu lassen, das es autark alle Aufgaben im Rahmen der Softwareentwicklung selbst abdecken kann. Dazu gehören neben den eigentlichen Entwickler:innen auch Tester:innen und Leute, die die Software implementieren. Die Idee ist, dass das Team – also die eigentlichen Spezialist:innen – selbst entscheidet, wieviel es in welcher Reihenfolge und Vorgehen pro Sprint schafft. Es gibt allerdings einen Product Owner, der als Mittler zwischen dem Team und den Kund:innen über die zu entwickelnden Funktionen entscheidet und diese priorisiert. Ein Scrum Master hilft dem Team bei der Selbstorganisation, organisiert die wesentlichen Arbeitsformate und beseitigt möglichen Schwierigkeiten, auf die das Team bei ihrer Arbeit stoßen.
Startpunkt für jede Produktentwicklung ist die Anforderungserhebung. Hierzu gibt es inzwischen aus dem agilen Kontext sehr ausgefeilte Verfahren. Alle erarbeiteten Anforderungen werden in ein Backlog geschrieben, aus dem sich die Entwickler:innen bedienen, wenn sie ans konkrete Entwickeln gehen. Das Backlog ist jedoch kein statischer Anforderungskatalog, wie man das auch traditionellen Projekten kennt, sondern wird im Fortgang durch den Product Owner mit dem oder der Kund:in kontinuierlich verändert, umpriorisiert und erweitert. D.h., die Anforderungen bleiben variabel und veränderbar. Das entspricht auch einem der zwölf Prinzipien, die das agile Manifest begleitet: „Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“
Bevor nun eine Anforderung (oder Anforderungsbündel) in Arbeit genommen wird, muss dieses bereits einmal qualitätsgesichert werden mit Hilfe der sogenannten Definition of Ready (DoR). Das Team hat sich nämlich zuvor Kriterien auf Vollständigkeit und Qualität gegeben, die als Checkliste fungieren, um zu entscheiden, ob schon alles bekannt und bedacht ist, bevor man in die Programmierung geht. In der Theorie darf nichts angelangt werden, dass diesem Anspruch nicht genügt. Umgekehrt gibt es auch einen festen Katalog an Abnahmekriterien: die Definition of Done (DoD). Die DoD bestimmt, mit welchem Reifegrad das Inkrement an die Kund:innen übergeben werden kann.
Innerhalb jedes Sprints gibt es ein tägliches Treffen (Daily), das dafür sorgt, dass das Team immer ausreichend synchronisiert ist und um zugleich die Möglichkeit zu haben, Schwierigkeiten frühstmöglichst zu identifizieren und zu beseitigen. Oberstes Ziel ist immer, das Sprintziel einzuhalten und zum Ende eines jeden Inkrements ein fertiges Teil des Produkts auszuliefern. In einem Sprint Review wird dies den Kund:innen vorgestellt und deren Feedback eingeholt. Dem schließt sich sogleich die Planung (Sprint Planning) für das nächste Inkrement an, indem bereits die Rückmeldungen aus den vorangegangenen Sprints berücksichtigt werden.
Das Ende jedes Sprints stellt schließlich die Retrospektive dar, auf der die gemeinsamen Zusammenarbeit auf dem Prüfstand gestellt wird. Das Team tauscht sich darüber aus, was gut, was schlecht lief, was sich bewährt hat. So wird z.B. besprochen, ob die Definition of Ready wirklich gewährleistet, dass nur ausreichend ausführlich beschriebene Anforderungen in Arbeit genommen wurden. Genauso kann kritisch hinterfragt werden, wie gut die Zusammenarbeit im Team war. Vielleicht gab es auch Störungen von Außen, die ein konzentriertes Arbeiten verhindert haben. Ziel der Retrospektive ist es, mit Hilfe des Prinzips „Inspect & Adapt“ schnelle Lernkurven zu generieren und bereits in der nächsten Iteration bessere Ergebnisse als bei der letzten liefern zu können. Es ist Aufgabe des Scrum Masters, das zu gewährleisten.
Einige agile Praktiken neben Scrum
Wie oben schon erwähnt, ist Scrum nur eine unter vielen agilen Praktiken. Sie alle profitieren von einerseits einer klaren Struktur mit festen Ritualen und andererseits von einer Flexibilisierung der Produktentwicklung. Andere Methoden sollen hier kurz vorgestellt werden:
- Design Thinking: In bewussten Schleifen von Theoriebildung, Prototyping und Kundenfeedback in eigener Geschwindigkeit arbeiten sich Designer:innen und Nutzer:innen an das Produktideal heran. Dabei soll der Prototyp schon so viele der zukünftigen Merkmale wie möglich visualisieren, um sicherzugehen, dass sich alle dasselbe unter dem Produkt vorstellen und auch tatsächlich die Funktionalitäten auf diese Weise bereitgestellt werden können.
- Kanban-Board: Alle Arbeit wird auf einer Tafel visualisiert, die verschiedenen Reifegrade („To-Do“, „Doing“,,Waiting for others“, „Done“) abbildet, dargestellt. Die Teammitglieder können selbstständig und nach klaren Regeln die Arbeit ziehen („Pull-Prinzip“) und nicht mehr zugeschoben bekommen („Push-Prinzip“). Dabei dürfen nicht mehr als z.B. drei Aufgaben in „Doing“ gebracht werden, um Arbeitsüberlastung und Fokusverlust zu vermeiden. Oftmals kommt auch bei Scrum ein Kanban-Board zum Einsatz.
- Kamishibai-Board: Im Gegensatz zu Kanban ist diese Methode für wiederkehrende Aufgaben gedacht. Diese werden auf Karten mit einer grünen und einer roten Karte dargestellt, die den aktuellen Bearbeitungsstand widerspiegeln. Die Spalten teilen sich in den Frequenzen auf, in denen sie regelmäßig bearbeitet werden müssen („täglich“, „wöchtenlich“, „monatlich“…). Idealerweise betrachtet man Kanban- und Kamishibai-Board zusammen, um Arbeitsüberlastung zu vermeiden.
- Extreme Programming: Über Planungsspiele, ständiges Überarbeiten, dem Programmieren in Paaren und engem Kundenkontakt werden in Sprints auslieferbare Softwareprodukte entwickelt, die höhere Qualität und stärkeren Kundenfokus versprechen.
Lesetipp: Agile Methodenkiste des Blogs „Agile Verwaltung„
Dr. Dina Brandt 
Kommentar verfassen