Probleme mit dem Daily Scrum

Die Murmeltiere der Webentwicklung grüßen sich bekanntermaßen täglich, jedenfalls dort, wo Projektverschleierungsreligiositäten wie Scrum betrieben werden, also quasi all over the world. Für den Scrum-Anfänger, den Stakeholder und den Vorgesetzten IRL ist das die Scrum-Komponente, die am einfachsten zu verstehen ist. Leider ist das meist ein Missverständnis auf breiter Front und gerade durch die tägliche Wiederholung, verfestigen sich Fehler, die sich einschleichen praktisch immer wieder neu.

By the book

Im engere Sinne ist das sogenannte Daily ein kurzes (auf hart 15 Minuten beschränktes) tägliches Meeting, währenddessen sich die Entwickler erzählen, wie ihr Stand gerade ist. Außer den Entwicklern nimmt ein Scrum-Master an dem Meeting teil, ebenfalls der Product Owner (PO) nach Möglichkeit. Protagonisten sind aber die Entwickler, die sich gegenseitig die Fragen beantworten, was sie gestern getan haben, was sie gedenken heute zu tun und was ihnen im Weg steht. An diese drei Fragen soll sich akribisch gehalten werden. Der PO besucht dieses Meeting, um selbst auf neuestem Stand zu bleiben, ggf. um Fragen zu beantworten, das aber allenfalls, wenn sie mit „ja“ oder „nein“ zu beantworten sind, längere Diskussion finden zwangsweise nach dem Meeting statt.

What can possibly go wrong

Bei einem so einfachen und hart reglementierten Termin fragt man sich, was kann denn da noch schief gehen? Leider alles. Wie vieles in der Welt des Scrum funktioniert es möglicherweise nur, wenn man sich wirklich daran hält, in der richtigen, reinen, wahren Scrum-Umgebung. Also niemals. Abweichungen, die landläufig dauernd vorkommen („wir machen unser eigenes Scrum“), wie fehlender Scrum-Master, mehrere PO, nicht durchbrochene Command-and-Control-Muster führen sofort zu einer Schieflage und das Meeting erfüllt einerseits nicht seinen Zweck und wird andererseits schnell zur täglichen Qual.

Organisationsprobleme

Oft wird ja schon der Sinn des Meetings von vorneherein falsch verstanden. Die Entwickler informieren sich gegenseitig, was sie gerade machen und zu machen planen, nicht wie weit sie mit einer Story oder Aufgabe gerade sind. Die Fragen wie lange etwas noch dauert oder wann etwas fertig ist gehören nicht ins Daily! Dass solche Fragen natürlich doch aufkommen, liegt mal an Command-and-Control-Strukturen, die die Einführung von Scrum überdauert haben, mal an fehlenden Rahmenbedingungen, die durch das Scrum eigentlich gesetzt sein sollten. Eine nicht besetzte Scrum-Master-Stelle bspw. deutet schon an, dass die Sache in die falsche Richtung zu laufen droht. Er wäre es, der ein Daily moderiert und aufkeimende Konflikte schlichtet. Fehlt er, muss entweder ein Teammitglied oder gar der PO die Moderation des Treffens übernehmen, ersteres mag noch irgendwie gehen, ein moderierender PO allerdings ist ein deutliches Zeichen für scrumfuck. Der PO hat in einem Daily qua Definition nur eine sehr passive Rolle, er soll sich lediglich selbst informieren. Und er tritt keinesfalls im Namen der Stakeholder auf und fragt, wie lange es noch dauert. Never.

Inhaltliche Schwächen

Aber auch das Team kann ein Daily in die falsche Richtung führen. Nochmal, es geht ausschließlich um die drei Fragen:

–  Was habe ich seit dem letzten Daily Scrum getan?
–  Was plane ich, bis zum nächsten Daily Scrum zu tun?
–  Was hat mich bei der Arbeit behindert?

Also darum, dass sich die Teammitglieder gegenseitig informieren, was gerade gemacht wird. Eben um es zu wissen, schon mal gehört zu haben, mitzubekommen, wenn Dinge möglicherweise drohen doppelt gemacht zu werden. Falsch wäre es, diese Gefahr dann aber zu diskutieren. Dafür muss man sich danach Zeit nehmen, mit den Leuten, die es betrifft, um nicht alle weiter abzulenken. Es geht eben nicht darum festzustellen, an welchem Punkt der Story sich die Entwicklung gerade befindet. Nicht weil die Frage grundsätzlich nicht erlaubt wäre im Scrum, nur eben nicht in diesem Meeting. Abweichungen vom Ritual, bspw. statt die genannten Fragen zu klären, zu besprechen, wie der Stand einzelner Stories ist, ist schlicht ein Fehler. All diese Dinge lenken zu sehr vom Fokus, der thematischen Arbeit der Entwickler ab.

Technische Probleme

Immer wieder hört man, dass Scrum über mehrere Standorte hinweg ein Problem ist, wird immer wieder betont. Genauso oft gibt es allerdings auch Teams, die behaupten, bei ihnen würde genau das funktionieren. Die Wahrheit mag hier in der Mitte liegen, sicher aber ist, dass örtliche Hürden zu technischen Hürden werden, die für Rituale wie das Daily ein Problem darstellen können. Wie schon betont, schauen sich die Entwickler während des Dailies an und berichten einander. Steht dem mangelhafte Video- und Tontechnik im Wege, nervt das nicht nur wie irre, sondern es geht auch sämtlicher Verve, den so ein Meeting möglicherweise haben könnte verloren und die Empathie der teammates untereinander bleibt auf der Strecke. Kurz: die gewünschte Kommunikation lässt sich per Videoschalte sowieso schon schlecht transportieren, technische Probleme bringen das Fass regelmäßig zum Überlaufen.

Ebenso problematisch ist auch, wenn vom Ritual zeitlich abgewichen wird. Das Daily sollte immer zur selben Zeit sein und es sollten pünktlich alle da sein. Es soll Teams geben, die Strafen aussprechen (oder einkassieren) für Zu-Spät-Kommer. Nun gut… aber auch schon ein mehrminütiges „Könnt ihr uns verstehen“ am Meeting-Beginn setzt das falsche Setting und kann auf die Dauer ein Daily zerstören. Man darf halt nie vergessen: man macht das jeden verdammten Tag.

Und nun?

Ich persönlich würde sagen: entweder man macht es richtig oder lässt es gleich ganz bleiben. Ohne das ich eine Alternative zur Hand hätte.

Der reinen Informationspflicht kann ein geübtes Team wahrscheinlich auch per Slack-Channel nachkommen, es gibt auch Slack-Bots, die die drei Fragen täglich bei den Entwicklern abfragen und dann das Gesamtergebnis allen präsentieren. Aber auch in diesem Setting kann man noch nicht den Scrum-Master durch den Bot ersetzen, da jemand darauf achten muss, dass nicht alle immer dasselbe schreiben. Ob eine Art „Slack-Daily“ einen zeitlichen Vorteil bietet, wage ich anzuzweifeln, die Konzentration auf die drei Fragen wäre allerdings gegeben. In Teams an verteilten Standorten könnte hier wirklich ein Gewinn lauern, vor allem, wenn es technische Probleme gibt, wie oben beschrieben. Empathie bringt das Ganze natürlich nicht.

Ganz darauf zu verzichten wäre sicherlich auch ein Weg, nur dann macht man eben kein Scrum. Davon mutiert man auch nicht gleich zum microgemangeten Wasserfall, schon klar, aber hiervon ausgehend kann man mal kontrollieren gehen, wie es im restlichen Scrum-Prozess so aussieht.

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

Morgenlese I

Die vier folgenden Links, das ist mir erst aufgefallen, als ich sie in nebeneinanderlegenden Tabs durchcycelte, verbindet, neben dem Höchstmaß an interessantem Lese- und Staunegenuss, ein offensichtlicher Trend in Sachen Webdesign. Vielleicht schaut ihr einfach selbst.

  • The 100% correct way to validate email addresses in der Diesmal-aber-wirklich-Edition, zeigt tatsächlich und wissenschaftlich fundiert, den einzigen richtigen Ansatz bei der Validierung von Email-Adressen.
  • In Dark Scrum (bibber) lesen wir einmal mehr über die Horrorvision einer verfehlten Scrumeinführung, aber auch wie man es besser machen kann. So schlimm, wie es dort beschrieben ist, ist es aber hoffentlich nirgendwo… ja, oder doch?
  • Zur Frage warum die Schlangen vor den Apple Stores immer kürzer werden handelt Why We’re No Longer Desperate for the New iPhone, kurz gesagt: es ist genauso, wie man sich das schon vorstellen kann, wir hängen länger an unseren Smartphones (und Laptops) und die halten auch irgendwie länger und die neuen sind nicht so unglaublich viel besser…
  • Am Schluss der Designtipp: Jason Kottkes kottke.org begleitet meine Blogginghistorie seit Anfang an, ist aber gerade mit einem neuen Design an den Start gegangen. Bunt.