Dogmatische Agilität ist auch wieder irgendwie unflexibel

„Agil“ ist in den letzten Jahren eines DER Schlagwörter überhaupt. Teams arbeiten agil, modernes Management ist agil. Die Neuorganisation klassischer Produktionsprozesse im agilen Framework ist total wichtig. Alles ist irgendwie agil – und wie immer, wenn ein Trend seinen Zenit erreicht, müssen wir uns fragen: Was von der ganzen Begeisterung ist Hype und was bringt uns wirklich etwas? Bei Meisterplan arbeiten wir auch (im Sinne von teilweise) agil und unser Fazit ist: Agil als Option ist super, Agil als Dogma ist unflexibler Mist.

Warum wurde Agil so erfolgreich?

Die Antwort auf diese Frage ist eigentlich ganz einfach: In sehr vielen Fällen ist das agile Framework klassischen Projektmanagementmethoden einfach überlegen. Das herkömmliche (veraltete?) Wasserfallmodell mit seinen Milestones und Deadlines und Ressourcenplänen erzeugt beim Start komplexer Projekte oft Pläne, von denen alle genau wissen, dass sie nie und nimmer umgesetzt werden können. Kein Plan überlebt den Erstkontakt mit dem Feind – und der Feind ist hier die Realität. Außerdem basiert das Wasserfallmodell auf der Idee, dass das Ziel eines Projekts zu Beginn bekannt ist und dass wir zu Beginn abschätzen können, was wir tun müssen, um dieses Ziel zu erreichen. Im echten Leben sind all diese Annahmen oft kompletter Unsinn. Das ändert aber nichts daran, dass wir alle nachts schlechter schlafen, wenn wir mehr und mehr hinter einem Projektplan zurückfallen. Zumindest wenn die Gefahr besteht, dass wir dafür die Verantwortung übernehmen müssen (und irgendwer wird die Verantwortung dafür übernehmen müssen). Das agile Framework lügt sich in diesen Punkten nicht in die Tasche. Im Gegenteil, es bejaht sie noch. Wir wissen nicht, wie das Endprodukt aussieht, wir haben keine Ahnung, wie wir da hinkommen, und daher kann auch keiner so genau sagen, wann das der Fall sein wird. Wir arbeiten agil Baby… und Deadlines sind total 90’er.

Diese Ehrlichkeit stellte sich nicht nur als emotional befreiend heraus. Agile Teams zeigten schnell, dass sie mit ihrem flexibleren Framework oft günstiger und schneller bessere Produkte erzeugen konnten. Und das ist dann auch spätestens der Punkt, an dem nicht nur Teams, sondern auch das Management neugierig wird.

Also, alles auf Agil?

Damit wäre ja eigentlich alles gesagt. Schneller, günstiger und besser? Weg mit dem Wasserfall, her mit dem agilen Framework. Blogpost Ende.

via GIPHY

.
.
.

OK, vielleicht ist doch noch das ein oder andere zu sagen.

Kein Deckel passt auf jeden Topf

Agiles Arbeiten ist super für bestimmte Arten von Projekten. Die wichtigsten Punkte wurden weiter oben bereits angedeutet, aber wir schauen sie uns noch einmal genauer an.

Wir wissen nicht, wie das Endprodukt genau aussieht: Nicht immer ist zu Beginn eines Projektes klar umrissen, was dessen Ziel ist. Vielleicht geht es darum, eine Lösung für Problem X zu finden, aber es noch nicht klar, auf welcher Plattform die Lösung am Ende laufen wird. Oder welche Features dafür benötigt werden. Oder Sie entwickeln eine neue Baugruppe für ein komplexes Produkt und werden Ihr Design im Verlauf des Entwicklungsprozesses an das Design anderer Projektteams anpassen müssen, die andere Baugruppen für das gleiche Endprodukt entwickeln. In solchen und ähnlichen Fällen eignet sich die agile Methode besonders gut, einfach schon, weil das klassische Wasserfallmodell so ungeeignet ist. Für agile Teams ist es völlig in Ordnung, zu Beginn nur eine vage Ahnung eines schwammigen Ziels zu haben, dem sie sich iterativ annähern. Diese Unsicherheit zu akzeptieren, gibt den Teams zudem die Möglichkeit, den Kunden immer wieder in den Entwicklungsprozess einzubeziehen, was oft in einem Produkt resultiert, das diesen glücklicher macht. Und glücklichere Kunden ist, was wir im Endeffekt alle wollen.

Wir wissen nicht, wie wir da hinkommen: Selbst wenn das Endprodukt klar beschrieben werden kann, ist der Weg dahin nicht immer klar. Vielleicht ist schon ganz zu Beginn absehbar, dass das Projekt Ihre Ingenieure vor Herausforderungen stellen wird, die nicht absehbar sind. Um einige Beispiele zu geben: Vielleicht merken Sie nach einem Jahr, dass Sie für das Produkt ein Schmiermittel mit völlig neuen Eigenschaften entwickeln (lassen) müssen. Oder der Projektverlauf ist von den Ergebnissen physikalischer Grundlagenforschung abhängig, die erst nächstes Jahr in Cern beginnt. Oder Sie arbeiten in der Softwarebranche. Egal, was der Grund ist, wenn der Weg zum Ziel eher einem Labyrinth als einer gradlinigen Hindernisbahn gleicht, ist die agile Methode vermutlich die bessere Wahl.

Wir wissen nicht, wann das Projekt fertig sein wird: Das ergibt sich im Wesentlichen aus den ersten beiden Punkten. Wir wissen, nicht, wo es hingeht, und wenn wir es wissen, kennen wir den Weg nicht. Unter solchen Bedingungen mit harten Deadlines zu arbeiten, ist natürlich schwierig.

Wenn man sich diese Punkte ansieht, überrascht es eigentlich nicht mehr, dass agiles Arbeiten zuerst in der Softwareindustrie populär wurde. Was in vielen anderen Branchen als zusätzliche Herausforderung gesehen würde, ist in der Softwareentwicklung schlichtweg normal. Etwas überspitzt gesagt: Bei längeren Projekten können Sie sich nicht einmal sicher sein, auf welchen Geräten Ihre Lösungen am Ende laufen werden. Und Sie können schlichtweg nicht wissen, welche Bugs Sie auf dem Weg zum Ziel beseitigen müssen. Aber: Nicht alle Projekte in allen Branchen unterliegen den hier genannten Unsicherheiten (Ziel, Weg, Dauer). Wenn es Ihr Projekt ist, ein Fertighaus Modell X6543a5 aufzubauen, haben Sie vermutlich eine sehr genaue Vorstellung davon, was Sie tun müssen. Und selbst in der Softwareentwicklung gibt es Projekte, bei denen eigentlich sehr klar ist, was wann getan werden muss und wie lange das in etwa dauern wird. Natürlich könnte man diese trotzdem agil bearbeiten, nur … was ist der Vorteil? Insbesondere wenn man bedenkt, dass das Wasserfallmodell mit seiner konkreten Planung und klar kommunizierten Deadlines auch Vorteile hat. Verzichten wir auf diese, nur um agil zu sein?

Die Lösung: Die Teams entscheiden lassen

OK, halten wir fest: Für manche Projekte ist agiles Arbeiten besser, für andere klassischere Ansätze wie das Wasserfallmodell. Und wer entschiedet das jetzt konkret?

Unser Tipp: Das Management sollte „agil“ genug sein, diese Entscheidung den Teams zu überlassen, die das Projekt tatsächlich durchführen. Wichtig ist der Projekterfolg, nicht, wie er erzielt wird. Statt die Teams in eine bestimmte Projektmanagementmethode zu zwängen, sollte das Management in der Lage sein, bei der Planung sowohl agile als auch nicht-agile Teams zu berücksichtigen. Das Management entscheidet, was gemacht wird, die Teams, wie es gemacht wird. Wir haben an anderer Stelle (z. B. hier und hier) ausführlich darüber geschrieben, wie sich das bewerkstelligen lässt, daher hier nur in aller Kürze: 1) Das ist viel einfacher, als es klingt und 2) Wir empfehlen die Lean PPM als Methode für die Portfolioplanung.

Agile Religion

So weit, so pragmatisch. Es gibt hier jedoch ein Problem. Das Zeitalter des agilen Projektmanagement startete nicht mit dem Dokument „Agil: Ein Verbesserungsvorschlag zur flexibleren Organisation von Projektteams“, sondern mit einem Manifest. „Agil“ war nie nur eine alternative Methode, um Projekte zu managen, sondern auch, zumindest für manche, ein Gegenentwurf zu verkrusteten Strukturen und stagnierender Unternehmenskultur. „Agil“ hat seine eigene, teilweise recht arkane Sprache sowie seine eigenen Regeln entwickelt – und eine Menge Argumente, warum „Agil“ besser ist als alle andere Projektmanagementmethoden. „Agil“ erscheint in dieser Perspektive als mehr als nur eine Projektmanagementmethode, es wird zur Überzeugung, zu einer Lebenseinstellung. Zu einer Subkultur. Wenn wir es (total) überspitzt sagen wollen: „Agil“ hat manchmal etwas von einem quasi-religiösen Kult. Lasset die Ursünde Deadline hinter euch und betretet das himmlische Reich der flexiblen Arbeitswelt von morgen. Projekte werden agil gemacht, weil das eben besser ist. Unternehmen versuchen, 100% agil zu arbeiten, weil das gut klingt.

Wir finden agiles Arbeiten super, aber denken, dass es der falsche Weg ist, agil zu arbeiten, nur um agil zu arbeiten. Ironischerweise ist das auch nicht sonderlich „agil“ im eigentlichen Wortsinne.

Eigenlob stinkt …

…aber wir sind bereit, hier mal ein bisschen rumzumüffeln. Bei Meisterplan sind wir ein Team von über 40 Leuten, haben aber mindestens 10 verschiedene Tools im Einsatz, wir haben agile Teams, traditionelle Projekte, Run the Business und Change the Business Kapazität und Mitarbeiter, die auch mal einfach machen – ohne Projekt. Und das ist gut so. Das ist fast die maximale Freiheit! Wenn wir für einen Moment unsere (wirklich übertriebene) Metapher von „Agile“ als quasi-religiösem Kult mit Neigung zum Dogmatismus akzeptieren, dann ist Meisterplan eine ökumenische Gemeinde, zu der eine Menge Häretiker gehören, die mal so und mal so arbeiten.

Klingt chaotisch? Ist es nicht! Wir machen einfach nur für uns selbst, was wir auch verkaufen. Wir trennen die Fragen „Was machen wir?“ und „Wie machen wir das?“. Und wir müssen den Teams die Antwort auf die zweite Frage nicht vorschreiben, um die erste zu beantworten. Das einzige, was die Teams dem Management für diese Freiheit „schulden“, ist sich zu festgelegten Zeitpunkten am Planungsprozess (Lean PPM) zu beteiligen. Für die Planung verwenden wir Meisterplan (Überraschung), was es uns erlaubt, alle laufenden „Projekte“ in einer Planungsansicht zu visualisieren, egal, ob die Teams agil arbeiten oder nicht (Jira Integration!). So können wir ein Portfolio erstellen, das unseren strategischen Zielen entspricht – und die Teams wissen bei ihrer Arbeit stets, wie diese ins Gesamtkonzept unserer Unternehmensstrategie passt. OK, damit haben wir uns genug an unserer eigenen Großartigkeit berauscht.

.end().eigenlob

Unser Fazit: Agil als Option ist super, Agil als Dogma ist unflexibler Mist.

.end().article

Diesen Beitrag haben wir im Rahmen der Blogparade des projektmagazins zur PM Welt 2019 verfasst.

Über die PM Welt:
Am 15. Mai 2019 veranstaltet das Projekt Magazin zum vierten Mal in Folge die PM Welt – das Treffen der größten Projektmanagement-Community im deutschsprachigen Raum und erwartet rund 700 Teilnehmer. Das Motto in diesem Jahr: “Einfach anders! Projekte neu gemacht.” Die Fragestellung: Wie können Unternehmen, Projektleiter und Teams in ihren Projekten ausgetretene Pfade verlassen und gerade dadurch erfolgreich sein?