Was ist eigentlich das Gegenteil von Agilität?

Wenn ich ab und an eine freie Minute, den Abend im Hotel, eine lange Bahnfahrt oder den Flug nach Hause dazu nutze, über mögliche Themen für meinen kleinen Blog hier nachzudenken, tun sich mir manchmal ganz eigenartige Fragestellungen auf. So zum Beispiel heute: was ist eigentlich das Gegenteil von dem, was seit geraumer Zeit als Agilität insbesondere in der Softwareentwicklung und dort vor allem von den Entwicklern selbst als die bessere Vorgehensweise (oder überhaupt eine?) angepriesen wird?

Das Schlagwort Agilität ist seit Jahren in aller (oder vielen) Munde – doch was gab bzw. gibt es davor oder daneben?  Was könnte das denn sein … was zeichnet Agilität aus und unterscheidet es von anderen Vorgehensmodellen – ist die Kleinteiligkeit, das Zerschneiden eines großen Ganzen in kleine Pakete sodass deren Abarbeiten einfacher, effizienter und risikoärmer wird? Dann wäre das Gegenteil ja das Monolithische, Großes, Ganzes, Komplexes. Aber ist es denn genau das, was die „old school“ im Vergleich zur Agilität ausmacht? Oder sind es die Iterationen der Produkterstellung, die dann nach der Fertigstellung der vielen kleinen Bausteine am Ende das fertige Haus, die fertige Pyramide ausmacht?

Nun, wenn ich so darüber nachdenke zeichnet sich Agilität dadurch aus, dass man sich eben genau so kleinteilig und detailliert bewegt, wie man es quasi ohne Feldstecher gerade selbst überblicken, verstehen kann. Und am Ende gibt es dann doch das große Ganze, das Haus – aber ich kenne den Bauplan und die Detailausprägung eben nicht zu Beginn des Hausbaus – Form und Ausgestaltung des Bades im ersten Stockwerden eben erst dann detailliert und festgelegt, wenn die Deckenplatte des Erdgeschosses fertig ist bzw. die Außenwände stehen ….nun, aber wenn ich das erst während des Bauens definiere, wie kenne ich dann von Baubeginn an, wie viel Geld ich investieren muss? Soviel wie ich eben kann… also ist der Unterschied also der, dass ich es bei Agilität erst am Ende ganz genau weiß (was ich bekommen werde und was es kostet), anstatt es a la „hold School“ von Beginn an einzuplanen – es also von Beginn an zu wissen. Nein, das kann auch nicht sein, denn welches „hold School“ Projekt habe ich bereits in Time, in Budget und in Quality abschließen sehen? Ich kann mich gerade an keines erinnern …

Aber vielleicht ist das auch genau der Drehpunkt zum Gegenteil: Agiles vorgehen bedeutet durch die Brille des „hold school“ Projektmanagers das nackte Grauen! Ich fange mit stichpunktartig beschriebenen Anforderungen an und arbeite die in festen Zyklen immer detaillierter ab – ein Ende ist nicht planbar, Kosten und inhaltlicher Output sind doch eigentlich nicht steuerbar. Stimmt, wenn man in „old school“ Paradigmen denkt: Inhalte sind vorab bestimmbar, Aufwände sind präzise kalkulierbar, Risiken sind identifizierbar, kalkulierbar und damit auch mitigierbar, Dann ergibt sich „nur noch“ benötigte Dauer und Kosten – beides kann ich nach dem Festschreiben der Inhalte (Lastenheft) und Aufwände (Aufwandsschätzung auf Basis Pflichtenheft auf Basis Lastenheft) und dem zuweisen verfügbarer Ressourcen dann ja aus meinem Plan ablesen …. Na prima: so weiss ich schon vorher was ich auf Basis des bekannten Wirkkreises Zeit/Geld/Qualität (Z/G/Q) bekommen werde. Und hier ist alles starr, geplant, eingepresst durch die Vorgaben aus genau diesen drei Perspektiven.

Liegt dem Gegenteil der Agilität damit nicht genau diese eine Idee zugrunde: ich kann alle drei Aspekte  Z/G/Q genau vorab bestimmen und festschreiben. Dabei bewege ich mich in einem geschlossenen System, bei dem keine Kräfte verloren gehen – die Summe aller drei Aspekte bleibt immer gleich. Das erinnert mich an meinen Physikunterricht oder an das Radfahren: es kostet viel Kraft den Berg hinauf zu fahren, aber es kostet keine Kraft oben umzudrehen und bergab zurück nach Hause zu rollen. Aber dort angekommen habe ich Hunger – kann es sein, dass der Energieerhaltungssatz eine rein objektive Theorie ist, während sich die subjektive Realität anders verhält – und das bekannte Dreieck aus Z/G/Q dann eben doch kein geschlossenes System ist? Sehr gut möglich – und wieder versuche ich mich an das letzte Projekt zu erinnern, in dem sich der Keris über diese drei Aspekte geschlossen hat….

Ich glaube, das ist der wesentliche Unterschied zwischen Agilität und ihrem Gegenteil: der Glaube (bzw. Nicht-Glaube) an die Theorie des Energieerhaltungssatzes. Agiles Vorgehen geht davon aus, dass sich im (gleichschenkligen) Dreieck Z/G/Q auch Verschiebungen ergeben können die dazu führen, dass dieses Dreieck eben nicht mehr gleichschenklig ist, ggf. auch gar nicht geschlossen ist (und damit kein Dreieck mehr ist). Zum Beispiel mehr Qualität auf Kosten von Geld und/oder Zeit. Im Gegenteil der Agilität glaube ich an den Energieerhaltungssatz – alles wird so, wie es in der Planung austariert wurde,

Also ist das Gegenteil von Agilität der „Glaube an den Energieerhaltungssatz“?! Nun, nehmen Sie Ihr Fahrrad und fahren Sie auf den nächsten Berg. Drehen Sie oben rum und lassen sich wieder zurückrollen in die heimatliche Garage. In der Theorie haben Sie nun in Sachen kinetische Energie Ihren Haushalt komplett ausgeglichen. Sie können das auch schneller tun, indem Sie bergauf mehr Kraft investieren – und so vielleicht 10 Minuten einsparen. Auch dann werden sie einen kinetischen Potentialausgleich erreichen. Das könnte der Beweis des gleichschenkligen Dreiecks Z/G/Q sein – und der Theorie, dass auf diese Weise angegangene Projekte funktionieren MÜSSEN! Wenn Sie nach dieser Schinderei auf dem Rad nicht nur so einen Hunger hätten ….

Dieser Beitrag wurde unter Projektmanagement abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>