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“

… 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.

Der „Sprint 0“

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! 🙂 )

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. 🙂