Scrum: Vom Versuch, Software auf linke Weise schreiben zu wollen

Ich habe schon vor Jahren gesagt, dass das nicht funktioniert.

Seit 2012 hatte ich mit neuen Softwaremethoden zu tun. Nannte man „Agile“ und das bevorzugte Prozedere, um das alles zu erreichen, „Scrum“.

Ich finde es, obwohl ich auch Vorteile sehe, auf die ich unten zurückkomme, schrecklich. Nervig, menschenschinderisch, teils kontraproduktiv.

Glücklicherweise war ich immer nur Beobachter, nie selbst Teilnehmer. Weil Security. Ich habe ihnen zugesehen, ich habe ihnen gesagt, was sie tun und was sie lassen sollen, Fragen beantwortet, Leute geschult, angeleitet, und auch so manchen Tadel verteilt. In fast ausschließlich allen Fällen reichte einer der Kategorie „Du, Du, Du!“ mit erhoben wackelndem Zeigefinger und väterlichem Blick. Also im übertragenen Sinne. Ertappt zu werden bereits Strafe genug.

Und mich oft gewundert, was die da treiben. Wo ich mir dachte, die Leute sind nett, aber was die miteinander machen, ist nicht nett. Sie schrieben Anforderungen und Ideen in ein sündhaft teures Ticket-System, das mir nie so richtig gefiel, die immer mit „Ich als X wünsche mir…“, wobei X dann Anwenderin, Auftraggeber oder sowas heißen musste. Dann machen sie Sprints, also immer zweiwöchige Arbeitsstücke, in denen sie irgendwas davon umsetzen, dafür Punkte bekommen und dann implementieren. DevOps und so. Das ganze begleitet von sozialen Gruppentänzen, wie morgendlichen Standups, bei denen man, und ich habe nie verstanden, warum, nicht sitzen darf, und alle wände mit bunten Pappkärtchen und Haftnotizen vollgepflastert. Und dazu dann „Scrum-Master“, die eigentlich nicht Chef sein sollen, aber irgendwie Chef werden, obwohl sie dafür eigentlich oft nicht qualifiziert sind und grundsätzlich eher so als eine Art Teamsekretär eingestellt wurden, mitunter sogar Geisteswissenschaftler.

Und dann setzen sie sich enorm unter Stress, und immer wenn sie „Sprintwechsel“ haben, haben sie Druck und schlechte Laune und bitten nachdrücklich, dass ich Schulungen doch jeweils in der anderen Woche halte. Als ob sie alle gleichzeitig ihre Tage hätten, nur eben alle zwei Wochen.

Und ein enormer Teamstress.

Einer hat das mal bei mir versucht.

Obwohl ich eigentlich Aufsicht hatte und nicht produktiv sein durfte, weil Kontrolle und Produktion personell strikt getrennt sein mussten, habe ich mal ein angebranntes und eigentlich nicht mehr termingerecht zu machendes, aber überaus wichtiges Projekt im Security-Bereich an mich gezogen und in einer mehrtätigen eigenmächtigen Home-Office-Aktion (lange vor Corona) gerettet und im Alleingang gemacht. Da kam tatsächlich einer an und wollte mich Scrum-Managen, dass ich des morgens da antanze und im Stehen irgendwas zum Fortschritt beichte und bunte Karten beschrifte, als wollte er mich nach Art von Scientology auditieren. Dem habe ich was Exothermes erzählt. Er möge mich gefälligst in Ruhe arbeiten lassen, ich hätte gerade keine Zeit für Sozialtänze, sondern eine Frist einzuhalten, weil Auditoren kämen. Ich habe dann alleine hingestellt, was ein Team nicht konnte, weil diese Team-Mechanismen es daran hinderten. Schon vorher, aber besonders nach dieser Kostprobe war ich so froh, nicht in einem dieser Scrum-Teams zu sein. Eigentlich müsste man Scrum mit Hektik und Stress übersetzen.

Versteht mich nicht falsch. Ich sehe durchaus auch Vorteile in dieser Vorgehensweise, die aber eher Seiteneffekte und Nebenwirkungen sind. Weil durch diese Hektik und diesen hohen Arbeitsdruck die Software ständig und immer wieder neu compiliert und getestet werden muss, haben sich daraus recht gute Methoden entwickelt, Software automatisiert und vor allem unter kontrollierten und wiederholbaren Bedingungen zu produzieren. Früher nämlich war das so eine Art Hexenwerk. Entwickler von Microsoft erzählten mir vor rund 20 Jahren auf einer Konferenz mal, dass die Entwickler des Betriebssystem-Kernels und von Exchange keinerlei Chance hätten, den Code der jeweils anderen zum Produkt zu compilieren. Viel zu kompliziert, Geheimwissen hochbezahlter Entwickler.

Inzwischen aber ist es längst Standard, je nach verwendetem Verwaltungstool, es gibt so ein paar Stilarten, zur Software auch noch eine abstrakte Beschreibung, eine Art Skript zu schreiben, mit der ein zentraler Server die Software automatisch compilieren kann – und wo er die Tools dafür herbekommt. Dass das nicht mehr nur auf dem Notebook des Kollegen X funktioniert, weil der die Tools und Einstellungen hat. Und auch, Software automatisiert zu installieren. Wenn man das nämlich nicht nur einmal im Jahr zu Weihnachten macht, sondern alle paar Tage, automatisiert man das. Dazu musste die Software auch getestet werden, und weil man soviel gar nicht testen kann, erstellt man automatische Tests, die bestanden werden müssen, bevor man die Software durchlässt. Im optimalen Fall ändert man nur was am Quelltext, checkt das ein, und der ganze Rest, die gesamte Software, die davon abhängt, neu zu erstellen, zu testen und installationsfertig zu machen (oder zu installieren), und dann eben auch sofort anzuzeigen, ob sie überhaupt sauber compiliert und alle Tests besteht.

Sowas hat große Vorteile mit sich gebracht, aber ich sehe sie eben auf technischer Ebene. Diese Art und Weise, ein Team zu hetzen, hat mich nie überzeugt. Und vor allem: Ich halte es für kontraproduktiv. Es gibt auch die Möglichkeit, Aufgaben und Projekte über mehr als einen Sprint (=2-Wochen-Zyklus) zu verteilen, aber die sind unbeliebt, weil die Teams ja Punkte sammeln müssen und sich deshalb immer die kleinsten Aufgaben raussuchen, die sich in zwei Wochen durchbringen können, oder notfalls einfach selbst machen, indem sie sich eine User-Story schreiben (Ich als Handy-Nutzerin wünsche mir…)

Und dann gab es da noch die höchstbezahlten Gurus, denen man einen Haufen Geld hinterherwarf, damit sie mal ein paar Tage vorbeikommen und einen an ihrer tiefen Weisheit teilhaben lassen, wie Scrum und so zu laufen haben. (Ich hielt sie nicht für so weise, eher für Aufschneider und Schlangenölhändler, aber es war ja auch nicht mein Geld.)

Oder anders gesagt: Ich bin nicht so sonderlich gut auf den Scrum-Zirkus zu sprechen.

Was mir daran vor allem auffällt, ist, dass das ganze Konstrukt ziemlich links zu sein scheint, weil man den Leuten so eine Art Basisdemokratie aufzwingt und einen enormen Verwaltungsaufwand und so feste wie alberne Verhaltensverfahren und -abläufe, um das alles teamorientiert und nicht chefgesteuert zu machen. Alles wird irgendwie so im Kollektiv geregelt. Es erinnert mich stark an die endlosen, ineffizienten und meist nutzlosen Selbstverwaltungsorgien im Studentenwohnheim. Und dazu dann zwangsweise Jobs für Quereinsteiger ohne Berufskenntnisse, jedes Team muss da noch einen Scrum-Master mit(er)tragen. Als ob es geradezu dafür gebaut wäre, Geisteswissenschaftler in der Softwareerstellung unterzubringen. So eine Art sozialistisches Softwarekollektiv. Irgendwann sind die Leute mit den Nerven fertig. Man presst viel Arbeitsleistung aus ihnen heraus, aber es kommt im Ergebnis nicht so wirklich viel dabei heraus. Weil viel Energie für diese Gesellschaftstänze drauf geht. Und es Leute wie mich gibt, die sich etwas veralbert vorkommen, wenn sie mit bunten Pappkärtchen an den Wänden arbeiten und jeden Morgen beichten sollen wie bei den anonymen Alkoholikern.

Es hat aber auch etwas mit dem Zeitgeist und der Generation zu tun. Wer bis zum Studienende in so einem kindergartoiden Umfeld steckte, der ist dafür empfänglicher und findet das normaler.

Ein Hauptproblem ist aber, dass sich die Teams als Arbeit raussuchen, was sie machen wollen und was ihnen schnell und zuverlässig Punkte bringt. Das führt dazu, dass Probleme, Bugfixes, wichtige, aber schwierige Probleme oft sehr lange liegen bleiben, weil es keiner angeht. Und weil es eben auf gründliche Planung verzichtet, sondern eben „agil“ darauf reagieren soll, dass der Kunde, der Auftraggeber ständig was anderes will und es sich anders überlegt. Man könnte sagen, Scrum ist das Konzept, Software so zu bauen wie Berlin den Flughafen BER gebaut hat: Einfach los und ständig ändern und rummachen, ohne einen langfristigen Plan zu haben. Einfach immer nur hinterherrennen, wo irgendwer irgendwas will.

Man sollte sich aber bewusst machen, dass solche linken Dinge wie „Code of Conduct“ ähnliche Wurzeln und Hintergründe haben wie Scrum und Agile Entwicklung, die als Stein der Weisen hingestellt wurden.

Auf Golem ist ein Text erschienen, der eine Übersetzung aus dem Englischen eines Textes von Al Tenhundfeld ist: 20 Jahre Agiles Manifest: Die gescheiterte Rebellion

Man stellt langsam fest, dass die Herangehensweise ihre Verheißungen nicht erfüllt.

Das Agile Manifest ist dieses Jahr 20 Jahre alt geworden – und es gibt zwei offensichtliche Fakten:

Das Label “Agile” hat sich durchgesetzt; niemand möchte als “nicht-agil” bezeichnet werden.

Und: Agile Methoden, wie sie heute praktiziert werden, bleiben weit hinter den revolutionären Ideen ihrer Begründer zurück.

Ursprünglich dachte man an sowas:

“Wir haben festgestellt, dass die Rolle des Projektleiters bei komplexer, kreativer Arbeit kontraproduktiv ist. Die Denkweise eines Projektleiters, repräsentiert durch den Projektplan, schränkt die Kreativität und Intelligenz aller anderen Projektbeteiligten auf die des Plans ein, anstatt die Intelligenz aller zur bestmöglichen Lösung der Probleme zu nutzen.”

(Ken Schwaber, Unterzeichner des Manifests und Scrum-Mitbegründer)

Stimmt sogar. Aber eben nur dann, wenn die Projektbeteiligen kreativ und intelligent sind, und das sind auf dem heutigen Arbeitsmarkt die wenigsten. Und bei denen, bei denen das der Fall ist, kann diese Teamstruktur ihn sogar herunterziehen.

Scrum Master hatten damals so gut wie keine Befugnisse und keine Stimmrechte bei Problemen. Sie waren dienende Anführer, die das Team abschirmten und Blockaden aus dem Weg räumten, aber das Team nicht leiteten. Bei XP war es ähnlich. Wenn ich mich recht erinnere, gab es bei XP ursprünglich Tracker und Coaches, die eine ähnliche, unterstützende Aufgabe hatten.

Das war dann aber auch der Konstruktionsfehler, weil diese Scrum Master oft nicht über die Befähigung verfügten, um „Anführer“ zu sein, aber dann chefig rüberkamen.

Letztlich war das Ding erfunden worden, um sich gegen dumme Manager abzuschotten, aber man hatte vergessen, Maßnahmen gegen die eigene Dummheit zu treffen.

In gewisser Weise war das Konzept der Agilität eine Graswurzel-Arbeiterbewegung. Sie begann mit den Praktikern vor Ort und wurde nach oben ins Management getragen. Wie konnte das überhaupt gelingen?

Zum Teil, weil die Zahl der Entwickler und ihr Wert für die Unternehmen stiegen und sie an Einfluss gewannen. Wichtiger noch war aber meiner Meinung nach, dass die traditionelle Wasserfallmethode einfach nicht mehr funktionierte. Software wurde immer komplizierter, das Arbeitstempo immer höher und die Benutzer wurden immer anspruchsvoller, so dass es unmöglich wurde, alles im Voraus zu planen. Die Umstellung auf eine iterative Entwicklung war logisch, wenn auch ein bisschen beängstigend für die Manager, die es gewohnt waren, alles zu planen.

Es war so eine Art gewerkschaftlicher Ansatz, Arbeiterrechte in einem Umfeld immer schwerer zu beherrschender Software und immer inkompetenterer Auftraggeber klarzukommen. Man kann sich das leicht an solchen Produkten wie Facebook oder Twitter vorstellen. Einen festen Plan, ein Ziel, wo es eigentlich hingehen solle, gibt es eigentlich nicht. Stattdessen ein Geprassel von Leuten, die sich tagesaktuell über irgendwas beschweren, irgendwas haben wollen. Mach mal da noch einen Button hin. Ich hätte gern, dass das Menü da noch dies und jenes kann. Der Kundenservice hat noch irgendein Problem gefunden. So in der Art.

Innerhalb von nur fünf Jahren wurde Agile von einer Methode, von der man zwar gehört hatte, die aber eher nicht verwendet wurde, zu einer, die jeder nutzte. 2005 wechselte ich den Job und weiß noch, dass mein Wissen über Agile und TDD damals ein Alleinstellungsmerkmal war. 2010 wurde dann schon vorausgesetzt, dass moderne Softwareteams in irgendeiner Form agil arbeiteten. Zumindest galt das für meine Job-Blase in der Beratungswelt; große Unternehmen bewegen sich dagegen immer langsamer.

Anders gesagt: Eine Mode-Erscheinung.

Und die hat nicht funktioniert:

Wie bei vielen Revolutionen ging es auch mit der Agilität leider nicht so weiter, wie die Gründer sich das vorgestellt hatten.

• Es hat sich gezeigt, dass das Konzept, Menschen und Interaktionen in den Vordergrund zu stellen, schwierig zu verkaufen ist. Prozesse und Tools lassen sich viel einfacher verkaufen.
• Es hat sich gezeigt, dass funktionierende Software schwieriger zu produzieren ist als unrealistische Pläne und Unmengen an Dokumentation.
• Es hat sich gezeigt, dass die Zusammenarbeit mit Kunden Vertrauen und Sensibilität erfordert, was in einem geschäftlichen Umfeld nicht immer gegeben ist.
• Es hat sich gezeigt, dass die Reaktion auf Veränderungen oft davon bestimmt wird, dass Führungskräfte das Gefühl haben möchten, die Kontrolle zu haben. Und dass sie immer noch das (legitime) Bedürfnis haben, langfristige Pläne für ihr Unternehmen zu machen.

Es hat sich gezeigt, dass Agilität, wenn sie schlecht umgesetzt wird, sich oft wie Chaos anfühlt.

Das heißt nicht, dass die vier Werte falsch sind. Es bedeutet nur, dass es Kraft kostet, alles richtig zu machen, und dass es den Mut braucht zu akzeptieren, dass Software eben manchmal chaotisch und kompliziert ist.

Wir können aber nunmal nicht überall chaotische Software akzeptieren. Das funktioniert eben nicht oft, zumal Chaos, ist es erst mal da, unweigerlich zunimmt.

“Die agile Bewegung ist nicht gegen Methodologie, viele von uns wollen dem Wort Methodologie sogar wieder Glaubwürdigkeit verleihen. Wir wollen ein Gleichgewicht herstellen. Wir befürworten Modellierung, aber nicht, um ein Diagramm in einem verstaubten Firmenarchiv abzulegen. Wir begrüßen Dokumentation, nicht jedoch Hunderte Seiten nie gepflegter und selten genutzter Wälzer. Wir planen, erkennen aber die Grenzen der Planung in einem turbulenten Umfeld. All jene, die Befürworter von XP, Scrum oder einer anderen agilen Methodik als ‘Hacker’ bezeichnen, kennen weder die Methodik noch die ursprüngliche Definition des Begriffs ‘Hacker’.”

(Jim Highsmith: Geschichte des Agilen Manifests)

Leute, die vor 30, 40 Jahren Informatik gelernt haben, wie ich, würden einfach sagen, dass sie Top-Down ablehnen und meinen, dass Bottom-Up die Methode der Wahl wäre, aber sie kein Up geplant haben sich einfach davon überraschen lassen, wo sie damit rauskommen.

Die Branche ist mittlerweile überschwemmt worden von Tool-Anbietern, Prozessberatern und Experten, die Versprechungen machen, die niemals eingehalten werden können. So sind wir bei SAFe und Scaled Scrum und all den anderen Agile-Varianten für Unternehmen gelandet.

Diese Frameworks wurden nicht in böser Absicht entwickelt und im richtigen Kontext haben sie wahrscheinlich sogar einen gewissen Wert. Aber ich würde sie nicht als “agil” bezeichnen. Der Versuch, eine Methodik zu skalieren, die sich auf Einzelpersonen und Interaktionen konzentriert, führt unweigerlich zu Problemen – und untergräbt den ursprünglichen Wert der Methodik.

Scrum ist eben vor allem auch eines: Ein Unternehmensberater-Ding. Viele Leute haben viel Geld damit verdient, den Firmen etwas einzureden und sie darin zu „coachen“.

Warum hat das funktioniert? Weil wir so schrecklich viele unfähige Managements haben, die glauben, sie könnten ihre Probleme lösen, indem sie den hippsten Berater einkaufen. Und weil wir einen Arbeitsmarkt mit Fachkräftemangel haben, in dem man Leute nur bekommt, indem man ihnen die neusten Moden anbietet.

Also: Schluss mit Agile?

So kommen wir also zu diesem berühmten Beitrag von Ron Jeffries, dem Unterzeichner des Manifests und Miterfinder von XP, aus dem Jahr 2018.

Entwickler sollten Agile aufgeben

“Wenn ‘agile’ Ideen schlecht umgesetzt werden, führen sie oft zu mehr Konflikten mit den Entwicklern, weniger Zeit für die Arbeit, höherem Druck und der Forderung, ‘schneller’ zu arbeiten. Das ist schlecht für die Entwickler und letztlich auch für das Unternehmen, denn eine schlechte Umsetzung von ‘Agile’ führt in den meisten Fällen zu weitaus mehr Fehlern und einem viel langsameren Fortschritt, als man erreichen könnte. Oft verlassen gute Entwickler solche Organisationen, was das Unternehmen weniger effektiv macht, als es vor der Einführung von ‘Agile’ war.”

Genau das, beobachte ich seit Jahren. Hektik, Arbeitsdruck, Teamstreit, keiner kann sich mal hinsetzen und etwas einfach mal für gewisse Zeit systematisch bauen und implementieren.

Und so kommen wir auch zu dem berühmten Beitrag von Dave Thomas, Unterzeichner des Manifests und Mitbegründer von Pragmatic Programming, aus dem Jahr 2014.

Agile ist tot (lang lebe die Agilität)

“Das Wort ‘agil’ wurde bis zu einem Punkt ausgehöhlt, an dem es praktisch bedeutungslos ist – und das, was als agile Gemeinschaft gilt, scheint größtenteils eine Plattform für Berater und Anbieter von Dienstleistungen und Produkten zu sein … Mit der steigenden Popularität des Manifests wurde das Wort ‘agil’ zu einem Magneten für jeden, der eine Idee vorzubringen, Stunden in Rechnung zu stellen oder Produkte zu verkaufen hatte. Es wurde zu einem Marketingbegriff. Daher denke ich, dass es an der Zeit ist, das Wort ‘Agile’ in den Ruhestand zu schicken.”

Ja. Sowas wie von der Leyen mit McKinsey, nur etwas kleiner.

Und dann kommen die bei dem an, was mir schon lange auffiel und weshalb ich immer so froh war, nicht selbst in so einem Scrum-Team zu stecken (und vermutlich hält man sowas sowieso nur aus, wenn man unter 40 ist):

Das eigentlich Traurige daran ist für mich, dass junge Entwickler Agile ablehnen und als Mittel des Managements betrachten, ihren Entwicklern unrealistische Versprechungen abzuringen und sie zu haufenweise Überstunden zu zwingen. Ich verstehe das. Die einzige Agilität, die sie je kennengelernt haben, ist Agilität als Kontrollmechanismus und nicht als Werkzeug der Selbstermächtigung, das sie mit Freude annehmen könnten. Ich hoffe aber, dass uns der Anstoß zu Diskussionen über die Geschichte und die ursprüngliche Vision von Agilität dabei helfen kann, uns zu erinnern, wie es eigentlich laufen sollte.

Die gute Nachricht bei all dem ist, dass die Grundsätze des Agilen Manifests heute genauso klug und wichtig sind wie vor 20 Jahren. Selbst vermeintliche Abtrünnige wie Jeffries und Thomas sehen das so.

Es ist letztlich dasselbe wie der Sozialismus: Es ist das theoretische Versprechen, dass die Arbeiterschaft selbst die Macht hat, und man die drakonischen Firmeninhaber los wird, und man endlich zur Selbstverwirklichung kommt, bei Licht betrachtet führt es aber nur zu extremer Kontrolle, Terminstress und endlosen Überstunden.

Anders gesagt: Kleiner Sozialismus scheitert wie großer Sozialismus.

Ich hoffe, dass wir durch das eingehende Betrachten der Gründungsprinzipien aus der Vergangenheit lernen können und, um es mit den Worten von Dave Thomas zu sagen, unsere Agilität bewahren können, selbst wenn wir uns entscheiden, “Agile” aufzugeben.

Hört sich an, wie die Hoffnung, auch nach dem Zusammenbruch der DDR den Sozialismus noch gut zu finden.