Agiles – versus klassisches Projektmanagement oder mehr Planung, weniger Status
Ich komme immer wieder in Organisationen, die sich inmitten einer agilen Transformation befinden. Meist ist den Teams und Mitarbeitern das Thema „agil“ mit schönen Begriffen „verkauft“ – aber doch eigentlich „verordnet“ worden. Wir müssen schneller werden, flexibler sein, lieferfähig bleiben, schlanker und leichtgewichtiger werden, und so weiter. Dann werden schnell noch alle Rollen, Tools und ein paar Kernprozesse eingeführt, die Methode wird’s schon richten.
Irgendwann, ein paar Wochen oder ein paar Monate später hat sich der gewünschte Erfolg oft nicht so richtig eingestellt und die erste Enttäuschung macht sich breit. Oft werden dann methodische Justierungen vorgenommen, die, ohne dass die Beteiligten es merken, das Rad wieder ein Stück zurückdrehen. Das macht es dann leider auch nicht besser.
Nach meiner Beobachtung liegt es häufig daran, dass den Akteuren zu Beginn der wesentliche Unterschied zwischen klassischem- und agilen Projektmanagement nicht richtig erklärt wurde. Das führt dazu, dass beim Justieren der agilen Methode, sich dann oft wieder Elemente klassischem Projektmanagements zurückmelden. Dabei sind die Unterschiede zwischen klassischem- und agilen Projektmanagement so fundamental, dass ein „customizen“ der Methode mit Elementen aus beiden Formen eher neue Probleme aufwirft oder falsche (weil unerfüllbare) Erwartungen weckt.
Ich spreche hier nicht von Unterschieden im doing, also den Rollen, Meetings, der Anwendung von Tools, etc. sondern ich spreche von den fundamentalen Unterschieden in der Perspektive auf ein Projekt, aus denen sich das doing dann ableitet.
In diesem Artikel möchte ich kurz ein paar dieser wesentlichen Perspektivunterschiede besprechen und anhand eines sehr praktischen Beispiels zeigen, woran wir erkennen können, ob wir noch agil sind, oder schon wieder rückfällig werden.
Agil führt eine neue Zeitrechnung ein
Zeit ist relativ, das kann man wohl sagen, denn agiles Projektmanagement stellt das Zeitkonzept des klassischen Projektmanagements geradezu auf den Kopf. Diese Tatsache ist so fundamental, dass es mich sehr wundert, warum in vielen Organisationen darauf kaum eingegangen wird. So fundamental ist sie deshalb, weil sich aus ihr doch eine ganze Reihe Konsequenzen für die Anwendung der Methode ergeben und es leider oft gerade diese Dinge sind, die Gegenstand der ersten (falschen) Kompromisse werden. Da kommt man recht bald an einen Punkt, an dem das ganze Gefüge in eine Schieflage kommt.
Auch das klassische Projektmanagement kennt durchaus Iterationen, die wiederum in einzelne Phasen unterteilt sind. Die Iterationen können einzelne Releases sein, oder ein Proof-of-Concept oder die Erstellung eines MVP (minimum viable product). Und natürlich gibt es eine ganze Reihe von Meilensteinen, die in keinem Reporting fehlen dürfen. Aber die Phasen einer Iteration sind im klassischen Projektmanagement immer inhaltlich bestimmt, niemals zeitlich.
Die Phase der Spezifikation ist abgeschlossen, wenn die Spezifikation fertig ist, die Implementierungsphase ist abgeschlossen, wenn das Produkt oder Teilprodukt fertig ist, die Testphase ist abgeschlossen, wenn alle vorgesehenen Tests durchgeführt wurden, und so weiter.
Daran ändert auch die Tatsache nichts, dass diese Phasen vorab zeitlich geplant sind, was wir immer so schön an den Gantt-Charts ablesen können. Übrigens – und weil es gerade so schön passt – immer wenn Sie ein Gantt-Chart im Reporting auftauchen sehen, befinden Sie sich eigentlich schon wieder im klassischen Projektmanagement.
Im agilen Projektmanagement wird ein anderes Zeitkonzept verwendet. Und ich denke an dieser Stelle wird schon klar, warum man beide Projektmanagement-Formen nicht mischen sollte. Denn gleichzeitig mit zwei unterschiedlichen Zeitkonzepten zu hantieren, wäre wohl auch für Einstein der Relativität ein wenig zu viel. Agiles Projektmanagement arbeitet strikt „timeboxed“, das heißt, die Iterationen sind abgeschlossen, wenn der Wecker klingelt und die timebox abgelaufen ist.
Ob Sie dann schon ausgeschlafen sind oder lieber noch liegenbleiben würden, interessiert den agilen Projektmanager nicht, es wird jetzt aufgestanden. Die kleine Metapher sagt nur, dass uns dieses Konzept im täglichen Leben durchaus vertraut ist. In unserem Alltag nutzen wir für verschiedene Dinge auch unterschiedliche Konzepte, aber wir mischen sie eben nicht.
Im agilen Projektmanagement richten sich die Inhalte also nach der Timebox, und nicht umgekehrt wie im klassischen Projektmanagement. Storys müssen so klein geschnitten werden, dass sie in einen Sprint passen, usw. Der Grund für diesen Perspektivwechsel ist relativ naheliegend. Agiles Projektmanagement kommt zum Einsatz, wenn wir uns schwertun, die zu implementierenden Dinge vollständig zu erfassen, entweder weil uns die Zeit fehlt (time-to-market), oder weil sie zu komplex sind, oder sich schnell ändern könnten.
Die Konsequenzen, die sich für agiles Projektmanagement daraus ergeben, sind natürlich weitreichend und sie erklären so viele Dinge der agilen Methodik. Zuerst erklären sie, warum die Iterationen natürlich kurz sein müssen. Eine ein- bis zweiwöchige Timebox (Sprint) kann man noch einigermaßen gut planen, eine dreimonatige Timebox schon nicht mehr.
Das Ganze macht nur Sinn, wenn die Sprints dann auch erfolgreich abgeschlossen werden, d.h. Sprint-Commitments sind im agilen Projektmanagement kein nice-to-have, wie man leider annehmen könnte, wenn man sich so die Sprint-Accuracy der meisten Teams anschaut, sondern absolut essentiell. Das ganze Timebox-Prinzip wird komplett ausgehebelt, wenn Sprints immer wieder nicht abgeschlossen werden, die Organisation begibt sich dann in genau den Blindflug, dem sie eigentlich entkommen wollte. Heißt, wenn das nicht gehalten wird, könnte man auch gleich wieder klassisches Projektmanagement machen.
Nach meiner Meinung ist das der wichtigste Unterschied zwischen beiden Formen, der im Rahmen einer agilen Transformation sehr klar und präzise herausgearbeitet werden sollte. Denn hat man das getan und behält das auch immer im Blick, kann eigentlich gar nicht mehr so viel schiefgehen.
Kommen wir zu einem weiteren Unterschied bevor wir zum Titelthema kommen.
SCRUM kennt nur drei Rollen
Während Organisationen im klassischen Projektmanagement dazu tendieren, für jedes neue Problem einen neuen Prozess und auch gleich ein paar neue Rollen zu erfinden, geht agiles Projektmanagement auch hier einen anderen Weg und macht genau das Gegenteil. SCRUM kennt nur drei Rollen. Damit ist nicht das gesamte agile Projektmanagement eingeschlossen, aber es illustriert das Prinzip. SAFe zum Beispiel kennt natürlich auf Organisationsebene noch ein paar mehr Rollen, aber es bleiben wenige und vom Prinzip der statischen Rollen wird nicht abgewichen. Bleiben wir kurz bei SCRUM als Basis von SAFe und anderen.
Egal, wie das Projekt beschaffen ist, was implementiert werden soll, welche Technologie, Komplexität, Teamsetup, etc. Es gibt nur drei Rollen. Das macht es so wichtig, dass die Organisation auf eine ganz klare Beschreibung der Rollen achten muss und darauf, wie die Rollen zusammenarbeiten. Oft sehe ich, dass es gar nicht so klar geregelt ist, welche Kompetenzen Scrum Master auch gegenüber Product Owner so haben. Im Detail habe ich die Rollen hier beschrieben. An dieser Stelle geht es nur darum, den Unterschied zum klassischen Projektmanagement herauszuarbeiten.
Denn dieser führt unweigerlich zum nächsten Unterschied, der ebenfalls von großer Bedeutung ist.
Prozesse versus Menschen
Der Faktor „Mensch“ spielt im agilen Projektmanagement eine zentrale Rolle. Das soll jetzt nun weder bedeuten, dass klassisches Projektmanagement sich nicht auch um Personalentwicklung kümmert noch soll es bedeuten, dass agiles Projektmanagement – wie Karl Marx es vermutlich ausdrücken würde – die Ausbeutung der menschlichen Arbeitskraft auf die Spitze getrieben hat. Obwohl ich gestehen muss, dass an der Kritik vermutlich sogar etwas dran ist, zumindest legt es die steigende Burnout-Rate in unserer Branche in gewisser Hinsicht nahe. Aber das ist ein anderes Thema.
Während sich klassisches Projektmanagement mehr mit Prozessen, Architekturen und Organisationsstrukturen beschäftigt, legt agiles Projektmanagement den Fokus fast ganz und gar auf die Akteure selbst. Auch dieser Perspektivwechsel kommt nicht ganz von ungefähr und erklärt sich genauso wie oben mit den Voraussetzungen, die zum Einsatz von agilem Projektmanagement führen. Um es einfach auszudrücken, die Voraussetzungen sind so dürftig (wenig Zeit, wenig überschaubare, weil hohe Komplexität, hohe Volatilität), dass außer den Akteuren, die es richten sollen, kaum etwas da ist, auf dem sich Prozesse, Strukturen oder gar verlässliche Architekturen planen ließen.
Wir müssen also die Menschen befähigen, mit diesen Situationen umzugehen, statt sie wie Schachfiguren einfach nur mit dem richtigen Skill und der richtigen Aufgabe an den richtigen Platz zu stellen. Aus Programmierern werden Entwickler. Das kreative Potential aber auch die soziale Integration müssen wesentlich mehr gefördert werden. Ich sage nicht, dass das im klassischen Projektmanagement nicht auch schon eine Rolle gespielt hat, aber es erreicht hier definitiv ein neues Level.
Auch hier sind die Konsequenzen weitreichend. Agiles Projektmanagement ist konsequent Teamarbeit. Maximale Transparenz, kurze, direkte und kreative Kommunikation in selbstorganisiert arbeitenden Teams, das Herausbilden einer DevOps Kultur, all das spielt in diesem Zusammenhang eine zentrale Rolle und charakterisiert agiles Projektmanagement.
Aber was hat das alles mit dem Titelthema zu tun? Alles.
Kehren wir zum Anfang des Artikels zurück. Viele Projekte haben vergessen, die oben genannten wesentlichen Unterschiede beider Formen zu erklären, sind irgendwie und etwas mechanisch in die agile Transformation reingerutscht. Nach einer Weile funktioniert das nicht so gut und eine der häufigsten Reaktionen auf diese aufkommende Unzufriedenheit und Enttäuschung ist ein natürlicher Rückfall in das Micro-Management.
Der erste Schritt in diese Richtung ist das schwindende Vertrauen in die Methodik und die Akteure. Der zweite Schritt – und das bedeutet Micro-Management praktisch – sind das Einführen von zahllosen Statusmeetings, jour fixes und noch mehr Status-Reports. Selbst viele Daily-Standup verkommen zum Statusmeeting, in dem den Leuten diese drei Fragen gestellt werden (was hast Du gemacht, was planst Du heute zu tun, welche Impediments, bla bla bla). Die vormals agilen Meetings bleiben oft dem Namen nach bestehen – wir machen plötzlich ein Stand-up Statusmeeting – werden aber komplett umgedeutet. Gleiches passiert dann auch mit den Reports, die dann immer wieder mehr gegen 100% reporten (auch das geht ja nur im klassischen Projektmanagement, wo die 100% einmal definiert wurden.
Agiles Projektmanagement lebt nicht von Statusmeetings und Reports, sondern vom permanenten Planning.
Merkwürdig, denn Planung ist doch eigentlich ein Begriff, der dem klassischen Projektmanagement zugeschrieben wird. Aber das genaue Gegenteil ist der Fall. Im klassischen Projektmanagement wird – das ist jetzt natürlich stark übertrieben – nur einmal eine große Planungsphase zu Beginn durchlaufen. Ab dann wir nur noch der Status des Fortschritts gegen die Planung festgestellt. Im agilen Projektmanagement wird dagegen permanent geplant, nicht nur vor jeder Iteration, sondern wirklich permanent, also täglich.
Selbst ein Daily-Standup ist eigentlich ein Planungsmeeting. Da spielt eigentlich nur die Frage „wie bekommen heute gemeinsam diese und jene Story fertiggestellt und wer macht dabei was und wann“ wirklich eine Rolle, mindestens aber die Hauptrolle. Und das ist keine Frage, die sich – wie im Statusmeeting – reihum von jedem einzeln beantworten lässt, sondern das sollte eine sehr lebendige Teamdiskussion sein.
Auch in den agilen Boards setzt sich das Dilemma in unzähligen Status fort. Was es damit auf sich hat, habe ich hier beschrieben. Wir brauchen nur drei Status (open, in progres, done) und alles andere (in testing, in review, in deploymet, etc.) sind Aktivitäten, die Gegenstand von Planung sein sollten. Ein Status kann ich nicht planen, eine Aktivität (Subtask) dagegen schon.
Das Ergebnis unserer permanenten Planungen lässt sich dann sehr schnell in sehr wenigen KPI’s ablesen bzw. durch den Einsatz von sehr kurzen Iterationen (z.B. einwöchige Sprints) im Review in Form der Inspektion der Arbeitsergebnisse direkt ansehen. Man könnte auch sagen, das Ergebnis zählt. Wie das selbstorganisierte Team, dem wir unser Vertrauen geschenkt haben, das hinbekommen hat, müssen wir doch eigentlich nicht ständig kontrollieren.
Die Statusmeetings dokumentieren leider eher das fehlende Vertrauen der Projektleitung und ihr Unbehagen dem gefühlten Kontrollverlust gegenüber. Das tragische daran ist, dass durch die Wiedereinführung der Statusmeetings und der Berichtsebene fast automatisch das permanente Planen zu kurz kommt. Das ist wie ein Reflex, ausgelöst dadurch, das Planning natürlich auch etwas mehr Mühe macht sowie Kommunikation und Kreativität erfordert, als einen Status-Report zu pflegen und sich der Hoffnung hinzugeben, es würde dann schon laufen.
Die Existenz bzw. die Zunahme von Statusmeetings und jour fixes ist jedenfalls immer ein Indiz dafür, dass eine Organisation sich von klassischem Projektmanagement entweder noch nicht entfernt hat oder gerade wieder dabei ist, es zurückzuholen. Verstehen Sie mich nicht falsch. Dass Mitglieder einer Organisation sich synchronisieren und up-to-date bleiben, ist im agilen Projektmanagement absolut wichtig, sowohl in vertikalen Feature Teams als auch in horizontalen Gilden, Community of Practices, etc.
Aber das ist etwas anderes und auch das kann im Rahmen von Planungen oder Reviews (bzw. Inspect & Adapt Sessions) und Retrospektiven sehr viel besser und zielführender funktionieren. Alle diese Meetings beinhalten nämlich immer auch eine Planungsebene: Retrospektiven: was können wir künftig besser machen; Inspect & Adapt, sagt der Name schon; Daily Standup: wie oben erwähnt; Review: wie ist das Ergebnis und was fehlt noch.
Es lohnt sich an der Abschaffung der Statusmeetings zu arbeiten. Es schafft mehr Vertrauen und wirkt dadurch für die Akteure auch gleich viel motivierender. Es erfordert am Anfang etwas Mut gegen den eigenen Kontrollverlust anzukämpfen, aber es bringt Organisationen schneller voran als das Festhalten an – um im Kontext zu bleiben – aus der Zeit gefallenen Praktiken.
