Читать книгу Agiler Kapitalismus - Timo Daum - Страница 15

Die agilen Methoden haben in den fast 20 Jahren seit ihrer Erfindung einen beeindruckenden Siegeszug erlebt. Zahlreiche Innovationen sind branchenweit unbestritten, dazu gehören die kontinuierliche Bereitstellung funktionierender Prototypen, kurze Entwicklungszyklen und standardisierte Testverfahren. Bertrand Meyer, Autor einer vielbeachteten Agilitätskritik, nennt »kurze Iterationen, kontinuierliche Integration neuer Features in bestehende Software sowie die Rolle des Product Owners«¹⁷ als in Fachkreisen generell akzeptierte Neuerungen. Doch es gibt auch Kritik.

Immer wieder stoßen agile Prozesse gegen eine Wand, wenn plötzlich doch starre Zeit- oder Budgetvorgaben von Kundenseite oder durch die Geschäftsleitung präsentiert werden. Der Entwickler Amir Yasin schreibt auf medium.com: »Die Realität von agile ist, dass [die Entwickler] immer noch auf unverrückbare Entscheidungen stoßen, die von Geschäftsleuten ohne wirkliches Verständnis der Technologie getroffen werden. Diese Entscheidungen werden dann den Entwicklern aufgebürdet. Das Endergebnis ist dasselbe wie bei Wasserfall, nur die Namen haben sich geändert.«¹⁸ David E., langjähriger Softwareentwickler, haut in die gleiche Kerbe: »Das Arbeiten in Sprints zerhackt langfristige Arbeiten und orientiert sich nur an kurzfristigen Zielen. Es erzeugt zusätzlichen Stress durch unnötige Deadlines (nach dem Sprint ist vor dem Sprint) und durch die künstliche Erschaffung von Konkurrenzsituationen zwischen den Beteiligten. Scrum befürwortet und fördert aktiv die Austauschbarkeit von Personen; alle sollen alles können, jeder soll wissen, dass er jederzeit ersetzbar ist.«

Die Anwendung von Frameworks, also konkreten Umsetzungsmethoden wie Scrum, können zu unnötigem Verwaltungsaufwand führen, wenn etwa bestimmte Formate wie Scrum Meetings um ihrer selbst willen abgehalten werden. Eine sklavische Befolgung vermeintlich eherner Regeln ist die Folge. Der erfahrene Programmierer Dirk R. benennt im Interview mit dem Autor die Tendenz: »In meiner Erfahrung ist der Prozess oft kleinteilig und bringt hohen Strukturierungsaufwand mit sich, der Prozess schützt aber das Team vor Willkür und bringt mehr Ruhe rein, als wenn man ›drauflos agiert‹.« Oft wird bemängelt, ein gewisser Scheuklappeneffekt stelle sich ein, die agilen Entwickler verlören vor lauter Tickets, Mikrotasks und Teamkommunikation die eigentlichen Projektziele aus den Augen. David E.: »Das Problem mit den Takten und dem begrenzten scope [etwa: Wahrnehmungsbereich] ist, dass der Horizont vieler Entwickler am Rand ihrer Kaffeetasse endet. Es ist die totale Verschulung mit Daily Standup und Hausaufgaben, die täglich abgefragt werden. Scrum ist wieder Mikromanagement, Entmündigung, Infantilisierung, Verschulung, Kontrollwahn.«

Agilität kann auch einschüchtern: »[F]rühere Ansätze werden als passé abgetan, verächtlich als ›Wasserfall‹ bezeichnet und der Eindruck hinterlassen, dass jeder, der sie unterstützt, unflexibel und ein Spießer ist«,¹⁹ merkt Bertrand Meyer an. Beim Scheitern agiler Projekte sind die Schuldigen dann schnell ausgemacht: Wenn es nicht klappt mit der Agilität, dann war das Team nicht agil genug, die Einzelnen zu konservativ, nicht wirklich committed. Der Blogger Amir Yasin kritisiert insbesondere Scrum für diese Mechanismen: »Die Hinzufügung des Daily Scrum stellt sicher, dass jeder, der als zu langsam wahrgenommen wird (ob dies zutrifft oder nicht), sofort heraussticht. Diese Art von Heizraumatmosphäre mag für einige großartig sein, aber für die meisten ist sie eine Quelle von erheblichem Stress und letztendlich von geringerer Produktivität. Dieser Druck ermutigt die Entwickler nicht, an die Zukunft zu denken, sondern nur dazu, etwas zusammenzuschustern, das gerade so eben funktioniert.«²⁰

Oftmals scheitern Organisationen an der richtigen Umsetzung der neuen Rollen. Dem Wirtschaftsinformatiker Ayelt Komus zufolge hapert es daran oft, denn »viele Product Owner [kommen] nicht mit dieser neuen Rolle zurecht, in der sie nur Ziele formulieren, die Details zur Umsetzung aber dem Team überlassen sollen. Auch die Arbeit in Sprints aufzuteilen ist für sie eine große fachliche Herausforderung.« Ein großes Problem bilde oft das Umfeld: »Besonders in großen Unternehmen gibt es unzählige Vorgaben, Regelungen und Prozesse, die auf die alten, plangetriebenen Verfahren ausgerichtet sind. Das verträgt sich schlecht mit Agilität.«²¹ Die größten Widerstände in den Organisationen entstünden nicht bei den Entwicklerinnen bzw. den Teams selbst, sondern beim mittleren Management, fallen doch bei konsequenter Implementierung in traditionell hierarchischen Organisationen gleich mehrere Leitungsebenen weg. Daher »sieht das mittlere Management die Umstellung oft als Bedrohung. Viele haben Angst davor, nicht mehr gebraucht zu werden«, betont Komus in seiner Einschätzung der agilen Implementierung.

Von nur an der Oberfläche eingeführten Methoden, die klassischen Projektvorgaben einfach übergestülpt werden, berichtet der Soziologe Andreas Boes und spricht vom »Potemkinschen Scrum«, das Risiko »verbrannter Teams« entstehe, die ohne Empowerment dem Takt schutzlos ausgeliefert sind.²² Gerade die Teamarbeit kann zur extremen exposure der oder des Einzelnen führen, wer zurückbleibt, ist in Echtzeit als Schlendrian oder Versagerin identifizierbar und möglichem peer group pressure (Gruppenzwang) ausgesetzt, digitale Trackingtools für die agilen Arbeitsschritte verstärken diese Tendenz noch. Der Soziologe Tobias Kämpf sieht ein »System permanenter Bewährung« am Werk.²³ Der Blogger und Technologieexperte Kurt Cagle meint, Agilität sei schlicht zur Religion geworden, er vergleicht Daily Scrum Meetings mit Messen, in denen der Scrum Master die Beichte abnimmt und die Gläubigen Abbitte leisten: »Ich gelobe, drei Module abzuarbeiten, oh Scrum Master, denn ich habe gesündigt und den Teamdurchschnitt gesenkt.«²⁴

Den Verdacht, dass aus story points schnell Zeiteinheiten bzw. Geldeinheiten werden, spricht Yasin aus: In den Köpfen der Verantwortlichen würden diese fast immer zu »Zeiteinheiten« und dazu eingesetzt, Teams untereinander zu vergleichen oder ihnen Vorhaltungen zu machen, warum »ihre Geschwindigkeit abfiel, obwohl die Zahlen als willkürliche Werte ohne Einheiten begannen«.²⁵ Und Anne V., CEO eines Start-ups in Berlin, erzählt im Interview: »Man kann auch mal zwei Teams gegeneinander antreten lassen: Einmal hat ein Team geschaut, kriegen wir einen Sprint auch in einer Woche hin, auf die doppelte Geschwindigkeit kommen, das hat so einen Sportaspekt, Hackatonethik, 24 Stunden durchpowern und dann ein geiles Ergebnis haben, sie haben es dem Backendteam so richtig gezeigt.«

Was denken die Manifest-Autoren selbst über ihren fast zwanzig Jahre zurückliegenden Impuls für die Branche? Durch die Bank empfehlen sie, Methoden sorgfältig auszuwählen und an die konkreten Situationen anzupassen, und nicht sklavisch »nach Lehrbuch« vorzugehen. Agilität sei keine Patentlösung, geben sie in einer wissenschaftlichen Befragung aus dem Jahre 2018 zu Protokoll. Gleichzeitig drücken sie ein gewisses Unbehagen über eine Verschulung der agilen Prinzipien aus und rümpfen die Nase angesichts einer blühenden Berater- und Coachinglandschaft und einer »Zertifizierungs- und Kommerzialisierungsblase«.²⁶