Warum „ein bisschen agil“ auch der richtige Weg ist

Es war einmal… - so fangen doch die meisten Geschichten an – und hören mit einer hoffentlich verblüffenden Pointe auf. So oder so ähnlich laufen auch viele Projekte ab. Sie beginnen, werden durchgeführt und mit Ergebnis und einigen schlauen Erkenntnissen abgeschlossen. (Hoffentlich)

Das ist ein Bericht, in dem sich ein Projektteam, gewöhnt an klassische Wasserfall-Methodik auf den Weg hin zu einer beweglicheren, flexibleren und reaktionsfähigeren Vorgehensweise machte.

Was in Projekten gerne zu kurz kommt sind Fragen wie: Aber was werden wir bei nächsten Mal besser (anders) machen? Was haben wir gelernt? Welche Fehlentscheidungen wollen wir in der Zukunft vermeiden? Es ist schon lobenswert wenn eine Reflektion bei den Beteiligten am Ende einer jedes Projektes statt findet :-) Die Praxis sieht oft anders aus.

Es war einmal - besser gesagt es gibt es noch, ein traditionsgeprägtes Unternehmen, das bis vor kurzem seine IT- Projekte ebenso klassisch (Wasserfall - Methode) wie traditionell abgewickelt hat: Analyse, Planung, Durchführung, Abschluss, und wenn die Zeit es noch erlaubt hat oder der Projektleiter mutig genug war: Lessons Learned. Diese wurde für das Management dokumentiert und verschwand im Nirwana. Bis man bei der Vorbereitung eines Projektes zu der Erkenntnis kam, es könnte doch auch anders gehen. Man stellte sich einfache, aber wichtige Fragen: was können wir tun damit wir Fehler schneller identifizieren können und noch währen des Projektes aus den Erkenntnissen profitieren können –denn nach dem Projekt ist es meistens zu spät und das Interesse gering.

Da das neue Langzeit-Projekt praktisch vor der Tür stand, wollte man diesen Gedanken umsetzen. Aber wie? Der arme Projektleiter stimmte mit gemischten Gefühlen der ersten Lessons Learned - Runde zu, obwohl es ihm seltsam vorkam, diese gleich nach der Initialphase des Projektes zu veranstalten. Das anfangs ebenso skeptische Projektteam machte einen 2 sündigen Workshop brav, aber etwas reserviert mit – soll sich hier etwas ändern? Die Skeptiker überwogen. Schließlich waren sie anderes gewohnt.

Als zweiten Schritt führte man ein Projektbarometer ein: eine kurze, regelmäßige und anonyme Umfrage innerhalb des Projektteams zu Stand und Stimmung des Projektes. Das erste Feedback überraschte sogar das Management: zu viele Meetings ohne brauchbares Ergebnis, unklare Erwartungen und Aufgaben, zu wenig Zeit zur Umsetzung. Es gab Lob für die gute Zusammenarbeit, offene Kommunikation und den Wunsch nach weiteren Lessons Learned. Der Grundstein für eine nachhaltige Veränderung wurde damit gelegt.

Die Projektleitung, obwohl konstruktives und offenes Feedback nicht gewöhnt, wollte den neuen und ungewöhnlichen Weg dann gehen. Der Schlüssel zum Erfolg liegt/lag natürlich in der ersten Linie bei Management selbst, dass die Vorschläge angenommen hat. Man schaffte kurzerhand ein paar „langatmige“ Meetings ab und verschaffte dadurch dem Team Zeit zum produktiven Handeln. Ebenso wurde ein weiteres Lessons Learned terminiert. 

Also ein Lob nicht nur an das Team, das sich "ahnungslos" und mit einigen Vorbehalten auf eine Veränderung eingelassen hat, sondern auch an das Management, das den Raum für die kleinen, aber entscheidenden Veränderungsschritte gegeben hat. (und das Management wird ja in der Regel nicht gelobt)

Agil heißt für mich vor allem kontinuierlich und interaktiv: Planen, Umsetzen, Reflektieren, um die Erkenntnisse in den nächsten Projektschritten zu implementieren. Bis zu einer Agilen Projektorganisation ist es hier noch ein laaaanger Weg – wobei das nicht unbedingt das Ziel sein muss. Auch kleine Schritte können positive und nachhaltige Veränderungen in einer Projektorganisation bringen. 
Ein bißchen agil eben. Hauptsache beweglich bleiben.

Jolanta Czagin, @wowolek