5. Scrum

Der Täufer taucht den Kopf eines Kindes in die brackigen Fluten und murmelt dabei einige heilige Worte, danach wendet er sich, noch bis zu den Knien im Wasser stehend, an die herumstehenden Gaffer und brüllt sie lauthals an: »Dieser Mann ist nun geheilt, da er von nun an alles richtig macht in seinem Arbeitsleben! Ihr jedoch, ihr seid Ketzer, die der falschen Lehre anhängt, der Lehre vom Wasserfall. Und der Wasserfall wird es sein, der euch hinweg waschen wird, vom Erdenrand des Projektmanagements!«

So wurde mir Scrum nahe gebracht, bei einer Konferenz. Täufer war ein Scrum-Master und er beschimpfte unablässig sein Publikum, das er zuvor per Handaufzeigen sich selbst in Wissende und Ketzer geteilt hatte, damit, dass sie eine Schande für die gesamte IT seien, auf dem falschen Pfad, und alle Projekte die sie bis heute gemacht hatten, wären der letzte Müll gewesen, ein riesiger Wasserfall aus Scheiße!

Geschickt umging er es dabei zu erklären, was sein “Scrum” denn nun eigentlich sei, sondern hackte vor allem auf anderen Ansätzen, Frameworks, oder auch jenen die gar keiner speziellen Ideologie an hingen herum, sie alle würden Wasserfall machen. »Alles außer Scrum ist Wasserfall!«, schrie er uns förmlich entgegen, und wir alle waren kleine, nutzloses Kröten, die ihre Arbeitszeit bis dahin nur verplempert hatten ohne zählbares Ergebnis.

Wikipedia nennt es ein »Vorgehensmodell zur agilen Softwareentwicklung«. Einige denken, Scrum wäre der Name der Piratenspelunke in Monkey Island I, in Wahrheit ist es aber eine Religion, die auf Konferenzen, Messen und in luftarmen Konferenzräumen rund um diesen Globus verkündet wird. Und das Versprechen ist einfach nicht so zu sein, wie alles was man vorher gemacht hat, was ja so schlecht lief. Wenn ein Haufen Idioten keine ordentliche Website zusammen gebaut bekommt, liegt es nicht daran, dass es Idioten sind, sondern dass sie kein Scrum benutzen! Und auch wenn es gut läuft, es könnte doch viel besser laufen, dort im Land Scrum, wo Milch und Honig fließen. Wie das genau geht? Das weiß keiner so genau, denn nicht alle machen das gleiche Scrum. Vielmehr kocht jeder sein eigenes Süppchen. Weil jeder nach einem kurzen Einführungsseminar der Ansicht ist, er wisse, was er da tue. Ich ja auch.

Treffen sich zwei Scrum Master. Sagt der eine: »Und wie ist dein Scrum heute so?«, antwortet der andere giftig: »Jedenfalls anders als deins!«

Für irgendein Scrum also teilt man die Mitarbeiter in Stakeholder, Product Owner, Scrum Master und Teams. Es gibt ein paar regelmäßige Meetings, man arbeitet, nein iritiert iteriert in Sprints und man zählt Punkte. Ganz ähnlich also wie ein Mitgliedschaft bei Weight Watchers—auch so eine Sekte. Die Punkte jedenfalls schreibt man an User-Stories, so sind die Aufgaben formuliert. Ein Feature ist dort immer aus der Sicht eines Nutzers beschrieben und auch, wozu es ihm nützt. Das geht so lange gut, bis zum ersten Mal die Firma als User auftaucht »Als Website AG möchte ich mehr Werbeplätze einbinden, damit wir mehr Geld verdienen«. Die Userstories werden im Backlog zusammengefasst und pro Sprint werden welche ausgesucht, die in diesem Sprint zur Releasereife entwickelt werden, dem MVP, dem minimal viable product. Ja, Scrum hat ein Wort für alles und für alles einen eigenen scrummy way. Um all das umzusetzen braucht man nur die folgenden Meetings abzuhalten und irgendwann zwischendurch such mal Code zu schreiben, zu testen, zu releasen, zu verbessern.

Da ist einmal das Daily (Scrum), wo alle maximal eine Viertelstunde zusammenstehen und sich gegenseitig erzählen, was sie gestern gemacht haben, was ihnen im Weg steht und was sie heute vorhaben. Das kann interessant sein, anfangs. Mit der Zeit entwickelt man aber eine gewisse Abstumpfung, zumal das Daily das erste Meeting am Tag ist und die meisten gerade erst aufgestanden sind. Da ist man oft mit der eigenen Tagesplanung mehr beschäftigt, als man den anderen zu hören kann. Ich schwöre einer meiner Kollegen hat aus reiner Bosheit fünf Tage am Stück den immer gleichen Text beim Daily heruntergebetet und keiner hat es gemerkt. Wie so ein Daily läuft kann man schnell überprüfen, indem man danach in die Runde fragt, wer noch weiß, was man gerade erzählt hat.

Dann gibt es das Planning. Hier wird geplant, was in einem Sprint umgesetzt werden kann und wie. Es soll pro Sprintwoche maximal zwei Stunden dauern, bei vierwöchigen Sprints also mal gleich einen schlappen Arbeitstag. Zur Vorbereitung des Plannings, gibt es meist noch ein weiteres Meeting, das Grooming. »Der Product Owner stellt dem Entwicklungsteam die im Product Backlog festgehaltenen Produkteigenschaften in der zuvor priorisierten Reihenfolge vor.« Gemeinsam entwickelt man ein Verständnis dafür, was im kommenden Sprint zu erledigen ist. In der Webentwicklung heißt das im wesentlichen, man schaut auf Screenshots und Designs und füllt gemeinsam den Wissensteil, den man in Screenshots nicht sehen kann, also so an die 99 Prozent. Hinterher einigt man sich irgendwie, wieviel Arbeit man wohl schaffen kann. Dazu kann man das so genannte Planning-Poker nutzen, das nicht zufällig etwas mit Spielen zu tun hat. Geschätzt wird auch nicht Zeit, sondern Komplexität, obwohl alle im Kopf andauernd in Zeit zurückrechnen, der Sprint selbst ist ja auch eine zeitliche Dimension. So schätzen die einen die Zeit für die Aufgabe, die anderen wieviel Zeit sie mehr haben, wenn sie jetzt ohne weitere Diskussion schnell eine Zahl an den Task schreiben und das Meeting eher vorbei ist.

Und als letztes kann man noch regelmäßig am Ende eines Sprints eine Retrospektive abhalten. Dort wird, kanalisiert durch lustige Spielchen, erarbeitet, wie das Team mit Problemen umgeht, oder am liebsten, wie es noch besser werden kann. Hat man ein paar Retrospektiven abgehalten, stellt man aber auch schon mal fest, dass man immer wieder auf dieselben Probleme stößt, bspw. das die Retrospektiven nicht laufen. Weil eine derartige Metadiskussion kontraproduktiv ist, wird die Retro schnell dran gegeben, vergessen oder dem aktuellen Erfolgsdruck geopfert. Was Schade ist, denn während eines Sprints ist nicht viel keine Zeit Dinge zu kritisieren oder zu ändern. »Das ist jetzt ein Thema für die Retro« ist das Totschlagargument für alle anderen Meetings, falls unerwünschte, weil längliche Diskussionen aufkommen. Leider auch, wenn gar keine Retros mehr abgehalten werden.

Ich wische mir das Wasser aus den Augen und trockne die nassen Haare. Schön, nun bin auch in zu Scrum getauft. In Zukunft will ich nur noch Storypoints schaffen und Iterationen bauen. Das große Ganze wird mir dabei immer mehr egal sein, das beruhigt mich. Diese Zeilen dort oben? Die hat ein anderer geschrieben. Das wäre mal ein Thema für eine Retro.

Bild: Paul Itkin