Es ist erstaunlich, wie häufig einem diese Frage im IT-Umfeld noch begegnet, und außerhalb schaut es naturgemäß auch nicht besser aus. Was ist es also, dieses Scrum? Nachdem wir nun bereits wissen, was Agilität und XP sind, wird es Zeit, uns mit dem aktuell weitestverbreiteten agilen Framework auseinanderzusetzen.

Framework. Genau. „Scrum ist ein Rahmenwerk zur Entwicklung und Erhaltung komplexer Produkte“, heißt es im offiziellen Scrum Guide, der Grundlage für alle Arbeiten in Scrum. Nur wenn eine Entwicklung genau dieser Grundlage folgt, darf sie offiziell von sich behaupten, dass sie mit Scrum arbeitet. Lässt man einzelne Elemente weg, ist das möglicherweise in Ordnung, aber eben nicht mehr Scrum.

Aber von vorne. Scrum ist also ein Rahmen, mit dem Software (und andere Dinge) entwickelt und erhalten werden. Dabei sind unter anderem die Rollen, Ereignisse, Artefakte und Regeln genau definiert. Um es einfach zu halten, hier die jeweils wichtigsten Punkte, alles andere könnt ihr im Scrum Guide genauestens nachlesen.

Es gibt im Scrum drei verschiedene Rollen: Scrum Master, Product Owner und Development Team. Die Person in der Rolle Product Owner entscheidet mit Blick auf das Produkt, was umgesetzt werden soll. Dabei ist ihre zentrale Aufgabe, den Wert der geleisteten Arbeit zu maximieren, also das Wertvollste umsetzen zu lassen. Das Development Team, also alle, die die eigentliche Arbeit am Produkt erledigen, entscheidet selbst, wie es die Aufgaben umsetzt. Und die Person, welche die Rolle Scrum Master einnimmt, ist diejenige, die auf die korrekte Anwendung von Scrum achtet und dem Team das Arbeitsumfeld genau so gestaltet/gestalten lässt, dass es die Umsetzung mit Scrum reibungslos durchführen kann.

Die Iterationen, also sich wiederholende Zeiträume, in denen dabei gearbeitet wird, werden Sprint genannt. Diese Sprints dauern typischerweise zwei bis vier Wochen, je nach Unternehmen, und enden damit, dass das Team ein Inkrement der Arbeit abliefert, das potentiell ausgeliefert werden kann. Ein Inkrement beinhaltet dabei die Arbeit des aktuellen Sprints und die Inkremente der vorherigen Sprints, auf denen aufgebaut wird. Also im Grunde genommen die gesamte auslieferbare Arbeit für das Produkt.

Der Sprint selbst ist ein sogenanntes Ereignis in Scrum. Weitere Ereignisse sind das Daily Scrum, ein tägliches Meeting, in dem der kommende Tag geplant wird, am Ende eines Sprints eine Review, in der das Ergebnis des Sprints betrachtet wird, sowie eine Retrospektive, in der nicht die Inhalte, sondern das Arbeiten selbst betrachtet und verbessert wird.

Direkt nach dem Ende eines Sprints startet der neue Sprint. In der Regel ist die erste Handlung dabei das gemeinsame Planning, bei dem das Team eine Einschätzung trifft, welche Arbeit sie innerhalb des Sprints in einen lieferbaren Zustand möchte. Dabei hilft ein Sprint-Ziel, die richtige Arbeit auszuwählen und anzugehen. Diese Arbeit wird dann vom Entwicklungsteam vom Produkt-Backlog, einer Liste mit allem, was potentiell im Produkt landen kann, in das Sprint-Backlog übernommen, das nur das beinhaltet, was innerhalb des Sprints angegangen wird.

Produkt-Backlog, Sprint-Backlog und Inkrement werden auch als Artefakte bezeichnet. Ferner einigt sich das Scrum Team auf eine „Definition of Done„, ein gemeinsames Verständnis, wann einzelne Arbeitselemente und ein Inkrement an sich fertig sind, um integriert zu werden.

Alles in allem ist Scrum ein nützliches Framework für die Produktentwicklung. Während es allerdings betont, wenig präskriptiv zu sein, nutzen viele diese Freiheit, um einzelne Teile wegzulassen. Das führt dann nicht selten dazu, dass das Arbeitsergebnis nicht so wie gewünscht den höchstmöglichen Wert hat.

Ganz zu schweigen von Überforderung des Teams und anderen unerwünschten Nebenwirkungen. Was wiederum dazu führt, dass die Mitarbeitenden einen Widerstand gegen das „neue Framework“ (erstmals beschrieben übrigens um 1996 rum) aufbauen und allgemein agilen Ansätzen kritisch gegenüber stehen. Ungut.

Es lohnt sich also, nicht einfach anzufangen, sondern wenigstens ein bisschen Zeit zu investieren, um die Grundlagen zu erlernen. Dafür gibt es jede Menge Trainingsanbieter am Markt (*hust*), die das mal mehr und mal weniger gut vermitteln. Aber auch autodidaktisch lässt sich ein Einstieg schaffen, wenn man genug Zeit, ein gutes Leseverständnis, einen Zugang zu YouTube und einen Austausch mit anderen Scrum-Praktizierenden hat.

Ist Scrum also das Allheilmittel für die Entwicklung? Wie bei allen Frameworks gilt: Es kommt auf den Einsatzzweck an. Es lohnt, sich einen externen Coach zu holen (*RÄUSPER*) und die aktuelle Situation zu analysieren, bevor die Wahl auf ein Framework oder eine Methode fällt. Das spart unter anderem viele Nerven, Unzufriedenheit bei den Mitarbeitenden und eine Menge Geld. Just saying …

Achja, die Bezeichnung Scrum kommt aus dem Rugby. Warum, könnt ihr ja mal selbst überlegen. Wer es weiß, gerne in die Kommentare damit.

[waglerit-newsletter-block]