Der langsame und schmerzhafte Tod von Agile und Jira
(ehandbook.com)"Agile ist nicht länger Agile, also ist es jetzt an der Zeit, dass Agile zusammen mit Jira verschwindet."
- Die Software-Entwicklungszyklen werden immer länger, die Technikteams immer größer, für das Entwicklungsmanagement werden immer mehr Apps benötigt, die Zahl der Menschen, die tatsächlich programmieren, sinkt, und zwischen immer kürzeren, fortlaufenden Checkpoints gibt es immer weniger Fortschritt
- Wo ist Agile aus dem Ruder gelaufen?
- Agile wurde Anfang der 2000er als Methodik entwickelt, als Alternative zu den schweren, dokumentenzentrierten Software-Entwicklungsprozessen der Vergangenheit
- Heute ist Agile jedoch zu einer Abwandlung klassischer, komplexer Projektmanagement-Methoden geworden
Tech Bloat ist das Hauptproblem
- Der wichtigste Grund, warum viele Menschen Agile aufgeben oder aufgeben wollen, ist Tech Bloat
- Tech Bloat ist der Feind jedes Technologieunternehmens und auch für nicht-technische Unternehmen mit internen oder ausgelagerten Entwicklungsteams riskant
- Tech Bloat ist nicht dasselbe wie technische Schulden, erzeugt aber technische Schulden
- Zu den Symptomen von Tech Bloat gehören:
- Man spricht wiederholt mit Kunden, wird aber nicht zum Experten für ihr tatsächliches Verhalten
- Deadlines und Liefertermine werden ständig bewertet und neu bewertet
- Es besteht eine extreme Zurückhaltung, den Entwicklungsprozess zu starten, bevor nicht jedes Detail dokumentiert ist
- Es entsteht ein Anreiz, mit den einfachsten statt mit den riskantesten Aufgaben zu beginnen
Die verwirrenden Folgen von Tech Bloat
- Mehr Dokumentation
- In den Prozess sickert eine Dokumentation ein, die nicht nur nachverfolgt, was und warum entwickelt wurde, sondern auch "wie"
- Dieses "Wie" wird zum Schwerpunkt von Status-Updates, wodurch ständig neu bewertet wird, wie das Team arbeitet
- Teams verbringen mehr Zeit damit zu besprechen, warum Arbeit nicht abgeschlossen wurde, als sie tatsächlich zu erledigen
- Häufige Deadline-Setzung
- Durch mehr Deadlines an immer häufigeren Kontrollpunkten entsteht an praktisch jedem Wendepunkt eines im Kern kreativen Prozesses Mikromanagement
- Das läuft der Produktion hochwertiger Software zuwider, weil alles zu einem festen Termin geliefert wird, unabhängig davon, wie gut die Arbeit ausgeführt wurde
- Der ständige Zweifel im Neubewertungsprozess
- Durch den ständigen Zweifel während der Neubewertungsphasen werden Best Practices nicht festgelegt, Verschwendung nicht beseitigt und Skaleneffekte nicht erkannt
- Mikromanagement des Produktionsprozesses
- Sobald etwa 30 % einer gesamten Funktion fertiggestellt sind, ist sie oft schon keine Priorität mehr
- Organisationen geraten in eine Todesspirale, in der produziert wird, was auf der Roadmap steht, unabhängig davon, ob die Roadmap noch den Aufbau eines erfolgreichen Produkts definiert
- Das Endergebnis
- Produkte leiden unter der Last vielfältiger und widersprüchlicher Kundenanforderungen
- Funktionen kommen oft zu spät auf den Markt und werden in der Reihenfolge und auf die Weise geliefert, die für das Technikteam am besten passt, nicht für den Markt
- Am Ende wehren sich Vertriebs- und Marketingteams, weil sie nicht wissen, was sie eigentlich verkaufen, und Kunden nicht wissen, was sie kaufen
- Daraufhin beginnt die Organisation mit einem großen Aufräumen
Die Welt braucht leichte Software, die wichtige Dinge besser erledigt, nicht mehr Funktionen
- Das ist kein neues Konzept, aber eines, von dem sich am Ende jede Methodik entfernt
- Am Ende fangen die Menschen an zu fragen, ob der Toyota-Weg noch toyotahaft genug für Toyota ist, und daraus wird nur weitere Arbeit
- Agile ist inzwischen zu einem PMP mit niedlichem Namen, kürzeren Meetings und mehr Regeln geworden
- Das Problem ist nicht die Idee von Agile, sondern die Umsetzung und das Fehlen von Führung, die es steuert
- Es ist ein Problem des mittleren Managements, das sich stärker auf Deadlines als auf Nutzen, stärker auf Kürzungen als auf Wachstum und stärker auf Sparen als auf Fortschritt konzentriert
Meinung von GN⁺
- Agile ist entgegen seiner ursprünglichen Absicht bürokratisch und formalisiert geworden und trägt nun dazu bei, die Software-Entwicklung zu verlangsamen
- Tech Bloat ist nicht nur bei Agile, sondern in jeder technischen Organisation ein Risikofaktor, auf den man achten sollte
- Dokumentation, Deadline-Setzung und Mikromanagement können Qualität und Geschwindigkeit im Gegenteil verschlechtern
- Das Wesen von Agile liegt in Kundenorientierung, Zusammenarbeit und Flexibilität, daher sollte man sich eher auf die Prinzipien als auf die Form konzentrieren
- In der Software-Entwicklung ist nicht die Zahl der Funktionen entscheidend, sondern wie gut die Kernfunktionen umgesetzt sind
- Organisationskultur und Führung entscheiden über Erfolg oder Scheitern von Agile, daher sollten technische Führungskräfte darauf achten
- Es scheint an der Zeit zu sein, über Agile hinaus nach neuen Methodiken zu suchen
17 Kommentare
Da der Originaltext ein kostenpflichtiger Artikel ist, konnte ich ihn nicht bis zum Ende lesen. Es wäre aber gut, die übersetzte Formulierung noch etwas zu glätten.
„Agile ist nicht länger Agile, also ist es jetzt an der Zeit, dass Agile zusammen mit Jira verschwindet.“
=> „Agile hat aufgehört,
being agilezu sein, also ist es jetzt an der Zeit, dass Agile zusammen mit Jira verschwindet.“Es gibt hier das Konzept, zwischen dem großgeschriebenen Agile und dem kleingeschriebenen agile zu unterscheiden,
und
being agileunddoing agilehängen zwar zusammen, werden aber gedanklich getrennt.being agile by doing agile.Warum man Agile einführt, ist entscheidend. Führt man es ein, damit die Entwicklung besser läuft? Eher nach dem Motto: Ich kann nicht zusehen, wie ihr euch ausruht. Ich schaue mir mal an, wie fleißig ihr wirklich seid. Mit so einer Haltung führt man es ein. Dann wird es zwangsläufig zur Hölle.
An diesem Punkt scheint wohl eine Checkliste zur Einhaltung von Agile nötig zu sein.
Noch vor der Frage, ob Agile oder Waterfall besser ist, gilt: Wenn Menschen, Kultur und das Umfeld unverändert bleiben, führt selbst die innovativste Entwicklungsmethodik am Ende nur zu einer koreanisierten K-OOO-Version.
Wenn sich die Anforderungen (fast) nicht ändern, dann stimmt es durchaus, dass Waterfall aus Entwicklersicht wirklich die bequemere Methode ist. Vorausgesetzt natürlich, es gibt keinerlei Änderungen an den Anforderungen …
K-Agile wird ja nie neu bewertet.!
Kunde: Dieser Button wäre an dieser Stelle gut.
Entwickler: (Dann muss ich wohl die Nacht durchmachen, es gibt auch noch neue Aufgaben)
Kunde: Auf einem anderen Bildschirm sollte ein Button sein.
Entwickler: (Kann bitte jemand Klontechnik einsetzen) Ja, haha..
Kunde: Ist es immer noch nicht fertig? Laut Zeitplan hätte doch alles abgeschlossen sein müssen, oder?
Entwickler: (Rettet mich) Ja..;;
Es scheint nur wenige Fälle zu geben, in denen Agile langfristig wirklich agil genutzt wird,
und die meisten Organisationen offenbar letztlich bei Waterfall-Arbeit mit kurzen Deadlines landen.
Agile ist nicht das Problem. Das Problem sind die Menschen, die es anwenden. Egal, welche Methodik man einführt, am Ende kommt es immer darauf an, wie die Menschen damit arbeiten. Ich denke, Agile ist weniger eine Methodik als vielmehr eine Haltung, mit der man ein Produkt in bestimmten Zyklen weiterentwickelt. Wenn man das aus den Augen verliert und blind plant und Retrospektiven abhält, ist das meiner Meinung nach nur Zeitverschwendung.
Ich dachte, das sei nur bei K-Agile so, aber offenbar ist es ein globales Phänomen.
Es fühlt sich an, als würde man immer wieder auf das Falsche einschlagen ... Eigentlich sollte man danach urteilen, ob es zur Agile-Manifest passt oder nicht ...
Auch Uncle Bob, der an der Agile Manifesto beteiligt war, hat dieses Problem früh verstanden und 2019 das Buch Clean Agile veröffentlicht, um fehlgeleitetes Agile zu korrigieren, aber solche Probleme bestehen noch immer. Ich persönlich denke, dass das daran liegt, dass es für Agile keine standardisierten Leitlinien gibt und stattdessen der vage Begriff „Kultur“ verwendet wird. Ich wünschte, es würden konkrete standardisierte Leitlinien vorgegeben.
Der Autor würde wohl vermutlich empfehlen, jede Methodik aufzugeben, sobald sie bürokratisch wird.
Ich stimme zu. Es scheint, als würden immer mehr Leute falsch verstandenes Agile praktizieren und dann behaupten, Agile sei falsch.
Andererseits denke ich auch: Obwohl seit seinem Aufkommen schon ziemlich viel Zeit vergangen ist, scheint es wohl unvermeidlich zu sein, dass es schwierig ist, gute Praktiken aufzubauen.
Drehen wir uns im Kreis und landen wieder beim Ausgangspunkt?
Hacker-News-Kommentare
Probleme mit Agile
Prinzipien des Agile Manifesto
Der Kern von Agile
Die Flexibilität von Agile
Meinungen zu JIRA
Der Ursprung von Agile
Agile heute
Probleme mit JIRA
Anwendung von Agile