Als „agil“ aufhörte, agil zu sein

Der langsame, schmerzhafte Tod von Agile und Jira

Was ursprünglich als Befreiung gedacht war, hat sich in sein Gegenteil verkehrt: Die agile Methodik, einst gefeiert für ihren innovativen Ansatz, ist heute oft zu einem starren Regelwerk degradiert. Konzipiert als Werkzeug zur Förderung von Anpassungsfähigkeit und Wertschöpfung in der Softwareentwicklung, präsentiert sich Agilität heute vielerorts als schwerfälliger, überregulierter Prozess, der Teams eher behindert als unterstützt. Im Zentrum dieser Problematik steht das Projektmanagement-Tool Jira, das ironischerweise zum Symbol für jene Probleme geworden ist, die agile Methoden eigentlich beseitigen sollten.

Jeder, der in der Technologiebranche tätig ist, kennt die typischen Klagen: Die Entwicklungszyklen werden länger, Technikteams wachsen unverhältnismäßig, das Management erfordert immer mehr Hilfsmittel, und die Zahl der tatsächlich programmierenden Mitarbeiter sinkt stetig. Die Agilität hat sich von einem Hilfsmittel zu einem System bürokratischer Kontrolle entwickelt.

Dieser Beitrag beleuchtet, wie aus Agilität Starrheit wurde und wie Jiras Popularität zum Niedergang der agilen Grundprinzipien beigetragen hat. Vor allem aber zeigt er Wege auf, diesem Kreislauf zu entkommen.

Die ursprüngliche Vision: Ein Neuanfang im Jahr 2001

Als 2001 das Agile Manifest veröffentlicht wurde, bedeutete dies eine willkommene Erneuerung für die Softwareentwicklungsgemeinschaft. Die herkömmliche Wasserfall-Methode mit ihren unflexiblen Entwicklungsphasen (Anforderungsanalyse, Design, Programmierung, Tests und Veröffentlichung) hatte Projekte verlangsamt und die Reaktionsfähigkeit auf Veränderungen eingeschränkt.

Agilität versprach einen neuen Ansatz – schnellere Iterationen, intensivere Zusammenarbeit und kontinuierliche Bereitstellung funktionierender Software. Sie war unkompliziert, anpassbar und flexibel. Teams konnten rasch handeln, häufig liefern und auf Kundenfeedback unmittelbar reagieren. Entwickler schätzten die Einfachheit und Wirksamkeit der agilen Kernprinzipien:

• Menschen und Interaktion vor Prozessen und Werkzeugen
• Funktionierende Software vor umfassender Dokumentation
• Kundenkooperation vor Vertragsverhandlungen
• Reaktion auf Veränderung vor strikter Planbefolgung

Diese Ideen förderten kleine, selbstorganisierte Teams, die schnell Software produzieren und bei Bedarf ihren Kurs ändern konnten. Agilität sollte Entwicklern die Kontrolle zurückgeben und den Fokus auf Mehrwertschaffung legen, während Ablenkungen durch überflüssige Dokumentation und Prozesse minimiert werden sollten.

Doch mit dem Erfolg der agilen Methodik ging etwas schief.

Der Jira-Kult: Als Agilität zur Religion wurde

Agilität entwickelte sich rasch von einer Methodik zu einer Bewegung. Ganze Unternehmen begannen, agile Ansätze zu übernehmen. Es war nicht länger ein Framework für Softwareentwicklung, sondern wurde zum Standardvorgehen für sämtliche Unternehmensabläufe. An diesem Punkt begann der langsame, schmerzhafte Niedergang der Agilität.

Mit der zunehmenden Verbreitung agiler Methoden im großen Maßstab benötigten Unternehmen Möglichkeiten, die wachsende Komplexität bei der Verfolgung von Sprints, Backlogs und Aufgaben zu bewältigen. Hier kam Jira ins Spiel – ein Projektmanagement-Tool, das die perfekte Lösung zu sein schien. Mit Jira konnten Unternehmen agile Sprints verwalten, Tickets erstellen, Aufgaben zuweisen und den Prozess durch Boards und Burndown-Charts visualisieren.

Doch bald wurde aus einem Tool zur Unterstützung der Agilität das Framework selbst. Agilität drehte sich nicht mehr um Flexibilität oder Geschwindigkeit. Stattdessen ging es um die Verwaltung von Jira-Tickets, das Ausfüllen von Sprint-Boards und das Abhaken von Punkten auf Kanban-Tafeln. Anstatt ein Hilfsmittel für die Entwicklung zu sein, wurde Jira zum Maßstab, an dem agile Teams gemessen wurden.

Von leichtgewichtig zu aufgeblähter Bürokratie

Agilität sollte Teams helfen, sich auf die Bereitstellung funktionierender Software zu konzentrieren. Doch statt den Fokus auf Software zu legen, konzentrierten sich Teams zunehmend auf den Jira-Prozess selbst. So zerfiel die agile Vision langsam:

• Mehr Meetings: Agile Besprechungen wie Daily Stand-ups, Sprint-Planungen, Reviews und Retrospektiven sollten die Dynamik aufrechterhalten. Heute sind sie zu Zeitfressern geworden, die Entwicklerstunden verschlingen. Die Planung von Sprints dauert mittlerweile länger als deren Durchführung. Das tägliche Stand-up hat sich in eine Mikromanagement-Sitzung verwandelt, in der Teammitglieder jede Minute rechtfertigen müssen. Entwickler verbringen mehr Zeit damit, ihren Fortschritt zu berichten, als tatsächlich Fortschritte zu erzielen.
• Mehr Tools: Jira und andere agile Werkzeuge führten mehr Komplexität ein, als sie lösten. Projektmanager und Scrum Master begannen, sich auf eine ständig wachsende Palette von Tools zu verlassen, um Geschwindigkeit, Aufwand und Fortschritt zu verfolgen. Dies führte zu einer aufgeblähten Technologie-Infrastruktur voller Integrationsprobleme und dem ständigen Bedarf, Tickets zu aktualisieren.
• Weniger Programmierung: Obwohl Agilität Entwicklern ermöglichen sollte, sich auf das Programmieren zu konzentrieren, verbringen sie heute einen Großteil ihrer Zeit mit der Verwaltung von Jira-Boards, der Aktualisierung von Tickets, der Teilnahme an Meetings und der Bewältigung administrativer Aufgaben. Es ist nicht ungewöhnlich, dass die eigentliche Entwicklung zwischen endlosen agilen Kontrollpunkten eingequetscht wird, sodass wenig Zeit für bedeutsamen Fortschritt bleibt.

Wann wurde Agilität zur Pflicht?

Vielleicht die heimtückischste Entwicklung der Agilität ist, wie sie aufhörte, eine Methodik zu sein, und stattdessen zu einer Unternehmensreligion wurde. Was einst ein optionaler Weg zur Softwareentwicklung für bestimmte Projektarten war, ist jetzt ein Pflichtansatz für alle Softwareteams – ob passend oder nicht.

Die Einheitslösung für alles

Agilität war ursprünglich für Teams gedacht, die schnell iterieren mussten, wie Startups und Technologieunternehmen, die kundenbezogene Software entwickeln. Doch mit der Verbreitung agiler Methoden wurden sie zur Einheitslösung für jede Organisation und jedes Projekt, unabhängig von Branche, Produkt oder Teamgröße. Selbst Teams, die besser für Wasserfall oder hybride Ansätze geeignet wären, müssen jetzt agil arbeiten, weil es als „Best Practice“ gilt. Anstatt ein flexibles Framework für iterative Projekte zu sein, ist Agilität zu einer Zwangsjacke für Teams geworden, die nicht in zweiwöchigen Zyklen iterieren müssen oder wollen.

Kommando und Kontrolle durch Jira

Jira ist insbesondere zu einem Kontrollinstrument geworden, nicht zu einem Kollaborationswerkzeug. Viele Manager messen die Leistung von Entwicklern heute an der Anzahl der erledigten Jira-Tickets und nicht am tatsächlichen Projektfortschritt. Metriken wie „Velocity“ und „Story Points“ sind zu Selbstzwecken geworden, oft ohne Rücksicht auf die Qualität oder Wirkung der geleisteten Arbeit. Es ist üblich geworden, dass Teams das System manipulieren, indem sie Schätzungen aufblähen oder Aufgaben unnötig aufteilen, nur um willkürliche Ziele zu erreichen.

Dabei haben sich Entwickler vom eigentlichen Zweck ihrer Arbeit entfernt. Der Geist der Zusammenarbeit, den Agilität inspirieren sollte, wurde durch die Angst ersetzt, auf Jira-Boards zurückzufallen.

Wo bleibt die Agilität?

Die Ironie ist offensichtlich: Agilität, eine Methodik zur Förderung von Veränderung und Anpassungsfähigkeit, ist zu einem der am wenigsten anpassungsfähigen Systeme geworden. Teams werden oft bestraft, wenn sie vom Jira-gesteuerten Prozess abweichen, und Agilität hat sich zu einem Fließband repetitiver Aufgaben und administrativer Schritte entwickelt. Das Kernprinzip des Agilen Manifests, „auf Veränderung zu reagieren“, ging zugunsten von vorhersehbaren, fabrikähnlichen Arbeitsabläufen verloren.

Ist es Zeit, Agilität (und Jira) aufzugeben?

Angesichts der weiten Entfernung von Agilität und Jira von ihren ursprünglichen Zielen stellt sich die Frage: Ist es Zeit, sie ganz aufzugeben? Hier sind die Gründe, warum eine wachsende Zahl von Entwicklern und Managern dies befürwortet.

Inkompatibilität mit Innovation

Die ständigen Kontrollpunkte, Planungen und Sprints hindern Teams daran, tief in komplexe Probleme einzutauchen. Agilität mag gut für inkrementelle Verbesserungen oder Fehlerbehebungen funktionieren, aber wenn es um bahnbrechende, innovative Entwicklung geht, steht sie oft im Weg. Wahre Innovation erfordert Raum für Versuch und Irrtum, Zeit zur Reflexion und die Freiheit, sich ohne Unterbrechung zu konzentrieren – nichts davon bieten agile Sprints.

Jiras Auswirkungen auf die Teammoral

Wenn Sie jemals einen Entwickler beobachtet haben, der nach einem langen Programmiertag Jira-Tickets aktualisiert, haben Sie wahrscheinlich gesehen, wie die Lebensfreude aus seinen Augen schwindet. Der sich wiederholende Zyklus des Erstellens von Tickets, Zuweisens von Schätzungen, Aktualisierens des Status und der Teilnahme an Meetings fordert seinen psychischen Tribut. Jira und andere agile Tools haben Entwickler eher zu Aufgabenverwaltern als zu Problemlösern gemacht. Für viele ist die Arbeit mit Jira das Gegenteil einer kreativen, innovativen Umgebung.

Das Aufkommen neuer Methodologien

Es ist daher nicht verwunderlich, dass sich viele Teams neuen Alternativen zuwenden. Shape Up, ein von Basecamp eingeführtes Framework, bietet längere Zyklen (sogenannte „Wetten“) und ermöglicht eine tiefgreifendere Problemlösung. Lean-Startup-Methodologien betonen schnelles Prototyping und Lernen ohne die Starrheit von Agilität. Und Kanban, das sich auf kontinuierliche Bereitstellung konzentriert, wird von Teams übernommen, die in ihrem eigenen Tempo arbeiten möchten, ohne den Druck von Sprint-Deadlines.

Wie befreien wir uns vom agilen Kult?

Wie können wir uns also vom Würgegriff der Agilität und Jira befreien? Hier sind einige zu erwägende Schritte:

Hybriden (dualistischen) Ansatz übernehmen

Anstatt starr an Agilität oder einer anderen einzelnen Methodik festzuhalten, sollten Teams die Freiheit haben, einen hybriden Ansatz zu wählen, der am besten zu ihrem spezifischen Projekt passt. Nicht alle Projekte müssen in zweiwöchige Sprints unterteilt werden. Nicht alle Teams müssen tägliche Stand-ups abhalten. Die Freiheit, Elemente aus verschiedenen Methodiken zu kombinieren, ermöglicht größere Flexibilität und Kreativität.

Fokus auf Ergebnisse, nicht auf Prozesse (Wertschöpfung)

Hören Sie auf, Erfolg an der Anzahl erledigter Jira-Tickets oder der Teamgeschwindigkeit zu messen. Konzentrieren Sie sich stattdessen auf die tatsächlichen Ergebnisse, die dem Kunden geliefert werden. Sind die Benutzer zufriedener? Ist das Produkt besser? Wenn nicht, kann keine Anzahl von Jira-Tickets Sie retten.

Reduzierung von Meetings und Bürokratie

Es gibt keinen Grund, fünf agile Zeremonien pro Sprint zu haben, wenn sie nicht dem Team dienen. Vermeiden Sie unnötige Besprechungen und optimieren Sie Ihre Prozesse. Wenn das tägliche Stand-up zu einem Status-Update für den Scrum Master geworden ist, lassen Sie es fallen. Wenn die Sprint-Planung mehr Zeit in Anspruch nimmt als der Sprint selbst, vereinfachen Sie sie.

Entwicklern ermöglichen, sich auf den Code zu konzentrieren

Und schließlich sollten Sie Entwicklern die Freiheit zurückgeben, ohne ständige Unterbrechungen zu programmieren. Lassen Sie ihnen konzentrierte Zeit haben, um Probleme zu lösen und qualitativ hochwertigen Code zu schreiben. Weniger Mikromanagement, weniger Jira-Updates und mehr kreative Freiheit sind unerlässlich, um die Agilität von Agile wiederherzustellen.

Ausblick: Die Zukunft jenseits von Agilität und Jira

Agilität und Jira sollten die Verfechter von Flexibilität und Effizienz sein, aber irgendwann wurden sie zu genau den Systemen, die sie ersetzen sollten. Da Unternehmen wachsen und Projekte komplexer werden, hat sich die einst vielversprechende Flexibilität der Agilität in einen bürokratischen Albtraum verwandelt. Das ist kein Nährboden für kreative Entwickler.

Aber das muss nicht so sein. Indem wir neue Methoden übernehmen, uns auf Ergebnisse konzentrieren und Teams die Freiheit geben, sich anzupassen, können wir uns vom Kult um Agilität und Jira befreien. Der langsame, schmerzhafte Niedergang der Agilität muss nicht das Ende der Geschichte sein. Stattdessen kann er der Beginn einer neuen Ära der Softwareentwicklung sein – einer, die Kreativität, Innovation und Geschwindigkeit wirklich fördert.