Agiles Projektmanagement ist zwar nicht mehr neu aber gerade in aller Munde. Begriffe wie "New Work", "Digitalisierung" und eben "Agilität" stehen hoch im Kurs. Agiles Projektmanagement ist in der IT Branche bereits weitestgehend etabliert. Mehr und mehr Unternehmen außerhalb der IT Branche fragen sich nun, ob ein Vorgehen wie Scrum auch zu ihnen passen könnte. Aber welche Voraussetzungen sollten erfüllt sein, damit in Projekten agil gearbeitet werden kann?
Tipp 1: Das Projektteam sollte sich selbst organisieren können
Um agil, also schnell und wendig zu sein, ist es notwendig, Entscheidungen ins Team zu verlagern. Kurze Entscheidungswege sorgen dafür, dass anstehende Aufgaben sofort erledigt werden können.
Da Selbstorganisation ohnehin immer stattfindet. Jeder gesunde Mensch organisiert sich täglich selbst. Wer würde uns erwachsenen Menschen schon sagen, was zu tun sei? Stellt sich nur die Frage, wie passiert im Projektteam, was passieren soll, damit gestellte Aufgaben erfüllt, Probleme gelöst oder neue Ideen zum Leben erweckt werden? Damit sich ein Projektteam also selbst organisieren kann, braucht es passende Führung, Regeln und einen Rahmen.
Führung im Sinne von "in eine bestimmte Richtung lenken" kann hierbei etwa durch eine Vision oder eine Zielvorgabe funktionieren, die Orientierung gibt. Führung kann auch im Sinne von Verhaltensregeln erfolgen. Regeln entstehen dabei immer aus dem Versuch heraus, eine für alle Teammitglieder passende Art der Zusammenarbeit zu etablieren. Mit der Zeit werden diese Regeln zu ungeschriebenen Gesetzen; in regelmäßigen Abständen im “Review-Meeting” reflektiert und justiert. Die Rahmenbedingungen des Handelns ermöglichen Teammitgliedern abzuwägen, welche Entscheidungen sie selbst treffen können.
Ist ein Team mit der Zielrichtung ausgestattet, in die alle arbeiten sollen, wurden Regeln zur Zusammenarbeit gefunden und passende Rahmenbedingungen geschaffen, also Entscheidungskompetenzen eingeräumt, sind Teams in der Lage, sich selbst im Sinne des Projektziels oder Unternehmens zu organisieren. Dabei wird eine starke Weisungsgebundenheit vollkommen überflüssig.
Tipp 2: Projektteam-Mitglieder sollten sich zu 100% einem Projekt widmen können
Agiles Projektmanagement lebt von Kommunikation. Nur wenn jeder zu jederzeit über relevante Veränderungen informiert ist kann sichergestellt werden, dass Änderungen und Anpassungen zeitnah passieren können. Zudem wird sichergestellt, dass niemand den Anschluss verliert. Da jedes Projektmitglied in seiner Rolle entscheidend ist, muss Wissen frei im Team fließen können, mindestens zwei Personen sollten deckungsgleich informiert und mit den selben Kompetenzen ausgestattet sein. Das nennt man den “Truck-Factor”. Bildlich wäre dies in etwa so: Geht ein Teammitglied über die Straße und wird von einem LKW überrollt, muss es trotzdem weiter gehen können. Etwas makaber vielleicht, aber die Vorsichtsmaßnahme ist auch in weniger dramatischen Fällen sicherlich sinnvoll. Nur durch eine Überdeckung von Kompetenzen im Team bis zu 100% kann jede hoch priorisierte Aufgabe zu jeder Zeit erledigt werden. Sind Teammitglieder neben einem Projekt auch noch in andere Projekte oder Tagesgeschäft eingebunden, führt dies unweigerlich dazu, dass nicht zu jeder Zeit jemand verfügbar ist, der sich auskennt und Wissen nicht zu jederzeit geteilt werden kann. Multi-Projekt-Tätigkeit erzeugt also einen “Kommunikations-Overhead”, der die Produktivität einschränkt und Agilität konterkariert.
Tipp 3: Das Projekt sollte in kleinen Schritten geplant und ausgeführt werden können
Agile Projektarbeit organisiert sich entgegen statischer (traditioneller) Projektarbeit kleinteilig. In statischen Projekten wird das gesamte Vorhaben vor dem eigentlichen Start möglichst umfangreich geplant, um dann im Anschluss abgerollt zu werden. Bei agilen Projekten wird versucht in möglichst kurzer Zeit “timeboxed” bereits einen kleinen Teil fertig zu stellen. Daher kommen auch die sog. “Sprints”, also kurze Zeitabschnitte, in denen funktional fertige Softwareteile hergestellt werden zum Einsatz. Diese können dann idealer Weise gleich mit echten Kunden getestet werden. Für Nicht-Software-Projekte stellt sich hier die Frage: "Wie kann das, was im Projekt erreicht werden soll, so weit zerlegt werden, dass bereits ein erstes Ergebnis nach sehr kurzer Zeit (zwei bis vier Wochen) vorzeigbar und testbar ist?" Man könnte dabei in Anlehnung an das “Minimum Viable Product (MVP)”, also übersetzt das minimal lebensfähige Produkt, vom “Minimum Viable Part (MVPa)”, also etwa einem minimal funktionalen Teil eines Projektes sprechen.
Es geht dabei immer darum, möglichst schnell, möglichst konkret zu werden. Der sog. “Design Sprint” (siehe auch Google Design Sprint) hat beispielsweise zum Ziel, in nur fünf Tagen echtes Feedback von Nutzern zu einem Produkt einzuholen. Mit dem gewonnenen Wissen wird dann entschieden, ob man weiter arbeitet, nochmal eine Schleife dreht oder an dieser Stelle aufhört.
Zeigt sich, dass die Richtung stimmt, wird “inkrementell”, also Teil für Teil und “iterativ”, also Schritt für Schritt, weiter entwickelt. So wächst das Produkt und nimmt Gestalt an. Das Gute dabei ist, dass bereits früh ein Produkt am Markt ist, das sich idealer Weise schon ein Stück weit refinanziert. So wird das Risiko des Scheiterns am Markt minimiert. Es wird also bewusst Raum für Experimente geschaffen, wo aus Fehlerndenen gelernt werden kann. Ein agiler Ausspruch lautet daher auch: "Fail fast, fail often, fail cheap".
Tipp 4: Der Auftraggeber sollte Teil des Projektteams sein
Auftraggeber im statischen Projektmanagement werden oftmals als Fremdkörper erlebt. Sie erteilen einen Auftrag, beschreiben das, was sie sich vorstellen so genau wie möglich und warten dann, bis das Ergebnis geliefert wird. Ja klar, das war sicher etwas verkürzt dargestellt. Natürlich sind Auftraggeber auch bei statischen Projekten eingebunden und erhalten von Zeit zu Zeit Einblick in das Ergebnis der Arbeiten. Meist jedoch sind die Abstände in denen Anforderungen vom Auftraggeber geäußert und Ergebnisse überprüft werden sehr lang. Auch hier spielt im agilen Projektmanagement die Zeit einerseits und die Kommunikation andererseits eine große Rolle.
Der Auftraggeber wird im Scrum “Product Owner” genannt. Dieser weiss, wohin er mit seinem Produkt möchte. Er erteilt die Anforderungen und sortiert zusammen mit dem “Scrum Master” die Anforderungen nach Business Value. Er beantwortet also die Frage: Welche der “Funktionen”, die hergestellt werden sollen wird wohl bei Fertigstellung die höchste Relevanz am Markt erzielen und sollte daher zuerst fertiggestellt werden? Wenn dies klar ist, startet das Team mit der Umsetzung der höchst priorisierten Anforderungen. Dabei wird nur das umgesetzt, was von essenzieller Bedeutung ist. Alle Schnörkel werden also erstmal weggelassen, bis sich das Produkt am Markt beweist (siehe Tipp 3).
Der Auftraggeber muss Teil des Projektteams sein, da er bei Rückfragen jederzeit zur Verfügung stehen soll. Nur so wird sichergestellt, dass das Team auch genau das umsetzt, was er sich vorgestellt hat. Denn häufig zeigt sich erst bei der Umsetzung, was in der Planung vergessen wurde.
Tipp 5: Alle am Projekt mitwirkenden sollten einem Team angehören
Baut man ein Haus wählt man meist das statische Projektmanagement. Es wird ein Bauplan erstellt, danach ein Ausführungsplan. Der Ausführungsplan enthält häufig auch einen Bauzeitenplan in dem genau geregelt ist, welcher Handwerker zu welcher Zeit auf der Baustelle ist. Die Koordination der verschiedenen “Gewerke” übernimmt ein Bauleiter. Die Monteure und Handwerker die nun auf die Baustelle kommen, um das Bauprojekt zu realisieren gehören meist nicht einem sondern verschiedenen Teams an. Häufig kommt es so zu Missverständnissen. Es fehlt einfach an der Abstimmung, an Kommunikation.
Im agilen Projektmanagement gehören alle am Projekt mitwirkenden einem Team an. Dieses Team steht in ständiger Abstimmung. Dafür sorgen einerseits regelmäßige Meetings. Mindestens einmal pro Tag wird der aktuelle Fortschritt besprochen, sodass jeder auf dem selben Stand ist. Knifflige Details werden anschließend in Einzelgesprächen geklärt und zusammen gelöst. Miss-Kommunikation ist dabei kaum möglich bzw. wird diese sehr schnell entdeckt.
Damit diese Abstimmung in kurzen Abständen gelingen kann, besteht ein agiles Team aus nur fünf bis neun Personen. Sollte dies nicht ausreichen, um ein Projekt zu realisieren, kann es mehrere agile Teams geben. Die Kommunikation zwischen den Teams ist ebenfalls geregelt und erfolgt in so kurzen Abständen wie möglich, sodass eine sehr enge Abstimmung möglich wird. So kommt es kaum zu Missverständnissen, die gravierende Auswirkungen haben.
Tipp 6: Veränderungen sollten zu jeder Zeit willkommen und möglich sein
“Die wollen schon wieder was Neues” hörte ich früher, als ich noch klassisch als Projektleiter tätig war, meine Projektmitarbeiter jammern. “Hätten die das mal vorher gesagt, dann hätten wir es berücksichtigen können. Jetzt ist es zu spät!” Dies klingt sicherlich nachvollziehbar und häufig folgte danach Streit wer die nun anfallenden Kosten für den “Change” tragen soll und ob es sich um eine “Korrektur” oder eine “Änderung” handele.
Es ist kaum vorstellbar, wenn man diese Art zu Arbeiten gewohnt ist, es ginge auch anders. Wie soll es möglich sein, dass man, einmal eine Richtung eingeschlagen, den Pfad auch wieder verändern können soll, ohne dabei große Teile dessen, was bereits erledigt wurde wieder abzureißen? Und häufig ist auch genau dies eine der größten Veränderungen die in einem Prozess erfolgen, wenn agiles Arbeiten gelingen soll. Das Buch “Lean Startup” gelangte zu Berühmtheit, da es zahlreiche Praktiken für die Softwareentwicklung beschreibt, die es möglich machen, Software so aufzubauen, dass Änderungen jederzeit möglich sind. Leider wurde noch kein Buch geschrieben, wie dies für Nicht-IT-Projekte gelingen kann. So müssen sich Teams die agil arbeiten möchten die Frage stellen, wie der Prozess zur Herstellung eines Produktes gestaltet werden kann, damit möglichst alle Änderungen zu jeder Zeit möglich bleiben. Zugegeben ist dies nicht immer zu 100% machbar, doch genau dies ist die Aufgabe, die es zu bewältigen gilt, damit Projektarbeit agil werden kann.
Ich hoffe, Sie haben einige Anregungen erhalten, welche Bedingungen es braucht, damit agile Projektarbeit gelingen kann.
Ich wünsche Ihnen viel Erfolg und Freude dabei!
Ihr, David Seifert