Während Unternehmen auf der ganzen Welt noch versuchen, agiler zu werden, wächst in der Software-Entwicklungsbranche bereits ein Unbehagen mit Agilität. Die Autoren des Agilen Manifests (Beck e.a., 2001) äußern sich durchaus kritisch und es wird darüber diskutiert, was den "Kern von Agilität" ausmache. In seinem lesenswerten Blogbeitrag: "The Agile Crisis — a Primer" gibt Jan Wischweh einen Überblick der aktuellen Diskussion darüber, welche Fehlentwicklungen bei dem grundsätzlich nützlichen Ansatz von Agilität zu beobachten sind (Wischweh, 2019).

Auch wenn Sie kein Software-Entwickler sind, und selbst wenn Sie Agilität nur für einen Hype halten, lohnt es sich, das Agile Manifest, das Gründungsdokument der agilen Idee, genauer anzuschauen und vollständig zu lesen. Dann werden Sie sehen, dass die Rezeption des Agilen Manifests den ursprünglichen Gedanken der Autoren nicht gerecht wird – woran diese nicht ganz unschuldig sind. Die Problematiken in der Software-Entwicklung, mit denen sich die Autoren des Manifests 2001 auseinandersetzten, sind genau diejenigen, die Unternehmen heute bei der Einführung von agilen Methoden im Geschäftskontext erleben, wie z.B. ein zum Selbstzweck verkommenes Reporting oder zu träge Entscheidungswege. Hier können Sie also von der Erfahrung der Software-Entwickler profitieren, um nicht in dieselben Fallen zu laufen, welche die Autoren des Agilen Manifests unzufrieden machen.

Haben Sie das Agile Manifest wirklich gelesen?

Die Autoren des "Agile Manifesto" trafen sich im Jahr 2001, weil sie über das Selbstverständnis ihrer noch sehr jungen Profession der Software-Entwicklung sprechen wollten. Die Leitfrage war: Was macht gute Software-Entwicklung aus? So heißt es im ersten Satz des Manifests: "We are uncovering better ways of developing software by doing it and helping others do it" (Beck e.a., 2001).

Das Agile Manifest ist weit mehr als 4 Werte und 12 Prinzipien!

Wenn überhaupt, dann ist die Startseite des Agilen Manifests bekannt. Es finden sich jedoch ganz viele erhellende Informationen auf der Website (die folgenden englischsprachigen Zitate sind von dieser Site, siehe Beck e.a., 2001), auf der die Autoren über die Entstehungsgeschichte des Manifests berichten. Dabei wird deutlich, wie grundlegend sie ihre Profession hinterfragen.

Es dreht sich nicht einfach nur um eine bessere Art der Programmierung, sondern um das Selbstverständnis einer Profession. Die Autoren machen deutlich, dass sie sich als der Schrecken von Unternehmensbürokraten sehen, die offensichtlich keine agilen Ansätze mögen ("the Agile approaches scare corporate bureaucrats"). Sie möchten sich von denen unterscheiden, die Prozesse wegen der Prozesse mögen ("those that are happy pushing process for process’ sake"). Die Autoren wünschen sich eine Entwicklergemeinschaft, die von der Last der "dilbertesken" Unternehmen befreit ist ("developer community freed from the baggage of Dilbertesque corporations"). Wenn Ihnen der Begriff "dilbertesk" nichts sagt: "Dilbert" ist die Hauptfigur einer Cartoon-Serie von Scott Adams. Er ist Software-Entwickler in einem großen Unternehmen und beständig den Widrigkeiten sowohl einer überbordenden Bürokratie als auch unfähiger Vorgesetzter ausgesetzt.

Werteorientierte Zusammenarbeit als Ideal

Das Ideal der Autoren sind Organisationsmodelle, die den Menschen in den Mittelpunkt stellen, und eine werteorientierte Zusammenarbeit auf der Basis von Vertrauen und Respekt fördern, sodass ein Arbeitsumfeld entsteht, in dem sie gerne arbeiten wollen. Sie schreiben über ihr Treffen:

"We all felt privileged to work with a group of people who held a set of compatible values, a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work."

Für die Autoren definiert also das Agile Manifest dieses Ideal, wer sie sein wollen und wie sie arbeiten wollen.

Prozesse und Methoden sind für die Menschen da – nicht umgekehrt!

Sie weisen auch darauf hin, dass sie nicht gegen Methodik sind. So schreiben sie: "The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology." Diese Behauptung wird dadurch unterstrichen, dass die Autoren alle prozessorientiert und Verfechter unterschiedlicher Prozessmethoden sind, z.B. Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming. Sie suchen eine Alternative zu dokumentationsgetriebenen, schwergewichtigen Software-Entwicklungsprozessen. Das ist ein sehr wichtiger Teil ihrer Identität: Prozesse und Methodik sind natürlich notwendig. Aber auf eine Art und Weise, die Menschen respektiert und hilfreich anstatt belastend ist. Ihr Ziel ist die (Wieder)herstellung eines Gleichgewichts:

"We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment."

Diese Idee des Gleichgewichts wird in ihrer ursprünglichen Benennung besser deutlich, da sie von "Lightweight Processes" und noch nicht von "Agilität" sprachen.

Der Konflikt zwischen Mensch und Maschine

Ich sehe diese Balance, die die Autoren für ihre Profession wünschen, als Ausdruck des folgenden allgemeineren Ringens zwischen zwei Polen, die man gut mit "Mensch vs. Maschine" metaphorisch beschreiben kann.