Seit Veröffentlichung des Agilen Manifests im Jahre 2001 ist der Begriff „agil“ in aller Munde, zumindest in der Welt der Softwareentwicklung. Bis zu 80 % Planungsdifferenz zum schließlich realisierten Endergebnis durch häufige Änderungen, dazu komplexe Abstimmungserfordernisse und wenig Selbstorganisation an der Entwicklerbasis führten schon lange vorher zu der Erkenntnis, dass die klassische Durchplanung eines Projektes für hochvariable und -mobile Softwareprodukte an ihre Grenze kommt. Wer live erlebt, wie eine Planung sich ständig selbst überholt, sei es weil der Kunden neue Feature eingebaut haben möchte oder sei es, weil das Basissystem einer Anwendung neu versioniert wird und kein Stein auf dem anderen bleibt, der versteht rasch die Ansätze der Agilen Methodik:
Insbesondere das Fokussieren auf „potentially shippable product increments“, d.h. Liefergegenstände mit in sich abgeschlossener und produktiv einsetzbarer Funktionalität, ist Basis für wesentlich kürzere Planungszyklen, die ihren deutlichsten Ausdruck in Iterationsschritten findet, die sehr plakativ „sprint“ genannt werden. Die Art wie in dieser Methodik mit längerfristigen und kurzfristigen Arbeitsvorräten umgegangen wird (Product und Sprint Backlog), ähnelt stark dem industriebekannten Kanban-Verfahren. Auch das Einfrieren (Freezing Point) eines Arbeitsauftrags, ähnelt dem Vorgehen, z.B. in chemischen Betrieben.
Interessant bleibt daher die Frage, inwieweit Projekte, in denen es nicht um Software geht und in denen die potenziell versandfähigen Inkremente nicht so offensichtlich sind, sich auch für agiles Vorgehen anbieten.
Beim Überprüfen und der ständigen Verbesserung Ihres Projektmanagements sollten Sie durchaus auch entsprechende Möglichkeiten prüfen.