Welche Worte kennen Sie noch, die so inflationär verwendet werden wie der Begriff „Agilität”?

Agiles Projektmanagement ist alles andere als schwammig. Es ist tatsächlich sehr spezifisch; manchmal mehr, als sich Projektmanager dies wünschen. Am besten kann ich das zeigen, wenn ich die beiden Modelle gegenüberstelle: Im klassischen Projektmanagement kennt man den Plan und den Weg. Meilensteine werden abgearbeitet, Meetings nicht selten Monate im Voraus geplant.

Im agilen Projektmanagement geht man bewusst dynamisch vor. Man kennt sein Ziel, dies ist aber eher im Sinne einer Vision beschrieben. Ein Beispiel: Das Ziel ist die Entwicklung eines neuen Produkts für die Zielgruppe der jungen Kunden. Dabei sind am Anfang nur wenige Meilensteine definiert, häufig noch kein fixer Endpunkt und auch nur ein indikatives Budget. So wird der Freiraum geschaffen, auf Entwicklungen im Projekt und am Produkt flexibel reagieren zu können.

Nicht jede Organisation lässt die dafür notwendigen Freiräume ...

Ja, in großen Organisationen ist ein Projekt oft bereits im Vorfeld mit viel Bürokratie verbunden. Zum Projektstart werden Informationen verlangt über die notwendigen Ressourcen, das Budget, den Zeitraum, die Meilensteine etc. Um diese Organisationsinteressen zu berücksichtigen und gleichzeitig Agilität Raum zu lassen, wird in der Praxis oft ein Mittelweg eingeschlagen. Wichtig ist dann nur die Offenheit, auch die Abweichungen vom Pfad nicht als Fehler zu klassifizieren. Stellt sich etwa bei der Lösungsentwicklung heraus, dass die Kunden eine besondere Funktionalität besonders schätzen, die vorher nicht geplant war, dann darf es kein Fehler sein, hier vom Plan abzuweichen. Im Gegenteil; dann wurde alles richtig gemacht.

Verlangt ein Kunde nach einem agilen Projekt, bekommt er dann die eine zeb-Methode?

Wir haben keine Methode von der Stange, wir machen Maßanfertigung. Denn die Kunden und Projekte sind auch zu spezifisch, dass eine Methode für alles passen würde. Wir verfügen aber über einen etablierten Baukasten. Bestimmte Tools und Hilfsmittel bieten Sicherheit in einem dynamischen Umfeld. 

Was ist drin im Baukasten?

Wir arbeiten fast immer in Sprints, die drei bis vier Wochen dauern. In den Sprints nutzen wir Elemente, die aus Scrum bekannt sind: Kickoffs, Dailys, Weeklys, Reviews. Hierbei bieten wir etablierte und verprobte Formate. Denn Kickoff ist eben nicht gleich Kickoff, Review nicht gleich Review und so weiter. Hier haben wir uns erfolgreich auf die Organisationen der Finanzbranche spezialisiert. Zusätzlich nutzen wir bei Bedarf Methoden wie Design Thinking, erstellen Customer Journeys und Personae; auch in internationalen Projekten. Auch Kanban-Techniken kommen zum Einsatz. Wir wissen, was im jeweiligen Kontext passt. Dies gelingt durch unser tiefes Branchenwissen. Denn nur mit der Methode alleine kommt man bei Banken, Versicherungen und Co. nicht weit.

Wie kann bei so viel Agilität noch eine Budgetplanung funktionieren?

Im vergangenen Jahr haben wir beispielsweise ein agil gesteuertes Millionenprojekt unterstützt. Die zugehörige Excel-Tabelle glich natürlich eher einer Tapetenbahn. Und sie wurde nahezu jeden Tag angepasst. Unsere Kunden profitieren also von unseren Erfahrungen aus anpassbaren Budgetplanungen, lassen aber auch ihre Mitarbeiter aktiv und agil mitarbeiten. Am Ende immer eine tolle Teamleistung. 

Ist in den Unternehmen mittlerweile nicht genug Agilitäts-Know-how vorhanden, um solche Prozesse ohne externe Unterstützung zu steuern?

Zunächst einmal ist es toll, dass die Unternehmen ihr Know-how in der agilen Projektplanung aufbauen. Das sollte auch zukünftig so weitergehen. Schließlich wünschen wir unseren Kunden immer den größtmöglichen Erfolg am Markt – und Agilität ist kein einfaches Trendthema. Im Projekt habe ich als Externe eine besondere Rolle. Teilnehmer sind dann eher bereit zu experimentieren und sich auf Neues einzulassen, wenn ein Externer dabei ist, auf den man sich auch im Zweifelsfall berufen kann. Außerdem ist es für mich als Externe im Team leichter, dass Leistung realistisch betrachtet wird. Insgesamt ist es so: Wenn eine externe Person dabei ist, ist Agilität schneller möglich. Nach dem vierten Sprint läuft es meist und wir ziehen uns zurück. 

Welche Rahmenbedingungen müssen mindestens gegeben sein, damit ein agiles Projekt überhaupt funktionieren kann?

Es muss einen echten Lösungsraum geben. Das ist der Freiraum, in dem ein Team eigenverantwortlich handeln kann. Ein Beispiel aus der Praxis: Vorgegebenes Ziel war, die Bindung junger Kunden zu stärken. Dem Product Owner schwebte eine digitale Lösung vor, doch er gab dem Team das aber nicht als Vorgabe, sondern gab Lösungsraum. Und so kam es zu einer analogen Lösung. Der Product Owner hat das akzeptiert. Heute ist die Lösung in der Praxis im Einsatz und bereits profitabel. Agil wird es erst, wenn alle inkrementell verändern können. Das heißt: Die einzelnen Bausteine zur Lösung des Problems werden aus dem Team heraus entwickelt und sind nicht vorgegeben. 

Bei so viel Freiheit: Wann ist denn dann ein agiles Projekt beendet?

Auch dies kann man gerne durch das Team mitentwickeln lassen: Welche Ziele möchte man sich geben? Ein bestimmter erreichter Ertrag, eine bestimmte Anzahl erreichter Kunden oder nur eine Konzeption? Hier kommen bereits im Laufe der ersten Tage häufig tolle Vorschläge, die das Team im Zeitverlauf weiter motivieren. Ja, manches Projekt sollte über das eigentlich geplante Projektende hinaus weiterlaufen. Die gezielte Weiterentwicklung von Lösungen, hin zu einem agil weiterentwickelten Zielzustand, hat leider aktuell noch einen zu geringen Stellenwert. Je mehr Lösungsraum gegeben ist, desto stärker ist das Team auch motiviert, nochmals nachzulegen, die Extrarunde zu drehen. Die großen Player am Markt machen es doch vor – die Entwicklung hört nicht auf, die Anwendungen werden ständig weiterentwickelt. Und zwar schnell.

Wo liegen die Grenzen agilen Projektmanagements, wo ist die klassische Methode besser geeignet?

Generell gilt: Je komplexer ein Thema ist, desto eher ist es für agiles Projektmanagement geeignet. “Komplex” bedeutet hier: die Breite des möglichen Lösungsraums, Schnittstellen zum Kunden, Abhängigkeiten. Das gilt auch für Lösungsentwicklungen für den internen Kunden, also den Mitarbeiter. Hier denke man etwa an neue Lösungen in der Personalarbeit und Fortbildungen, hier gibt es noch riesiges Potenzial. 

An Grenzen stößt man mit dem Vorgehen bei stark aufsichtsrechtlichen Inhalten oder dort, wo es systemseitig und prozessuale Restriktionen gibt. Wo es wenig bis keinen Spielraum gibt, da kann agiles Projektmanagement seine Kraft nicht entfalten. 

Lesen Sie mehr von Sarah Schroeder im Interview zum Thema "New Work".