Netzgeflüster: Scrum Anti-Patterns

Offenbar habe ich eine gewisse Freude daran über Anti-Pattern zu schreiben. 🙂 Zumindest ging es hier vor einer Weile schon mal um Code Review Anti-Pattern. Manchmal erklärt sich offenbar leichter wie man es nicht macht. Aber nachdem ich nun einige Jahre in Scrum-Teams arbeite (als Softwareentwicklerin und Scrum Master) und die inzwischen auch im Agilen coache (zu coachen versuche?), sammelt sich eine Menge an Geschichten. Selber erlebten genauso wie solche, die man erzählt bekommt. Und daraus lässt sich gut am Beispiel erklären wie man Scrum nicht macht und ergo was Scrum versucht. Für heute habe ich mir mal vier rausgegriffen.

Der „Versteckte Wasserfall“

Um den versteckten Wasserfall zu erkennen, muss man manchmal schon genauer hingucken … Photo by Jeremy Allouche on Unsplash

… und den will man definitiv nicht. Wasserfall bezieht sich hier natürlich auf das Wasserfallmodell, das häufig als Negativbeispiel für Vorgehensmodelle herangezogen wird und auch in der Softwareentwicklung so seine Jahrzehnte angewendet wurde – und wird. Grundsätzlich gibt es halt für jedes Modell seine Anwendungsfälle. Aber ja: auch ich denke mit Graus an das Wasserfallmodell zurück.

Wenn nun in agilen Projekten die Storys gefühlt nie ready sind, dann gibt es höchstwahrscheinlich so einen versteckten Wasserfall – irgendwer im Projekt arbeitet danach und bildet das Bottleneck. Gut erkennbar daran, dass die Story nie geschätzt werden kann, weil es immer noch „Rückfragen gibt“. „Oh, da muss ich nochmal Rücksprache halten.“ Oder noch schlimmer: wenn es im laufenden Sprint Rückfragen gibt, bei denen sich plötzlich offenbart, dass die Sachlage doch nicht so klar ist wie man im Refinement annahm. Und die Antworten kommen nicht … .

Ich habe das beispielsweise selber mal in einem stark konzeptions-/Business-Analyse-getriebenen Projekt erlebt, wo man meinte den Entwicklern ein Datenmodell vorlegen zu wollen, worauf man das Datenbankmodell aufbauen solle. Die Anfertigung dessen wurde aber ein Never-Ending-Level-Game. Hätten wir das gemacht, würde wir wohl heute noch drauf warten. Aber irgendwann war den Konzeptionären klar, was Inkrement bedeutet.

Der „Pate“

… oder: „Ich mache dir ein Angebot, dass du nicht ablehnen kannst“. Habe ich selber nicht erlebt, aber mal gehört:  der Fall tritt beispielsweise in Teams auf, in denen die Bezahlung an erledigte Story Points geknüpft ist. Klingt schlimm – ist es auch. Das kann aus vielerlei Gründen nach hinten losgehen. Entweder kompromittiert es die Schätzung, weil das Team sich gezwungen fühlt besonders hoch (zugunsten der Auftragnehmer) oder besonders niedrig (zugunsten der Auftraggeber) zu schätzen. Letzteres eventuell weil eine Atmosphäre mangelnden Vertrauens und schlechten Klimas herrscht. In jedem Fall wird nun auch keine Komplexität geschätzt, sondern Zeitaufwand und/oder Kosten.

Die einzigen die hiervon profitieren, sind vielleicht der PO, vielleicht die Stakeholder, vielleicht der Projektmanager, aber sicherlich nicht das Dev-Team. Normalerweise wird Komplexität geschätzt, um ein Gefühl für die Größenordnung und den Schwierigkeitsgrad einer Story zu entwickeln – und natürlich ein gemeinsames Verständnis. Wer sich in dem Muster wiederfindet, sollte gut das Miteinander im Team und die Notwendigkeit dieses verzerrten Maßes hinterfragen. Normalerweise entwickeln PO und Projektmanager ein Maß, das nicht an die Story Points gekoppelt ist, aber beispielsweise die Velocity oder andere Maße als Quelle heranzieht. Und idealerweise kommt das Dev-Team mit derlei Themen nicht in Kontakt, es sei denn es interessiert sie… . Der Scrum Master oder die Masterin können bei der Methodensuche unterstützen. Die Schätzung gehört dem Team und sollte die Komplexität abbilden.

Ein anderer Fall von Der Pate tritt auf, wenn man häufig hört „Ich würde ja 5 Story Points schätzen, aber …“. Und die Begründung mag sein, dass man nicht anecken will, weil jemand im Team häufig mit einer besonders starken Meinung auftritt und die Schätzung an sich reißt. Das ist dann der Pate. 😉 Habe ich schon einige Male erlebt. Bevor wir uns aber in der Gruppendynamik verlieren, sei hier gesagt, dass der Scrum Master intervenieren und Ursachen aus dem Team rauskitzeln sollte. Oder natürlich jeder andere, der sich dazu berufen fühlt! Denn die Schätzung ist ja u.a. dazu da einen Konsens zu finden und ein gemeinsames Verständnis für den Inhalt zu entwickeln.

Photo by Headway on Unsplash

Der „Sprint 0“

Photo by Michał Parzuchowski on Unsplash

Schwieriger Fall. Es gab eine zeitlang viele, die überzeugt davon waren, dass man einen Sprint 0 braucht, um die Architektur oder irgendwas anderes festzulegen, bevor die „normale Arbeit“ losgehen kann. Die Vorstellung die ganze Architektur dort festzulegen führt häufig zu der Frage, wann denn ein Sprint 0 fertig ist? Da es ja impliziert, dass man offenbar ohne das Sprintergebnis nicht anfangen kann zu arbeiten. Tatsächlich sollten möglichst alle Arbeitsergebnisse als Inkremente nach und nach weiterentwickelt werden. Und wie häufig hat man schon gehört, dass technische Entscheidung nur aus Gewohnheit beibehalten werden, aber nicht aus vernünftiger und begründeter Entscheidung!? Das ist dann ein Turm, der früh sehr hoch gebaut wurde und entsprechend früh anfängt zu wackeln. In der Softwareentwicklung und -architektur spricht man hier auch gerne von Big Design Upfront – ein beliebtes Anti-Pattern.

Die „Eierlegende Wollmilchsau“

Über den Begriff Full Stack Entwickler habe ich mich hier ja schon mal aufgeregt. Der weckt nämlich nicht selten vollkommen falsche Vorstellungen, davon dass Entwickler alle Sprachen aus dem FF schreiben können und sowieso alles wissen. Fairerweise heißt es ja im Scrum Guide auch, dass alle Entwickler auf demselben Stand sein sollen. Das ist aber eher so gemeint, dass grundsätzlich alle einigermaßen vertraut mit den Technologien sein sollen. Natürlich hat jeder seine Stärken und Schwächen, die sich ergänzen oder gar idealerweise im Laufe der Zeit durch Erfahrung, Wissensaustausch und produktive Code Reviews zum Teil aufheben. Aber niemand kann oder weiß alles.

Ich habe mal als Full Stack Entwicklerin in einem Projekt gearbeitet, das Webfrontends über einem Java-Backend entwickelt hat. Eines Tages wollte der Kunde, dass wir native und hybride Mobile Apps schreiben. Eine große und spannende Sache, die uns aber alle kalt erwischt hat, weil wir so gar nicht mit Mobile-App-Entwicklung vertraut waren. Insbesondere Apple-Apps haben uns dabei fast das Genick gebrochen, während wir uns in die anderen Frameworks recht gut eingearbeitet haben. Dass wir damit solche Schwierigkeiten hatten, stieß auf absolutes Unverständnis beim Projektmanagement: „Was heißt hier – ihr wisst das nicht? Das ist euer Job.“

Das Anti-Pattern eierlegende Wollmilchsau erkennt man v.A. dann, wenn man voraussetzt, dass jeder alles können muss und Stakeholder, POs oder Management partout keine Lernaufwände innerhalb von Storys oder gar in Form von Storys im Sprint reservieren wollen. Wo soll denn das Wissen herkommen? Aus der Freizeit? Das hat nichts mit der modernen Arbeitswelt zutun, der schnelllebigen Softwareindustrie schon gar nicht. Ein ähnliches Muster ist, wenn man keine durch die Entwickler vorgeschlagenen Storys zulässt. Man denke nur an Code Improvement, Dev Ops-Themen, Housekeeping oder einfach dem technischen Fortschritt nachzukommen. Da heißt es häufig: „Macht es doch gleich richtig“. Erstens: es muss halt „alles“ gemacht werden. Zweitens: nicht immer ist „alles“ zufällig auch im Rahmen einer Story anfallend. Wird in der Großküche nicht mal gewischt, wird die vom Gesundheitsamt halt auch zugemacht. (Vielen Dank an einen Kollegen für das bildliche Beispiel! 🙂 )

Na du Kleine? Wirst du auch mal eine eierlegende Wollmilchsau, wenn du groß bist? Photo by Abonyi Kevin on Unsplash

Das was am meisten Spaß gemacht hat, war mal wieder die Namen für die Anti-Pattern zu suchen. 🙂 Ich hätte noch eine Weile weitermachen können … . Welche der Anti-Pattern sind euch schon begegnet? Oder sind euch gar andere begegnet? Stimmt ihr bei der Ursachenforschung zu oder habt ihr manche Situationen ganz anders erlebt? Scrum hin oder her denke ich, dass sich das eine oder andere davon auch auf alle möglichen Projektarbeiten adaptieren lässt.

Netzgeflüster ist eine Kategorie meines Blogs in der ich mich immer zwischen dem 10. und 15. eines jedes Monats Themen aus IT, Forschung, Netzwelt und Internet widme genauso wie Spaß rund um die Arbeit mit Bits und Bytes. 🙂

2 Antworten

  1. Avatar von voidpointer
    voidpointer

    Der Pate. 😉 Eine Variante davon würde ich als Chef-Scrum bezeichnen, d.h. der Chef schätzt und plant (mit). Das Problem dabei war, dass man in der Folge mit der Personalfluktuation durch die Decke gerast ist und leider überwiegend die starken Entwickler zu erst weg waren. Die Konsequenzen waren mitunter sehr unvorteilhaft.
    Natürlich muss man zumindest auf lange Sicht im Budget bleiben, wenn die Sache einen Sinn machen soll.

    Was ich an Scrum immer geschätzt habe waren die Transparenz und die Verbindlichkeit die der Prozess erzeugt.
    Durch die Team-Schätzung unter der Prämisse, das jedes Team-Mitglied prinzipiell jede Aufgaben übernehmen können muss, hat die zu verteilenden Aufgaben inhaltlich aufgewertet und die Schätzung hat zusätzlich die zeitlichen Rahmen grob fixiert.
    Das man als einfacher Entwickler in der Retrospektive Feedback liefern konnte und dieses von allen Stakeholdern auch regelmäßig gelesen wurde, hat mitunter sehr viel Aufwand gespart.
    Transparenz und Verbindlichkeit lassen sich denke ich kaum überbewerten. Wenn man darauf verzichtet, entartet auf kurz oder lang die Zusammenarbeit, weil zunehmend die Projektziele durch (mitunter groteske) Einzelinteressen ersetzt werden und die Entscheidungsfindung entsachlicht wird.
    Vielleicht ist es eine gute Metapher Scrum als Fahrbahnmarkierungen zu bezeichnen: Ein perfekter Fahrer braucht sie nicht, aber die Wirklichkeit sieht anders aus.

    1. Avatar von Miss Booleana
      Miss Booleana

      Ah ja, Chef-Scrum, verstehe. Bei uns auf Arbeit fiel da neulich mal der Begriff Bottom-Up-Agile-Management. Das ist dann die nochmals verschleiernde Bezeichnung …
      Dass die guten zuerst gehen ist auch eine Entwicklung, die ich miterleben musste, leider. Wenn man einen Priorisierungswilligen Kunden hat, dann muss das mit dem Budget in der Theorie ja eigentlich auch klappen. Das Problem ist oftmals wenn keiner den Hut für die Entscheidung aufhaben will. Zumindest habe ich die Erfahrung im Kundenumgang einmal gehabt ..

      Das mit der Transparenz schätze ich auch am meisten von den drei Säulen Inspektion, Adaption, Transparenz. Ich habe auch schon in Wasserfallprojekten gearbeitet und kann mir das eigentlich kaum noch vorstellen. Wenn ich an damals zurückdenke kenne ich eigentlich nur zwei Modi: fast nichts zutun und dann plötzlich Überstunden noch und nöcher. Total unausgeglichen. Und andererseits stets mit dem Gefühl das Ende der Nahrungskette zu sein und in quasi keine Entscheidungen involviert zu sein, sei es auch nur um die mitgeteilt zu bekommen. Aber ich habe auch schon glühende Reden pro Wasserfall gehört. Kommt also letzten Endes bei Allem wohl darauf an, ob es fair und passig für alle gehandhabt wird.
      Von daher finde ich die Metapher mit der Fahrbahnmarkierung super!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert