„Agile Prozesse funktionieren nur, wenn Umgebung und Kultur dazu passen. Wenn diese Bedingungen nicht passen, muss man sie ändern. Aber können Softwarearchitekten, Entwickler oder Projektleiter eine Organisation so grundlegend ändern? Auch für Manager sind Änderungen in der Kultur schwierig, denn die Kultur ist fundamental für ein Unternehmen als soziales Gefüge. Die Unternehmen sind mit ihren alten Vorgehensmodellen und ihrer Kultur meistens am Markt gut positioniert, sodass gar kein Druck zum Wandel besteht – schon gar nicht zu einem radikalen Kulturwandel, wenn es doch „nur“ um ein Software-Entwicklungsprojekt geht.“
Eberhard Wolff mit einem sehr reflektierten Stück über agile Entwicklung, in den Kommentaren finden sich auch einige gute Erfahrungsberichte. Als Außenstehendem kommt mir Waterfall vs. Agile manchmal wie ein (meistens) freundlicher Religionskonflikt vor.
Auf struktureller Ebene scheint mir agile Entwicklung fast zweitrangig den Wunsch nach kürzeren und flexibleren Zyklen innerhalb von Projekten zusammenzuhängen. Eigentlich handelt es sich um einen Puffer gegen Stakeholder, die Projekte allzu optimistisch planen, die Roadmap durch ständige Änderungswünsche umschmeißen und an unterschiedlicher Stelle Druck ausüben. Also quasi eine Eindämmung von Irrationalität. Neulich hat ein Nutzer bei HackerNews das hier geschrieben:
„Am jetzigen Punkt meiner Karriere bin ich überzeugt davon, dass das Problem immer darin besteht, dass irgendwo in der Befehlskette jemand ist, der willkürliche Deadlines setzt und dann ständig die Anforderungen ändert. Als Entwickler habe ich das gehasst – uns wurde einfach mehr und mehr Arbeit aufgehalst, Änderungen von willkürlich über kontraproduktiv bis schlicht dumm. Produktmanager, die die Nutzer nicht verstanden und einfach zufällige Ideen ohne Überprüfung umsetzen ließen.
Als ich CTO wurde, stellte ich fest, dass meinem CEO die Realität scheissegal war, er einfach mehr forderte, Änderungen veranlasste und überhaupt nicht interessiert war, wie sich der Arbeitsaufwand zum Zeitplan verhielt. Ihm war es einfach egal, dass er verhinderte, dass das Produkt fertig wurde und er machte einfach die Entwickler (und schließlich mich) dafür verantwortlich. Mein Vertrag war so, dass ich kein Problem damit hatte, der Sündenbock zu sein, aber die Beschimpfungen, die die Entwickler über sich ergehen lassen mussten, waren sinnlos.
Das war nicht das einzige Mal. In mehr als 20 Jahren habe ich das bei Firmen wie Microsoft oder Amazon erlebt (von Bezos direkt, inkompetentester CEO aller Zeiten). Auch bei vielen Startups.
Mir kommt es vor, als wäre nicht-technischen „Leadern“ die Tatsache völlig egal, dass Software Zeit braucht. Sie glauben, dass es doch einfach möglich sein muss, alles zu jeder Zeit ändern zu können.Ich habe deshalb unterm Strich aufgehört, für andere Leute zu arbeiten. Es ist nicht so, dass Software schwierig zu managen wäre – aber die MBA-Typen haben keinen Respekt für die Entwickler-Teams und wollen Entwickler nur ausbeuten. Wenn du in einer guten Situation bist, ist das deshalb, weil jemand zwischen dir und dem MBA-A*loch dich schützt. Oder weil dein CEO ein Entwickler ist. Ich arbeite nicht mehr für CEOs, die keine echten Entwickler sind (dabei wurde ich auch angelogen. Nein, deine HTML-Seite aus der Schule mit einem bisschen JavaScript macht dich noch nicht ‚technisch‘).“
Aus dieser (genervten) Perspektive ist ein guter Projektleiter theoretisch ein besserer Puffer als ein ausgeklügeltes Scrum-System. Umgekehrt würde ich (Achtung, ich = organisationspsychologisch interessierter Laie) aber in einem Umfeld, in dem alle die Funktionsweisen von Software-Entwicklung und ihre eigene Rolle in der Zusammenarbeit verstehen, einem agilen Projektmanagement bessere Erfolgsaussichten geben.
Aber in all dem spielen x Faktoren eine Rolle, zum Beispiel auch die Frage nach dem Lerneffekt: Denn selbst wenn ich zum Beispiel als Produktmanager den Bedarf eines größeren Zeitbudgets verstehe, kann ich meinerseits unter Druck stehen, diesen Faktor völlig zu ignorieren. „Kultur“ ist in diesem Falle eben Verpflichtung zum Respekt des Prinzips nicht nur in einer Abteilung, sondern auf allen Ebenen inklusive des externen Kunden.
Siehe auch: Tech und seine Kulturen