single.php
< Beitrag von Bernhard Reuß

Agilität als Feigenblatt, Teil-Agilität als Torso

Agilität wird von allen Seiten gefordert: Ja, heute sind wir alle agil! Einfach weil es alle tun, tun es die, die es noch nicht tun, umgehend auch. Die Bergpredigt hatte seinerzeit sicher nicht annähernd die Strahlkraft der heutigen agilen Projektierung oder gar der agilen Organisation.

Leider, leider fehlt jedoch überwiegend ein halbwegs hinreichendes Verständnis agiler Prinzipien und Arbeitsmethoden und vor allem eine ehrliche Einschätzung des erheblichen Fleißes sowie der hohen Disziplin und Präzision, die agiles Arbeiten erfordert.

Mein „Lieblingssatz“, den ich immer wieder höre, lautet: „Nein, nein, wir machen das agiler!“ Und damit ist die totale Freiheit und Unverbindlichkeit verkündet, in der sich jeder innovativ und integriert fühlen darf. So weit, so gut. Leider aber kommt bei einer solchen Pseudo-Agilität absolut nichts heraus.

Das „anarchistisch-agile Modell“: totale Freiheit und Entpflichtung

Ein aus meiner Sicht gefühltes Drittel der Wahrheit agiler Prinzipien ist die Loslösung von langfristigen Plänen zugunsten einer schnelleren Reaktionszeit. Agilität ermöglicht höhere Qualität, vermindert Korrekturarbeiten und führt zu schnell nutzbaren Teillösungen, gern als „Minimum Marketable Product“ (MPP) bezeichnet.

Tolle Sache, leider bleibt von diesem Drittel auch wieder nur ein Drittel in vielen Köpfen hängen, also nur noch ein Neuntel der agilen Logik: In dieser Wohlfühl-Agilität gilt dann nur noch „Loslösung von Plänen“ und „Reagieren“. Projekt-Beteiligte sehen sich durch Agilität von praktisch allem entbunden. Von der Last der Konzeption, der Planung und der Beschäftigung mit lästigen Details. Sie schwelgen in neu gewonnener Kreativität, ohne sich dem Anspruch unterwerfen zu müssen, die eigenen Ideen mit denen ihrer Kollegen in Einklang zu bringen oder auch mal irgendwann irgendwas festzulegen oder gar fertigzustellen. Schließlich kann man ja immer noch „reagieren“ und alles anders machen, wenn es gerade sinnvoll erscheint. Somit kommt man von Hölzchen auf Stöckchen und gerät auf immer neue Holzwege. Ganz im Sinne des „anarchistisch-agilen Modells“, wie ich es hier nennen möchte.

Widerspruch aus der harten Realität

Derzeit schwelgen viele Manager noch in derselben Illusion totaler Freiheit und Fleißlosigkeit der Arbeit. Wie immer bei solch harschen Urteilen meinerseits in diesem wunderbaren Blog weiß ich dessen LeserIn, also auch Sie in diesem Moment, auf der klugen Seite der Macht und kann Sie davon ausschließen. Sowieso wird diese extreme Form der Pseudoagilität meiner Einschätzung nach in den nächsten gut 2 Jahren deutlich zurückgedrängt werden und zwar aus 2 Gründen:

  1. Sämtliche Controller werden alsbald zurecht auf die Barrikaden gehen, wenn dauerhaft Projekterfolge, selbst mit der Lupe gesucht, nur herbeigeredet werden können. Das Ganze kostet ja eine Menge Geld und bringt schlicht nichts, außer zeitweilig schöpferischen Gefühlen oder solchen von Allmacht.
  2. Die Manager der unteren und mittleren Ebenen, die für Projekte oder „Values“, ja üblicherweise in der Linie geradestehen müssen, werden sich intensiver mit agilen Methoden auseinandergesetzt haben und einen solchen Larifari-Zirkus von vornherein unterbinden.

Ein Hauch von Einsicht: die Sehnsucht nach dem „teil-agilen Modell“

Die kleine Schwester der totalen Freiheit ist das „teil-agile“ Vorgehen. Dieses ist ein Quantensprung gegenüber dem oben beschriebenen anarchistischen Modell. Denn dem Gedanken liegt mindestens eine von 3 sehr wertvollen Erkenntnissen zugrunde:

  1. Unser Projekt-Soll-Ergebnis eignet sich nicht gut für eine in allen Aspekten agile Arbeitsweise.
  2. Wir wollen bestimmte Schwächen in unseren bisherigen Projekten durch einzelne agile Ansätze beheben.
  3. Wir sind organisatorisch – zumindest derzeit – gar nicht in der Lage, durchgehend agil zu arbeiten.

Recht oft verbinden sich derlei kluge Erwägungen mit der Vorgabe „von oben“, jetzt bitte mal mit der Zeit zu gehen. Da muss das Projekt schon – irgendwie – „agil“ ablaufen. Wer „teil-agil“ arbeiten will, muss aber klipp und klar definieren, was wie agil und was wie traditionell gemacht werden soll. So kann es durchaus sinnvoll sein, kürzere Lieferzyklen in ein traditionelles Projekt einzuführen. Dies gilt vor allem, wenn die Nutzer bestimmte Funktionen dringend brauchen und nicht warten wollen, bis alles komplett fertig ist.

Unterstellen wir mal, dass die Anforderungen glasklar definiert, abgestimmt und priorisiert sind. Dann könnte man „Sprints“ einführen, sich die vorhergehende Definition von User-Storys aber „sparen“. Oder umgekehrt könnte auf zyklische Lieferung verzichtet werden, aber mittels einer Variante von „Sprint-Reviews“ die Eignung des Entwicklungsstandes für die Fachseite fortlaufend geprüft und angepasst werden.

Oftmals schließen auch die etablierten Prinzipien der Projekt-Budgetierung eine Agilität reinsten Wassers aus, weil üblicherweise eine klare und detaillierte Ergebnisbeschreibung dafür erforderlich ist. Dies spricht aber keineswegs gegen die Nutzung einzelner agiler Elemente, wenn sie sich im gegebenen Rahmen als vorteilhaft erweisen.

Im Projekt-Alltag bleibt selbst Teil-Agilität häufig auf der Strecke

Diese Beispiele sind zugegebenermaßen recht abstrakt, denn sie entstammen meinen Gedankenspielen, nicht der Praxis. In den Fällen, in denen mich Kunden in den letzten Jahren mit der Suche nach Teil-Agilität konfrontiert haben, wurde diese Konkretisierung nämlich stets abgebrochen, wohl auch, weil sie anstrengend war und vielen zu akademisch erschien. Dann wurde das Projekt entweder nach „alter Väter Sitte“ durchgeführt, trug vielleicht dennoch den Stempel „hip und agil“ oder wurde verschoben, einem anderen Projekt angegliedert oder ganz verworfen.

Ich spreche hier – wie fast immer im Rahmen dieses Blogs – von meinen persönlichen Erfahrungen. Wenn Sie anderes erlebt haben, freue ich mich sehr über Ihre Rückmeldung; nicht nur dann, versteht sich. In meinen Projekten sind die Methoden des „Teil-agilen“ bislang nicht über die Idee hinausgekommen, selbst in den Fällen, in denen ich sie als sehr sinnvoll eingestuft hatte. Ich werde sie aber nicht ad acta legen, sofern sie mir im Einzelfall als Optimum erscheinen.

Wo bleibt die kompakte Lehrfibel?

Liebe Leserinnen und Leser, Sie erwarten nun zum Abschluss dieser Generalabrechnung natürlich das Gegenmodell, die kompakte und unfehlbare Lehrfibel. Und seien Sie gewiss, wenig macht mir mehr Freude, als ex Cathedra die großen Wahrheiten in noch viel größeren Reden unters Volk zu schwingen. Doch bei aller Versuchung bescheide ich mich an dieser Stelle ausnahmsweise einmal. Denn es gibt all das schon, ich muss es bei allem eigenen Sendungsbewusstsein nicht neu erfinden. Vielmehr verweise ich hier auf ein paar wenige Leseempfehlungen:

Das „Agile Manifest“

Agilität: Agiles Manifest

Es ist so etwas wie die Präambel der sich täglich erweiternden agilen Enzyklopädie. Schauen Sie mal rein, es sind nur ein paar Zeilen, die es allerdings in sich haben, vor allem in der Mitte der kurzen Lehrsätze: Dort heißt es nämlich im englischen Original „over“, in der deutschen Übersetzung „mehr als“. Damit ist eben nicht gemeint, alles, was Fleiß und Anstrengung braucht, über Bord zu werfen, sondern eine neue Gewichtung vorzunehmen, die näher am greifbaren Ergebnis liegt. Und nach meiner Interpretation muss diese Gewichtung, die ja bewusst im ungefähren bleibt, auch in mindestens jedem Projekt immer wieder neu justiert werden, so wie es im konkreten Fall sinnvoll ist.

Der SCRUM-Guide

SCRUM ist das agile Modell, das zumindest in unserer IT-Welt am meisten verbreitet ist. Machen Sie sich doch einmal die Mühe und lesen den SCRUM-Guide, also die Reinfassung der Modellbeschreibung, ohne die meterdicke Sekundärliteratur. Das ist tatsächlich schnell machbar. Er hat nämlich netto nur 14 Seiten, kein Scherz!

Ganz leicht verdaulich ist die Lektüre aber auch wieder nicht, da sehr kompakt beschrieben wird, wer was alles in welcher Folge und mit welchen Erfolgskriterien zu tun hat. Das erfordert Konzentration und Vorstellungskraft. Denn der Guide ist bei aller Kürze so konkret und beinhaltet so viel Fleißarbeit in kurzen Zyklen, dass er ein perfektes Heilmittel darstellt für alle Apologeten der vermeintlichen agil-theologischen Befreiung.

Wenn Sie sich dann noch vorstellen, dass Sie eine Brücke über den Atlantik bauen möchten, wird Ihnen schnell klar, dass Ihnen SCRUM, so hip es immer noch sein mag, überhaupt nicht helfen kann. Es ist ein Vorgehensmodell für Software-Entwicklung. Das Modell lässt sich durchaus auch auf andere, vor allem immaterielle, Güter anwenden, aber auf ganz viele eben auch nicht. Etwas Anderes hat übrigens meines Wissens auch niemand mit Kenntnis der Materie je behauptet!

Unser herrlicher ORBIT-Blog

Schauen Sie doch mal, wenn nicht schon geschehen, was unser Kollege Mario Pützstück zur agilen Praxis geschrieben hat: Das muss ich an dieser Stelle wirklich nicht versuchen zu paraphrasieren.

Na gut, zumindest ein kleines Lehrblättchen

Da ich mich aber auch nicht einfach aus der Verantwortung stehlen kann und will, gebe ich hier zumindest ein paar griffige Ableitungen aus den hier beschriebenen Beobachtungen zum Besten: Agilität …

  • bedeutet eigenverantwortliche, straffe Arbeitsorganisation, Fleiß, Präzision und Pünktlichkeit.
  • funktioniert nur, wenn alle Beteiligten die Arbeitsprinzipien genau kennen und sich penibel daran halten.
  • ist dann sinnvoll, wenn sich das Ergebnis „portionsweise“ bauen lässt und sich die Teilergebnisse idealerweise gleich nutzen lassen.
  • entfaltet ihre potenziellen Vorteile vor allem dort, wo Unsicherheit bei der Ausgestaltung des Ergebnisses besteht. Dort, wo ich etwas aus dem Effeff baue, erhöht sie hingegen den Aufwand, ohne das Ergebnis zu verbessern.
  • muss, wenn sie aus ihrem originären Geltungsrahmen übertragen wird, auf den neuen Anwendungsbereich explizit angepasst und neu justiert werden.

Noch ein Wort vom Chefankläger, zu dem ich mich hier aufschwinge: Ich bin in Wahrheit ein großer Anhänger agilen Arbeitens. Ich verbinde das aber immer mit 2 meiner Leitfragen, die ich immer und überall stelle:

  • Wofür ist das gut?
  • Wie machen wir das jetzt hier in diesem Fall konkret?

Mit diesen salbungsvollen Weisheiten wünsche ich Ihnen nun viel Erfolg im agilen oder im traditionellen Schaffen oder eben auch in der richtigen Mischung und Dosierung!

Folgen
X

Folgen

E-mail : *
Kategorie: Projektmanagement | Schlagwörter: | Kommentare: 0

Beitrag kommentieren

CAPTCHA * Time limit is exhausted. Please reload CAPTCHA.