Das Wort "Projektmanagement" ist heutzutage ja ein fast schon angestaubter, altbackener Begriff. Stattdessen spricht alle Welt von Scrum und Jira Workflows... und dann die schon fast inflationär getätigte Aussage: "Das entwickeln wir alles ganz agil." Vielleicht ist einem dieser Satz ja auch schon mal untergekommen. Je nach persönlichem Background, stellt sich jede*r was anderes darunter vor. Also Licht aus, Kopfkino an. Und dann sieht man sie, die verbildlichte Agilität... Projektteams auf Rollschuhen, chaotische Kanban Boards mit allerlei Zettelwirtschaft, verzweifelte Controller*innen, Start-Up-Enthusiast*innen beim mitternächtlichen Asia-Snack, schwer gestresste Geschäftsführer*innen, morgens um 7 Uhr - kurz vorm Daily Huddel oder Stand-Up... Die Möglichkeiten der Vorstellungskraft sind unendlich. Im folgenden Blogbeitrag wollen wir etwas Klarheit in die Thematik bringen und uns alle relevanten Aspekte ein wenig genauer anschauen.
Fragen über Fragen...
Vorgehensweisen, die unter die Kategorie "AGIL" fallen, sind insbesondere in der Softwareentwicklung bereits etabliert. Die Einschränkungen und Restriktionen, die traditionelle und eher als konservativ zu bewertende Unternehmensstrukturen mit sich bringen, begrenzen die Möglichkeiten eines Einsatzes entsprechender Methoden häufig enorm. Lassen sich agile Herangehensweisen unter solchen Umständen überhaupt sinnvoll implementieren und anwenden? Und welchen Nutzen ziehen die Companies dann daraus? Und was ist dann mit dem Projektmanager und seiner Rolle? Innovations- und Marktdruck sind in diesem Kontext wohl zuallererst als Herausforderungen in der Projektwelt zu nennen. Und dann kommt noch hinzu, dass ein gewünschtes Projektergebnis zu Beginn der Planung meistens nur stark abstrahiert und mit einer entsprechenden Unschärfe definiert werden kann. Im Projektverlauf lässt sich stets auch das Phänomen der sich verändernden technischen Rahmenbedingungen und Kundenwünsche beobachten. Und die Engpass-Ressource sind gute Mitarbeitende mit hohen und seltenen Qualifikationen. Dort, wo diese Faktoren und Umstände zusammenkommen, wird seit einigen Jahren auf agile Vorgehensweisen gesetzt, hauptsächlich auf Scrum und Extreme Programming (XP).
Agil versus traditionell: gleicher Rahmen, verschiedene Ansätze
Einen ähnlichen Bekanntheitsgrad wie das "Agile Manifest" – wenn auch nicht damit vergleichbar – hat das im traditionellen Projektmanagement äußerst prominente "Dreieck des Projektmanagements", bestehend aus Zeit, Kosten und Leistung. Diese drei Restriktionen haben natürlich unter anderem auch für agil geführte Projekte Gültigkeit, verdeutlichen aber einen grundlegenden Unterschied (Bild 1).
Bild 1: Agil versus traditionell - Unterschiede
Traditionell durchgeführte Projekte haben die Tendenz, den Leistungsgegenstand eingangs genau zu spezifizieren und dann als fix anzusehen. Damit dann die am Anfang vereinbarten Leistungen erfüllt werden können, ist es häufig notwendig und auch durchaus akzeptiert, die Zeit- und Kostenziele zu überschreiten. Die agilen Vorgehensweisen stützen sich in ihrer Logik auf die Akzeptanz der Tatsache, dass der Leistungsgegenstand anfangs sehr unscharf ist und erst im Projektverlauf spezifiziert und genauer wird. Die zeitlichen Rahmenbedingungen und auch die zur Realisierung verfügbaren Ressourcen werden dagegen als fix angesehen. Agile Projekte bewegen sich somit innerhalb derselben Beschränkungen und Rahmenbedingungen wie anhand des traditionellen Ansatzes durchgeführte Projekte. Die Handhabung und der Betrachtungswinkel, mit denen den Schwierigkeiten eines Projekts begegnet wird, sind allerdings äußerst unterschiedlich.
Bei agilen Ansätzen wird ein "iterativ-inkrementelles Vorgehen" angewendet. Das bedeutet, dass die Produkterstellung in festgelegten Zeitintervallen (Iterationen) stattfindet (zum Beispiel 30 Tage). Wenn diese Zeitspanne dann zu Ende ist, sollte immer ein nutzbares Teilergebnis feststehen. Es wird also nicht eine (gefühlte oder aber auch tatsächliche) Ewigkeit auf den ersehnten Augenblick der Finalisierung hingearbeitet, sondern kontinuierlich in kleinen Steps ein Produkt generiert, das in einem frühen Stadium lauffähig ist und dessen Funktionsumfang kontinuierlich erweitert wird.
Also "entweder oder"? Kann man auch beides haben?
Bei der Integration agiler Methoden in einer traditionellen PM-Umgebung können Welten aufeinanderprallen: Die Anhänger*innen der klassischen Vorgehensweisen wollen klare Leistungsbeschreibungen und Termine, die der Agilen wollen im Team von Iteration zu Iteration neu bestimmen, was wann getan wird. Prinzipiell gibt es zwei Möglichkeiten, Agilität in einem Unternehmen zu integrieren, ohne dieses in seinen Grundfesten zu erschüttern: Entweder man formiert klar abgetrennte Projektteams, die agil arbeiten - heißt ganz konkret, man bildet an den Stellen Inseln, an denen agile Ansätze erfolgversprechender als der traditionelle Weg sind - oder man kannibalisiert agile Vorgehensweisen, zerlegt sie in ihre Bestandteile (sprich Praktiken und Module) und implementiert sie schließlich anteilig in das traditionelle Projektmanagement.
Diese Möglichkeiten sind in agilen Ansätzen selbst schon enthalten: Extreme Programming z.B. beschreibt bewusst verschiedene Praktiken zur Softwareentwicklung, aus denen Anwendende nach Belieben für ihre Projekte wählen sollen.
Umdenken erwünscht zur Integration agiler Methoden!
Möchte eine Organisation in ihr traditionelles Projektmanagement agile Methoden einfließen lassen, können deren Vorteile genutzt werden, ohne auf einen Schlag alle bestehenden Standards umzuwerfen. Allerdings spricht man tatsächlich erst von agilem Projektmanagement, wenn agile Methoden auch durchgängig eingesetzt und die agilen Werte gelebt werden. Das bedeutet ein gewisses Maß an Umstellungen für die betroffene Company und hat entsprechen große Auswirkungen auf das Leadership-Team selbst. Denn die agilen Ansätze kommen mit einem Set aus Werten, die nur im Einklang mit den Werten der Geschäftsführung und der Unternehmenskultur funktionieren. Das kann wiederum Gegensätze aufwerfen: Vertrauen und freie Interaktion stehen im Kontrast zu Compliance (Regelkonformität) und Kontrolle oder Selbstorganisation in einem Team gegen Prozessreife. So muss sich ein Unternehmen z.B. fragen, ob seine Kund*innen ein CMMI-Level oder agiles Vorgehen glücklicher macht. Auf einmal ist man neben der Implementierung von neuen PM-Vorgehensweisen mit ganz grundlegenden Werte- und Kulturfragen konfrontiert.
Je nach Sachlage bzw. Projekteigenarten, kann es sinnvoll sein, verschiedene Vorgehensweisen anzuwenden. Ob Agilität erfolgreich ein- und umgesetzt werden und sein Potenzial vollumfänglich zeigen kann, hängt davon ab, ob es für das jeweilige (Teil-)Projekt auch tatsächlich einen Mehrwert bringt und ob das entsprechende Team auch damit umgehen kann und will. Abhängig vom Leistungsgegenstand und Zielzustand kann es etwa bei einem hoch innovativen Thema alternativlos sein, mit regelmäßig iterativ neu definierten und bewerteten (Zwischen-)Zielen zu arbeiten. Unter stark reglementierten Umständen und starren Rahmenbedingungen dagegen gibt es vielleicht keine wirklichen Alternativen zum gängigen Wasserfall-Modell. Eine Organisation muss daher den Boden und die Bedingungen dafür bereiten, dass klassisch und agil durchgeführte Projekte im selben Unternehmen und sogar im selben Gesamtprojekt effektiv und effizient neben- und miteinander koexistieren können.
Und jetzt - wo anfangen, wen verpflichten und was machen?
Sollten die Entwickler*innen nach agilen Prinzipien arbeiten, empfiehlt sich in der Übergangsphase eine Betreuung durch externe Agile Coaches. Die Coaches sollten von Anfang an funktionierende Agile Strukturen und Prozesse etablieren, um später keine „eingeschliffenen“ Probleme bearbeiten zu müssen. Im agilen Umfeld ist es nicht unüblich, dass wertvolle Teams, bestehend aus Spezialist*innen, kontinuierlich von Coaches betreut werden, um bestmögliche Resultate zu erzielen – ähnlich wie beim Hochleistungssport. Den Mitarbeitenden in Entwicklungsteams soll es im Endeffekt wichtig sein, aktiv auch an grundsätzlichen Entscheidungen sowie an der Gestaltung von Strukturen und Prozessen beteiligt zu werden.
Gerne können wir uns zum Thema direkt auch austauschen, wenn Sie mögen - auf Feedback, Erfahrungen und auch durchaus kritische Gedanken freue ich mich. Lassen Sie mir einen Kommentar da oder schreiben Sie mir direkt.