"Agilität" ist ein Begriff aus der Informatik. Dort war man vor einigen Jahren unzufrieden mit dem bis dahin traditionellen Vorgehen bei der Softwareentwicklung - bekannt unter dem Namen "Wasserfallmodel". Der etablierte Pfad führte nicht verlässlich zu guten Ergebnissen.
Ausgangspunkt Softwarebranche
So formierten sich einige Vordenker der Branche zu einer Gruppe und formulierten einen Gegenentwurf. Den nannten sie "Agile Softwareentwicklung" und deklarierten ihre Position im so genannten "Agilen Manifest". Sie stellen darin neue Sichtweisen/Praktiken den bis dato vorherrschenden gegenüber:
- Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen.
- Funktionsfähige Produkte haben Vorrang vor ausgedehnter Dokumentation.
- Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.
- Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.
(Quelle: http://scrum-master.de/content/view/62/25/)
Für einen Außenstehenden mag es überraschend sein, wenn die Softwarebranche scheinbar erst im Jahr 2001 entdeckt, dass z.B. die Zusammenarbeit mit dem Kunden wichtig ist. Aber es hatte schon seinen Sinn, dass die Agilisten ihr Manifest so formuliert haben. Sicherlich war der Kunde auch schon vorher den Softwarefirmen wichtig - das hatte sich nur nicht in geeigneter Weise in ihrem Vorgehen bei der Softwareentwicklung ausgedrückt.
Kann es denn da aber Missverständnissee geben? Kann man ungeeignet mit dem Kunden umgehen? Ja, man kann.
Agilität als geeignete Haltung
Ungeeignet ist eine Haltung, wenn sie dem Offensichtlichen widerspricht. So war es mit der Softwarebranche, die den Kunden zwar kannte und sah, ihn aber hinter Regeln und Papierbergen zunehmend aus den Augen verlor.
Das widersprach dem Offensichtlichen, dass die Regeln und Papierberge nicht zu erfolgreichen Projekten führte, d.h. Ablieferung des Bestellten innerhalb von Geld- und Zeitbudget.
Der Grund dafür: ein Missverständnis bzgl. der Natur von Software. Die wurde (und wird auch immer noch in weiten Teilen der Branche) als maschinenähnlich angesehen. Und so war denn das Vorgehen bei der Softwareentwicklung ähnlich dem beim Maschinenbau.
Software ist Maschinen oder Gebäuden jedoch nur oberflächlich ähnlich. So mussten die traditionellen Ansätze früher oder später gegen eine Wand laufen. Die Erkenntnis, dass das schon lange der Fall war, führte 2001 zum Agilen Manifest.
Das trägt der wahren Natur von Software Rechnung. Die ist nämlich viel dynamischer als die von Maschinen. Die ist eher Lebewesen ähnlich oder einer Stadt. Denn Software ist ständig in Bewegung, sie wächst kontinuierlich. Wie ein Programm in 5 Jahren aussieht, weiß keiner, der heute beginnt, es zu entwickeln. Die Gründe dafür sind vielfältig. Am Ende ist die Konsequenz jedoch, dass sich für Software kein Plan bis zu ihrer Fertigstellung machen lässt. Software ist quasi nie fertig, auch wenn in Verträgen ein Auslieferungsdatum steht. Die erste Auslieferung ist nur der Anfang eines meist unabsehbar langen Weges weiterer, oft sehr tiefgreifender Veränderungen.
Solange also Pläne, aufwändige Dokumentationen, starre Prozesse die Softwareentwicklung bestimmen, solange sind Softwareprojekte nur schwer zum Erfolg zu bringen, weil die Umstände ihrer Natur widersprechen.
Dem wollte die Agile Softwareentwicklung etwas entgegensetzen. Sie definiert vier Eckpunkte (s.o.) für eine geeignete Haltung, eine, die der Natur der Software entspricht. Das Agile Manifest trägt also Dynamik Rechnung; es entwirft einen Umgang mit Unwägbarkeiten. Softwareentwicklung soll im Angesicht von Ungewissheit, Komplexität und Fluktuation verlässlicher als bisher allseits zur Zufriedenheit verlaufen.
Agilität für die Führung
Ungewissheit, Komplexität, Fluktuation in der Umwelt: damit muss die Softwareentwicklung klar kommen. Ihr Vorgehensmodell muss also hinreichend offen und flexibel sein.
Ungewissheit, Komplexität, Fluktuation in der Umwelt: damit muss auch Organisationsführung klar kommen. Heutige Organisationen lassen sich nicht mehr quasi am Reißbrett planen und "durchziehen". In Wachstumsmärkten, solange eklatanter Mangel mit Produkten zu kompensieren war, mag das noch gegangen sein. Oder als die Organisationsmitglieder noch nicht so auf ihre Individualität bedacht waren, mag das auch noch gegangen sein.
Verdrängungsmärkte, globale Märkte, Mangel an qualifizierten Mitarbeitern, individuelle, multikulturelle Mitarbeiter... das sind Umstände, unter denen linear denkende Autokraten nicht mehr geeignet führen können. Diese Umstände verlangen - wie bei der Softwareentwicklung - Agilität. Es lohnt sich also, einen Blick auf das Agile Manifest von der allgemeineren Position der Organisationsführung zu werfen.
Was steckt also im Kern des Agilen Manifests, das sich auf Führung im Allgemein unter heutigen Umständen übertragen lässt?
Im Kern geht es bei den vier Punkten um zwei Grundhaltungen, die die Softwareentwicklung einnehmen soll, um der Natur von Software gerecht zu werden:
- Die Softwareentwicklung soll zunächst einmal zuhören. Die Menschen, die ein Interesse an einer Software haben, sollen zu Wort kommen. Sie sollen im Vordergrund stehen und nicht in einem Prozess verwaltet werden. Sich persönlich "breitbandig" begegnen ist den Agilisten wichtig. Wissen, das in den vielen Köpfen der "Stakeholder" schlummert, soll gehoben, soll lebendig gemacht werden. Dazu sind Nähe und kontinuierlicher Dialog wichtig. Softwareentwicklung steht und fällt mit den Menschen und ihren Kommunikationsfähigkeiten. Wo Verantwortung an Werkzeuge technischer oder methodischer Art übertragen wird, tritt der Mensch in den Hintergrund. Ebenso bei übermäßiger Dokumentation. Denn nur eine lebendige Kommunikation ist so flexibel, wie es letztlich das Problemfeld verlangt, in dem Software eine Lösung sein soll.
- Und dann soll das, was im Dialog herausgearbeitet wird, in einer Weise realisiert werden, dass es ständig weiter entwickelbar bleibt. Software ist insofern kein Produkt, was es einmal zu fertigen gilt, sondern ein Beitrag zur Kommunikation. Software ist eine Äußerung des Entwicklungsteams, auf die der Kunde wiederum mit Äußerungen reagieren kann und soll. Software ist also nicht außerhalb des Dialogs mit dem Kunden, sondern Bestandteil. Das bedeutet, sie muss letztlich so flexibel sein wie jeder Satz oder Gedanke in einer Kommunikation. Wie letztlich jede Aussage ist sie daher ganz fundamental immer nur eine These, ein Versuch - und damit nur solange gültig, bis sie falsifiziert ist. Softwareentwicklung ist eben Entwicklung, d.h. ein Lernprozess, und keine Produktion.
Agilität bedeutet also: genau hinsehen, ständig Daten sammeln, daraus Informationen generieren und diskutieren, im Fluss bleiben, Produkte als vorläufig betrachten und sie so konstruieren, dass neue Erkenntnisse jederzeit in sie einfließen können.
Agilität steht also ganz fundamental für einen fortschreitenden Lernprozess unter Einbeziehung aller Informationsquellen.
Um nichts anderes geht es auch der Soziokratie. Deren "Produkt" ist jedoch keine Software, sondern eine Organisation. Softwareentwicklung produziert Software. Führung produziert soziale Systeme, Organisationen.
Wenn Softwareentwicklung angesichts der Natur von Software besser agil abläuft, warum sollte dann nicht auch Führung angesichts der heutigen Natur on Organisationen agil sein?
Software ist ein sich ständig wandelndes komplexes technisches System eingebettet in soziale Systeme, deren Wandel es sich anpassen muss.
Organisationen sind komplexe soziale Systeme eingebettet in andere soziale Systeme, deren Wandel sie sich anpassen müssen.
Und genausowenig wie festgefügte, quasi autokratische Prozesse, Regeln, Werkzeuge der Softwareentwicklung helfen, genausowenig helfen sie heute noch der Führung von Organisationen. Deshalb sollte die Führung von Organisationen agil werden.
Agilität als Haltung in Bezug auf Unvorhersehbarkeit und Komplexität, entwickelt aus einer offensichtlichen Not der Softwarebranche heraus, hat also Bedeutung über diese Branche hinaus. Agile Führung ist nicht nur möglich, sondern nötig.