Mythen und Polemik

von Thomas Starz | Okt 15, 2019 | Agil

„Wir müssen agiler werden!“

Jeder kennt es: In der Kaffeeküche geht es mal wieder hoch her. Jemand hat eine Behauptung rausgehauen und jetzt prallen die Meinungen aufeinander. Wir haben uns mal 5 dieser Behauptungen herausgegriffen, die wir in letzter Zeit immer wieder mal gehört haben – und mit unserem gesammelten Wissen eine Antwort formuliert.

„Agilen Methoden sind besser“

Wortwörtlich genau so oft gehört. Gemeint ist meist, „sind besser, als der aktuell gelebte (Wasserfall-)Prozess“.

Manchmal.

Aber das hängt im Wesentlichen davon ab, mit welcher Art Anforderungen man es zu tun hat. Weiß man ziemlich sicher und genau, wie eine Lösung aussehen soll, bringt agiles Vorgehen u.U. keinen Vorteil.

Sind die Anforderungen jedoch eher unklar, man weiß nicht, ob der Kunde bestimmte Funktionen wirklich braucht und wie diese zu implementieren sind – dann muss man mit höherer Unsicherheit und mehr Risiken im Projekt umgehen. Dann muss man akzeptieren, dass ein Plan sich ändern wird, dann benötigt man Anpassungsfähigkeit und die Möglichkeit, schnell und leichtgewichtig Entscheidungen zu treffen und die Richtung zu justieren.

Bottom Line: Agil zu arbeiten empfiehlt sich bei manchen Aufgabenstellungen mehr, bei anderen weniger.

Und nicht jedes Unternehmen kann agil arbeiten. Ein Unternehmen benötigt einen gewissen Reifegrad, um Selbstorganisation zuzulassen und effektiv und effizient agil zu arbeiten. Manchmal passen die organisatorischen Strukturen (noch) nicht zum agilen Denken. Bevor dann irgendeine neue Methode eingeführt wird, scheitert, zu Frust führt und verflucht wird, ist es manchmal besser, bei den bekannten klassischen Methoden zu bleiben und sich Stück für Stück weiter zu entwickeln. Aber: Einfach ist das nicht.

Was auf jeden Fall nicht funktioniert: Das Management ordnet an, „Wir sind jetzt agil“, und versteht nicht, was wirklich dahintersteckt. Und dann werden blind irgendwelche Berater engagiert und „Agile Methoden“ eingeführt. Am Besten noch mit vielen Schulungen und Zertifizierungen. Das ist teuer, aber im besten Fall unwirksam.

„Agil bedeutet, nach zu Scrum arbeiten“

Oft wiederholt und trotzdem falsch. Scrum kann der Rahmen sein, der mir dabei hilft, Agilität zu leben. Kann, muss aber nicht.

Ich kann mit Scrum herrlich un-agil sein, genauso kann ich sehr agil sein, ohne Scrum zu nutzen.

Agil zu arbeiten heißt, anpassungsfähig zu sein und die agilen Werte und Prinzipien zu leben. Die Methode ist dabei nicht so wichtig – so lange sie uns nicht behindert.

„Wir brauchen agiles Projektmanagement“

Genaugenommen gibt es weder Wasserfall-Projektmanagement, noch agiles Projektmanagement – und schon gar kein hybrides Projektmanagement.

Es gibt sehr viele unterschiedliche Techniken und Praktiken im professionellen Projektmanagement. Diese sind für bestimmte Projekte mehr oder weniger sinnvoll und Projektmanager sollten das Können und die Freiheit haben, diese pragmatisch und (hoffentlich) passend zu den Gegebenheiten im Projekt anzuwenden.

Denn natürlich brauchen wir auch bei agilen Vorhaben eine funktionierende Planung und Vorhersagbarkeit. Ja, wir planen vielleicht leichtgewichtiger und vor allem nur das, was sinnvoll geplant werden kann, soll, oder muss. Wir machen kein Projektmanagement des Projektmanagements willen – aber war das nicht eigentlich schon immer so?

Unser Projektmanagement muss also agiles Arbeiten unterstützen und darf es nicht behindern. Manchmal muss ich ausprobieren, lernen und mich anpassen. Aber manchmal muss ich auch etwas längerfristig planen und den Überblick über Termine behalten. Das hängt davon ab, wie gut der Kunde schon weiß, was er braucht – und von der Klarheit, wie er diesen Bedarf ausdrücken kann. Es hängt nicht von den Werkzeugen ab, die ich im Projektmanagement verwende.

Manchmal sind die klassischen Tools hilfreich, manchmal sind sie zu schwergewichtig. Manchmal sind neue Techniken sinnvoll, manchmal reichen sie nicht aus. Wir nutzen, was sinnvoll ist.

„Agil bedeutet, nicht planen zu können und nicht zu wissen, was wann geliefert werden wird“

Im Gegenteil. Denn: Gibt mir die klassische Planung wirklich Sicherheit? Ich kenne kein klassisch abgewickeltes Projekt, das am Ende so geliefert wurde, wie zu Beginn gedacht. Projekte sind nun einmal neuartig, risikoreich, dynamisch und häufig komplex.

Agil sein heißt, dies zu akzeptieren und Schritt für Schritt vorzugehen – und regelmäßig zu validieren, ob wir noch auf dem richtigen Weg zum richtigen Ziel sind. Um mit Hilfe dessen, was wir aus den bereits erzeugten, sicht- und anfassbaren Teilergebnisse gelernt haben, die bestmöglichen Entscheidungen für unsere weitere Arbeit zu treffen.

Letztendlich ist das magische Dreieck, das Kosten, Inhalt und Zeit in Beziehung bringt, immer gültig. Und die Aussage, dass man Kosten, Inhalt und Zeit vorhersagen und festzurren kann, war noch nie richtig und wurde auch von wirklich professionellen Projektmanagern nie behauptet. Eigentlich logisch, denn dann bräuchte man ja auch kein Projekt-Management mehr, dann würde eine Projekt-Verwaltung vollkommen ausreichen.

„Das Projekt ist zu groß für Agil“

Große Projekte heißt, viele Beteiligte. Viele Beteiligte benötigen viel Interaktion. Je komplexer die Aufgaben, desto mehr Interaktion ist notwendig. Agiles Vorgehen erhöht die Anforderungen an die Häufigkeit der Interaktion.

Sind die Möglichkeiten und Fähigkeiten zur Interaktion und die notwendigen Freiheitsgrade für ausreichend schnelle Entscheidungen vorhanden, dann funktionieren Vorhaben. Wenn nicht, dann nicht.

Mit klassischen Methoden kann Komplexität und die Notwendigkeit für späte und schnelle Entscheidungen reduziert werden – das funktioniert jedoch nur, wenn die Anforderungen bekannt sind. Sind die Anforderungen, auch teilweise, unklar, bleibt keine Wahl: Viele Entscheidungen können nicht gleich zu Beginn eines Vorhabens endgültig getroffen werden. Und dann sind die Projekte vielleicht zu groß für die Fähigkeiten einer Organisation – bzw. vielleicht kann die Organisation nicht agil genug sein. Das liegt dann aber nicht an der Methode.