Agile / Projektmanagement

Ich bin agil – was nun? … eine systemische Betrachtung

In IT-Organisationen kann immer wieder beobachtet werden, dass agil umgesetzte Projekte durchaus als erfolgreich zu bezeichnen sind. Darüber hinaus gibt es andere Projekte, die streng klassisch vorgehen und den Erfolg der agilen Projekte gefährden. Aus systemtheoretischer Perspektive ist an diesem Punkt ein Perspektivenwechsel zu empfehlen. Mit steigender Komplexität gewinnen die Beziehungen zwischen den Elementen des sozialen Systems immer mehr an Bedeutung. Dieser Gedanke soll hier aufgegriffen werden.

Agil - was nun?

Vor einigen Jahren starteten etliche IT-Abteilungen kleine aber feine Testballons, um zu sehen, dass agiles Vorgehen trotz anfänglicher Schwierigkeiten durchaus funktionieren kann. Erste Erfolge in kleinem Rahmen ermutigten die Teams dazu, auch in größeren Projekten das agile Paradigma zu leben. Die Erfahrungen zeigten, dass da was dran ist an dem agilen Vorgehen. Oft schon nach wenigen Sprints sind erste positive Signale zu erkennen. Das Team wächst zusammen. Plötzlich wird erkennbar, dass sich Entwickler viel stärker zu einem Plan committen können, den sie selbst mitgestalten können. Die Auslieferungen erfolgen immer öfter in der geplanten Zeit. Die Auftraggeber geben Feedback zu den präsentierten Teillösungen. Es sind nur die klassischen Projekte, welche die agilen Vorhaben auszubremsen versuchen. Die machen das aber nicht mit Absicht, aber eine neue Spalte in einer zentralen Tabelle bedarf sechs Monate Vorlaufzeit – inklusive intensivem Testen versteht sich. Innerhalb kurzer Zeit wurde klar, dass es so nicht weitergehen kann. Irgendwie muss es doch möglich sein, agile und klassische Projekte im Portfolio zu managen. Fragt sich nur, wer hier nachgeben soll? Die Agilisten bestehen darauf, an ihren Methoden nichts ändern zu können, weil das Ganze nur dann funktioniert, wenn man sich strikt an die Bibel der agilen Community hält. Plötzlich begann das Management sich einzumischen.

 

Das Management greift ein

Aus der Sicht des Managements ist weniger von Bedeutung, welches Vorgehen gewählt wird, solange die Projekte in der Zeit und innerhalb des gesteckten Budgetrahmens abgewickelt werden. Trotzdem wollte man Verständnis zeigen und sich für die offensichtlich erfolgreiche agile Arbeitsweise stark machen. Eine fundierte Entscheidung bedarf nun einer ausreichenden Entscheidungsgrundlage. Und schon war der Arbeitsauftrag an die IT-Abteilung formuliert. Der Einfachheit halber sollten für jedes der beiden Vorgehensmodelle die drei wichtigsten Erfolgskriterien dargelegt werden. Dann würde man schon sehen, welchem Vorgehensmodell in Zukunft der Vorrang zu geben ist.

 

Die wichtigsten 3 Erfolgskriterien waren rasch gefunden

Das klassische Lager geht in Klausur und kommt mit folgenden Argumenten zurück:

  1. Bereits am Anfang des Projektes ist detailliert geplant, wer was macht und bis wann jedes einzelne Arbeitspaket fertiggestellt ist.
  2. Bereits vor Projektbeginn ist klar ersichtlich, was das Projekt kosten wird und wann es fertiggestellt sein wird.
  3. Bei gutem Projekt-Management hält sich das Projektrisiko in überschaubarem Rahmen

Die Argumente für agiles Vorgehen sind auch nicht von der Hand zu weisen:

  1. Rasche Reaktion auf sich ändernde Bedürfnisse ist möglich
  2. Releases mit hoher Planungssicherheit werden zur Projekt-Realität
  3. Return on Investment stellt sich rasch ein

 

Nächstes Problem

Die drei Erfolgskriterien müssen auf maximal 5 Folien mit maximal drei Farben passen. Da fragt sich natürlich jeder Experte, wie man auf dieser Basis eine vernünftige Entscheidung treffen kann. Nun kommt der Querdenker ins Spiel, der die Frage in den Raum stellt: Brauchen wir überhaupt eine Entscheidung? Gehen wir einen Schritt zurück und überlegen wir uns, was wir aktuell beobachten können. Vielleicht lässt sich daraus etwas ableiten, das uns in dieser Situation weiterhilft?

 

Eine kurze Analyse aus systemischer Sicht

Projekte mit langen Durchlaufzeiten waren noch vor wenigen Jahren meist massiv verspätet, kosteten viel mehr als ursprünglich geplant und lieferten nicht unbedingt den erwarteten Nutzen bei einem „Big Bang“ – Go Live. Das Rezept damals war die Verringerung der Taktung der Releases in überschaubarere Einheiten.

Das funktionierte soweit ganz gut. Das Warten auf ein Release wurde erträglicher und damit die Time to Market bedeutend verbessert. Plötzlich bedrohte ein neues Phänomen die Reputation der CIOs: Nach der Live-Schaltung der ersten Release einer Lösung wurden regelmäßig Unmengen an Änderungsanträgen eingebracht. Das setzte das Projekt mächtig unter Druck. Ein Schuldiger war rasch gefunden: das Anforderungsmanagement muss verbessert werden. Daraufhin wurde vermehrt Energie in die Qualität der Anforderungserhebung und Analyse investiert. Die Anforderungsmanager wurden dazu angehalten, die Anforderung exakter zu formulieren und nachvollziehbarer zu dokumentieren. Die Projekte wurden dadurch zwar nicht billiger aber bedeutend kalkulierbarer.

Plötzlich erscheinen Produkte am Markt, die mit relativ wenig Aufwand entstanden und in kurzen Zyklen weiterentwickelt wurden. Das Reagieren auf Veränderungen wurde zu einem integrativen Bestandteil des Vorgehens gemacht, die Methoden wurden schlanker und die Teams interdisziplinärer. Mutige Manager setzten ihr Vertrauen in agile Teams und erhielten Lösungen, die näher an den Bedürfnissen der Anwender heranreichen als jäh zuvor.

 

Der Druck wächst

Mittlerweile sind wir an einem Punkt angekommen, wo eine kritische Masse an Projekten agil umgesetzt wurde und dabei relativ erfolgreich war. Daneben laufen noch bedeutend mehr Projekte nach klassischem Wasserfall-Prinzip und den typischen Problemen. Der Druck auf die IT-Abteilungen wächst. Steigendes Kostenbewusstsein führt dazu, dass nach Auswegen gesucht wird, um schneller passende Produkte und Lösungen ausliefern zu können. Der agile Ansatz verspricht, viele Sorgen der CIOs von der Tagesordnung zu nehmen.

Jetzt geht es nicht darum, dass agiles Vorgehen das allheilbringende Mittel ist, sondern agiles Vorgehen und klassische Ansätze so weit zu harmonisieren, dass dadurch eine neue Stufe der Interaktion innerhalb des sozialen Systems „Unternehmen“ ermöglicht wird. Das Zauberwort der Gartner Group in diesem Zusammenhang ist die Bimodale IT, welche eine Koexistenz zwischen traditionellem und agilem Vorgehen im Projekt anstrebt. Soziale Systeme neigen dazu, dass bei steigender interner und externer Komplexität nicht die einzelnen Elemente, sondern eher die Beziehungen zwischen den Elementen an Bedeutung gewinnen.

 

Was sagt der systemische Berater dazu?

Setzen wir also bei den Beziehungen an! Überlegen wir uns, was wir an den Schnittstellen etwa zwischen Betrieb und Projekt verbessern können. Wie kann ich aus Projektsicht, egal ob klassisch oder agil, die Kommunikation mit den Anbietern und Betreibern der IT-Infrastruktur verbessern? Wie kann ich noch besser die Brücke zwischen Anwendern und IT-Fachleuten schlagen? Das sind die Fragen, die uns wirklich beschäftigen, damit das soziale System „Unternehmen“ und speziell das Sub-System „IT-Abteilung“ zukunftsweisende und wahrscheinlich gar nicht so neuartige Beziehungen aufbauen kann. Neue Modelle der Zusammenarbeit werden sich entwickeln müssen, denn der Weg in die Schatten-IT sollte keine valide Option sein.

Mehr zu diesen neuen Modellen werde ich im nächsten Artikel behandeln sowie auch die die Rolle des Managements bei Veränderungsprozessen. Denn systemisch betrachtet wird dem Management nicht nur die Rolle des Auftraggebers für die Veränderung zuzuschreiben sein. Das Management agiert in erfolgskritischen Beziehungen als Initiator, Entscheider, Gestalter und Gestalteter zugleich. Diese vielfältigen auch rückbezüglichen Beziehungen zwischen Management und Team führen dazu, dass für alle Beteiligten der Sinn allen Tuns manchmal sogar zu „Eigensinn“ mutiert. In der Beraterpraxis zeigt sich immer wieder, wie die Prinzipien der Selbstorganisation zu wirken beginnen, und zwar bereits bevor die geplante Veränderung eingeleitet wird.

Passende Artikel

Kommentare gesperrt.