Agile Methoden sollen Softwareteams durch kurze Entwicklungszyklen, frühes Feedback und gemeinsame Verantwortung besser planbar machen. In der Praxis scheitern agile Transformationen jedoch häufig an der Unternehmenskultur. Eine Analyse von Heise Developer beschreibt, warum die Probleme nicht allein im Prozess liegen.
Iterationen können früh zeigen, dass ein Projekt länger dauert oder ein geplantes Feature keinen ausreichenden Nutzen bringt. Das ist technisch wertvolles Feedback. In klassischen Organisationen wird derselbe Befund aber schnell als persönliches Versagen oder als Argument gegen das gesamte Team behandelt. Dann entsteht ein Anreiz, Risiken und Verzögerungen zu verschleiern.
Gemeinsame Verantwortung trifft auf klassische Projektrollen
Agile Teams teilen die Verantwortung für ein Produkt. Klassische Organisationen belohnen dagegen häufig einzelne Projektleiter für den Abschluss eines Vorhabens. Diese beiden Modelle passen nur schwer zusammen, wenn die Bewertung einer Führungskraft davon abhängt, dass ein Projekt trotz früher Warnsignale formal erfolgreich abgeschlossen wird.
Ein ähnlicher Konflikt entsteht bei der Produktplanung. Ein Team kann alle zwei Wochen eine neue Version bereitstellen, während das Produktdesign weiterhin in Quartalsreleases denkt. Nutzerfeedback erreicht dann nicht die Planung, obwohl genau dieses Feedback ein Grund für die kurzen Zyklen ist.
Continuous Delivery braucht passende Rahmenbedingungen
Continuous Delivery und Microservices verstärken die technischen Möglichkeiten für häufige Veröffentlichungen und selbstorganisierte Teams. Sie lösen aber keine widersprüchlichen Ziele zwischen Auftraggebern, Dienstleistern, Technik und Management. Die GitLab-Meldung zu automatisierten Build- und Testketten zeigt die technische Seite solcher Abläufe, die organisatorische Seite bleibt Aufgabe der Unternehmen.