Eine wiederkehrende Behauptung auf LinkedIn lautet, Agile sei tot. Das ist Unsinn, aber die Art von Unsinn, die ein Signal enthält, das eine Untersuchung wert ist. Wer diese Behauptung aufstellt, bewirbt meist ein Nachfolge-Framework, was etwas über die eigenen Motive verrät. Es bedeutet nicht, dass die Symptome völlig falsch beschrieben werden.
Hier die ehrliche Version: Agile ist zu einem der am stärksten kommodifizierten, missbrauchten und inhaltsleeren Begriffe im Berufsleben geworden. Als die dänische Behörde für Landwirtschaft das Wort "Agile" fünfundzwanzigmal in einer einzigen Stellenausschreibung verwendete, war eindeutig etwas schiefgelaufen. Das ist kein Einzelfall, es ist ein Symptom dessen, was geschieht, wenn eine genuin kraftvolle Idee zur Branding-Übung wird.
Erfüllte und gebrochene Versprechen
Über mehrere Jahre wurden Führungskräfte-Kohorten begleitet, zu deren Beginn eine wiederkehrende Frage gestellt wird: Von den Versprechen, die Agile bei der Einführung in der eigenen Organisation gemacht hat, welche wurden gehalten, und welche nicht?
Die Antworten waren über Organisationen unterschiedlicher Größe, Branche und Geografie bemerkenswert konsistent.
Was Organisationen im Allgemeinen berichten, erhalten zu haben: höhere Transparenz, schnellere Entscheidungsfindung auf Teamebene, klarere Prioritäten und bessere Zusammenarbeit innerhalb von Teams.
Was sie im Allgemeinen berichten, nicht erhalten zu haben: echte Kundenorientierung, selbstführende Teams, schnellere Markteinführungszeit, echte Innovation, echte Ermächtigung, Einfachheit und weniger Meetings.
Das ist eine vernichtende Bilanz für eine Philosophie, die versprach, all das zu adressieren. Die gute Nachricht, so weit sie reicht, ist, dass dieses Muster kein Beweis dafür ist, dass Agile nicht funktioniert. Es ist ein Beweis dafür, dass die meisten Organisationen nicht umgesetzt haben, was Agile tatsächlich erfordert.
Woher Agile eigentlich kommt
Um zu verstehen, warum die Lücke zwischen Versprechen und Realität besteht, muss verstanden werden, woher Agile tatsächlich kommt. Das Agile Manifest, unterzeichnet in Snowbird, Utah, im Februar 2001, wird oft als Ursprung behandelt. Das ist es nicht. Die Wurzeln reichen weiter zurück.
Das intellektuelle Fundament liegt im Harvard-Business-Review-Artikel "The New New Product Development Game" von 1986 von Takeuchi und Nonaka, die sechs führende Produktentwicklungsorganisationen untersuchten und identifizierten, was ihre Ansätze auszeichnete. Sie beschrieben selbstorganisierende Teams, überlappende Entwicklungsphasen, eingebaute Instabilität als Kreativitätstreiber, und eine Rugby-Metapher, Teams, die sich als Einheit bewegen, den Ball hin und her spielend, die direkt den Namen "Scrum" inspirieren sollte.
Weniger häufig erwähnt wird, dass alle sechs von Takeuchi und Nonaka untersuchten Produkte mechanisch-elektrisch waren: Fotokopierer, Autos, Kameras und PCs. Die intellektuellen Wurzeln von Agile liegen in der physischen Produktentwicklung, nicht in Software. Die siebzehn Unterzeichnenden des Manifests von 2001 kamen alle aus der Softwarebranche, weshalb Agile so eng mit Software assoziiert wurde, aber diese Assoziation war kontextuell, nicht inhärent.
Agile ist ein Paradigma zur Entwicklung komplexer Produkte unter Unsicherheit. Es ist egal, welche Technologien beteiligt sind. Die Implikationen davon sind erheblich: Viele der "Agile für Hardware"-Frameworks, die in den letzten Jahren entstanden sind, lösen ein Problem, das keiner Lösung bedurfte. Agile war von Anfang an nie nur für Software gedacht.
Worum es in dieser Serie geht
In den folgenden Beiträgen werden konkrete Pannen behandelt: es nach Lehrbuch machen, Framework-Götzendienst, die Kommodifizierung von Scrum, das Inkompetenzproblem bei Coaching und Training, und der Zertifizierungszirkus. Die Agenda ist nicht, ein Nachfolge-Framework zu bewerben. Es gibt keines zu verkaufen.
Die Agenda ist, einen Spiegel vorzuhalten. Der Agile-Markt enthält eine erhebliche Menge Schlangenöl, eine beträchtliche Menge Religion, und darunter gemischt genuin exzellentes Denken und Praxis. Es lohnt sich, sie zu trennen. Der nächste Beitrag ist Agile-Panne #1: Es nach Lehrbuch machen.