Agile Projektarbeit

Realitätsnähe statt Hellseherei

Gedanken zur agilen Projektarbeit

Agilität ist eine gute Alternative zur Hellseherei (Bild: foto art Elisabeth Wiesner)
Agilität ist eine gute Alternative zur Hellseherei (Bild: foto art Elisabeth Wiesner)

2015 Mai, Peter Siwon: Los Leute, wir werden heute agil und ab morgen schnurren unsere Softwareprojekte wie Kätzchen. Vieles deutet darauf hin, dass sich komplexe Softwareprojekte mit agilen Methoden effektiver durchführen lassen. Das liegt vor allem daran, dass sich die Projektteams schneller und entschlossener ihrer Realität stellen. Doch das bekommt man nicht von heute auf morgen geschenkt. Warum ist das so? Hier eine Erklärung mit einem nochmal zugedrückten Auge.

Ergänzenden Artikel: Fordern Sie den ergänzenden Artikel „Psychogramm agiler Methoden“ zum Thema per Email mit dem Stichwort „agil“ an: info(at)systemisches-projektmanagement.info.

Der Umstieg auf die Agilität ist zunächst mal ein Eingeständnis der Projektleitung und all der anderen Stakeholder, die sich in Projekten herumtreiben: „Ehrlich gesagt blicken wir nicht wirklich vollständig durch!“  Der Durchblick fehlt uns, wenn wir von der Projekt-Gegenwart aus in die Projekt-Zukunft blicken. Er fehlt uns aber auch, wenn wir aus der Projekt-Gegenwart in die Projekt-Vergangenheit blicken. Der Blick nach hinten erscheint zwar etwas realistischer, wird allerdings durch allerlei Verdrängungs- und Verklärungsmechanismen verfälscht.  Wenn dem so ist, sollten wir vielleicht der Gegenwart etwas mehr Aufmerksamkeit schenken. Ich meine damit nicht, dass wir Projekte nicht planen und organisieren sollten, sondern, dass wir eine realistische Planung durchführen. Was heißt hier realistisch? Realistisch heißt agil.
Grob beschrieben bedeutet „agil“ Folgendes: Wir orientieren uns in unserem Vorgehen an den vier Werten und zwölf Prinzipien des agilen Manifests. Ihre Umsetzung äußert sich beispielsweise bei dem Prozessframework Scrum grob skizziert folgendermaßen:
Wir setzen uns ein Projektziel, wir legen die wesentlichen Qualitätsmerkmale, Features und Risiken fest, entscheiden was grundsätzlich zu tun ist und überlegen uns, an welchen Faktoren wir die Zielerreichung überprüfen. Kurz wir geben dem Projekt einen groben Rahmen, eine grobe Richtung und ein klares Ziel. Dann entscheiden wir, was wir in einer überschaubaren Zeit so erledigen können, dass ein funktionierendes und getestetes Zwischenergebnis vorliegt, das wir dem Kunden zeigen können. Der Zeitraum bis zum Release wird dann detailliert auf einzelne Aufgaben herunter gebrochen. Jeder Projektbeteiligte nimmt sich nun etwa eine Aufgabe pro Tag für den Zeitraum von 2-4 Wochen (Sprint) vor. Das Team beobachtet täglich in kurzen Meetings den Projektfortschritt und trifft sich alle 2-4 Wochen, um herauszufinden, welche Erkenntnisse für den weiteren Projektfortschritt berücksichtigt werden und wie der nächste Sprint aussehen wird. Nach  ca. 1-4 Sprints wird das Ergebnis dem Kunden gezeigt.Soweit der prinzipielle Ablauf in einem agilen Projekt.

Das geniale Prinzip, das dahinter steckt ist, dass der Projektablauf systematisch mit einem Kommunikationsprozess verzahnt ist, der das Lernen aus Erfahrungen fördert. Es wird dafür gesorgt, dass die Projektdurchführung zeitnah und genau beobachtet wird und so kurzfristig Lehren für den weiteren Verlauf gezogen werden. Es passiert genau das, was notwendig ist, wenn wir realistischerweise den Projektverlauf nicht vorhersagen können: Wir ersetzen unrealistische langfristige Detailplanung durch kurzfristigere Detailplanung auf Basis von Beobachtungen der Projektrealität. Wir verschieben unsere Aufmerksamkeit von einem unsinnigen Blick in die Glaskugel auf eine hilfreiche Beobachtung der Projektrealität. Das Tolle dabei ist, dass jeder Stakeholder von diesem Lernprozess profitiert, vor allem der Kunde. Denn er bekommt das, was er braucht.
Das Projektteam profitiert dadurch, dass diese Vorgehensweise den natürlichen Veranlagungen und Bedürfnissen der Menschen entgegen kommt:

  • Wir lernen am schnellsten, wenn der Zusammenhang von Ursache (Irrtum) und Wirkung (Fehlfunktion) unmittelbar erlebt wird.
  • Wir lernen am effektivsten, wenn wir Abläufe regelmäßig üben und dazu unmittelbare Rückmeldung erhalten. Die agile Methoden sorgen für regelmäßige Feedback-Zyklen.
  • Wir sind eher zu Offenheit und Konsens bereit, wenn die Opfer, die dabei gemacht werden, klein sind. Ein unbefriedigendes Release oder ein schief gelaufener Sprint schmerzt nun mal nicht so sehr wie ein gescheitertes Projekt.
  • Regelmäßige Kommunikation fördert das Vertrauen und vermindert das Risiko von Missverständnissen.
  • Der regelmäßige Blick auf Ergebnisse aus unterschiedlichen Perspektiven (Projektleitung, Teammitglieder, Kunde) wirkt Betriebsblindheit und Rosaroten-Brillen-Effekten entgegen.
  • Menschen lieben Erfolgserlebnisse und unmittelbare, konkrete Anerkennung ihres Einsatzes und ihrer Leistung.

Einer der wichtigsten Vorteile ist aus meiner Sicht die Reduzierung unnötiger Stressauslöser:  Je stärker Unsicherheit erlebt wird, desto mehr treten typische Stressreaktionen wie Aggressivität oder Flucht auf. In Projekten äußert sich das beispielsweise im arroganten, autoritären oder gar aggressiven Auftreten des Auftraggebers. Der Auftragnehmer kontert beispielsweise durch geschickte Ablenkungs- und Ausweichmanöver. Hier bieten sich gerade an den Schnittstellen zu anderen Lieferanten oder dem Kunden immer wieder gute Ansatzpunkte.

Wäre es nicht herrlich entlastend, wenn wir uns dieses Versteck- und Muskelspiel sparen können, das so oft in Projekten zu beobachten ist? Der Kunde muss nicht mehr so tun, als wüsste er genau, was er will. Das Projektteam muss nicht vorgeben, es könne verstehen, was der Kunde tatsächlich will und wie das Projekt im Detail verlaufen wird. Das Projektteam wird vor dem meist illusorischen Ansinnen geschützt, am Ende des Projekts all das auszugleichen, was im Verlauf des Projekts versäumt wurde (und was man dem Kunden tunlichst verschwieg). Ist es nicht auf jeden Fall angenehmer, die Hosen ab und zu ein bisschen herunter zu lassen, anstatt am Ende mit hochrotem Kopf völlig nackt da zu stehen.
Und wenn das Vertrauen da ist, wird der Projektpartner nach diesem Akt der Selbstoffenbarung gerne nochmal ein Auge verständnisvoll zudrücken. Schließlich haben alle was gelernt und können mit diesem Wissen künftig erfolgreicher sein.
Der einzige Haken an der Agilität ist: Es erfordert, dass wir uns das Vertrauen, das die Offenheit dieser Vorgehensweise erfordert, verdienen. Zum einen geht es um das Vertrauen, dass Projekte so (besser) funktionieren, und zum anderen, um das Vertrauen in die beteiligten Menschen. Am besten sie wenden dabei gleich die agile Vorgehensweise an: 1. handeln, 2. beobachten, 3. dazulernen, 4. nochmal ein Augen zudrücken, wenn es nicht gleich klappt, 5. weiter üben.

PSiwon-logo