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

Veröffentlicht von

Nico

Nico BrĂŒnjes ist Digitalkreativer und Internethandwerker. Seit mehr als 15 Jahren erdenkt, baut und programmiert er moderne, standardkonforme und zugĂ€ngliche Webseiten in HTML, CSS und Javascript.