👋 Schön, dass Du hier bist! Bitte beachte, dass dieser Artikel bereits einige Jahre auf seinem Buckel hat. Seitdem haben sich nicht nur die Welt, sondern auch meine Wissenslücken, Erfahrungen und Ansichten geändert. Dennoch stehe ich hinter den Aussagen, die ich damals getätigt habe. Selbst dann, wenn ich sie mittlerweile anders tätigen würde. Bitte behalte dies beim Lesen im Hinterkopf. Danke. Und viel Vergnügen!
Was Agilität für mich mit (viel) Effizienz und (oft wenig) Kundenwert zu tun hat und warum Kekse nicht immer gut sind.
“Come to the dark side. We have cookies.” #
Vorneweggeschickt: ich beobachte das Thema heute rein aus Projektmanagementaugen. Und da ist Agilität ja an sich eine tolle Sache. Aber was ist eigentlich das Tolle daran? Warum finden viele Agilität so großartig? Weil sie anders ist. Ein anderer Ansatz, Dinge zu erledigen. Ein anderer Ansatz als der, den viele Organisationen so leben. Denn sind wir uns ehrlich. Auch heutzutage gibt es noch unglaublich viele Firmen, deren Führungsebene der festen Überzeugung ist, C2 - Command and Control - sei die beste Herangehensweise, um ein produktives und florierendes Unternehmen zu haben. Und für so verkrustete, behäbige Strukturen klingt ein agiler Ansatz natürlich toll. Waghalsig zwar, aber sehr verlockend. Schnellere Entscheidungen, schnellere Umsetzungen, geringere Time-to-Market. Anders eben.
Aber ist anders besser?
Argumente #
Auch auf die Gefahr hin, dass ich wieder mal der Neinsager bin. Was gibt es an einem agilen Ansatz, an Agilität eigentlich und überhaupt auszusetzen? Und ja, ich jammere hier auf einem sehr hohen Niveau, das ist mir durchaus bewusst.
Wenn wir mal von den Argumenten absehen, die ich von einem bestimmten Typ Softwareentwickler immer wieder höre (“Agilität ist schlecht, weil ich 20 Jahre lang gut ohne Agilität ausgekommen bin. Das war eine tolle Zeit! Die Kunden waren uns egal und wir haben jede Nacht Bugs gefixt.”) - also, Anführungszeichen, Argumente, Anführungszeichen. Aber ich denke, das habt Ihr alle schon ein paar mal erzählt bekommen.
Ein paar Punkte, die für mich bei dem, was aktuell so unter “Agilität” (was für ein Buzzword da draus geworden ist, traurig eigentlich) verstanden wird, eher unrund sind:
Nicht jede Firma stellt Software her #
Agile Methoden haben einen wahnsinnig starken Fokus auf Softwareentwicklung. Ja, es wird besser. Aber egal, ob das jetzt ASD, Scrum, DSDM, oder - Gott bewahre! - SAFe ist. In ihren Ursprüngen waren das durch die Bank Methoden, die teils sogar von Programmierern entwickelt wurden und die auf jeden Fall Programmierer im Auge hatten. Und auch das agile Manifest heißt nach wie vor offiziell Manifesto for Agile Software Development. Und wo werden agile Methoden als erstes in Unternehmen eingeführt? Meiner Beobachtung nach im überwältigenden Großteil der Fälle in der IT-Abteilung bzw. konkreter in der Softwareentwicklung.
Nur was habe ich davon, wenn die IT agil ist, die restlichen 95% meiner Wertschöpfung aber nicht? Chaos an den Schnittstellen. Und ja, Kanban kann da sehr viel bewirken. Aber - und jetzt muss ich vorsichtig sein - Kanban gehört eigentlich nicht dazu, wenn in der Literatur so von "agil" die Rede ist. Mit Kanban sind wir eher im Bereich Lean Management. Ähnliche Baustelle zwar, aber andere. Baustelle. Und ja, Euer Agilitätswundercoach hat Euch was anderes gesagt, ich weiß.
Klein-klein #
Kaizen und stetige Verbesserung in kleinen Schritten schön und gut. Aber ab und an braucht es einfach auch ein bisschen Kaikaku. Den großen Wurf. Und den schaffe ich nicht, wenn ich nur mehr und ausschließlich in User Stories denke. Denn das ist ansteckend. Und selbst wenn die Strategie ganz oben gut ist - es hilft mir auch die beste Strategie nichts, wenn die Visionen auf dem Weg zur Umsetzungsebene bis zur Unkenntlichkeit zerschnipselt wurden. Doch das ist es, was ich bei vielen Organisationen beobachte, die auf Agilität umstellen: es wird ein starres Regelwerk durch ein anderes starres Regelwerk ersetzt. Und dann schreiben alle kleine User Stories und irgendwann denken alle klein. Brav nach den Regeln. Bewegung werde ich damit allerdings keine erleben.
Stillstand durch Priorisierung #
Agile Methoden leben von einer dauernden Priorisierung. Nur, wenn immer ausschließlich die aktuell wichtigsten Dinge umgesetzt werden - wer kümmert sich dann um die richtigen Dinge? Die, die vielleicht zu der Situation und dem Zeitpunkt und in meiner klein-kleinen Welt nicht die wichtigsten sind, aber auf einer größeren, globaleren Skala eben schon. Die bleiben auf der Strecke. Und damit verlangsame ich meine Organisation auf Dauer gewaltig. Und irgendwann bin ich wieder dort angekommen, von wo ich losgefahren bin: Stillstand. Stillstand durch Priorisierung.
Effizienz ist nicht immer Kundenwert #
Agilität erzeugt Teams, die maximal effizient sind. Das freut die Manager und Krämerseelen. Agilität erzeugt somit aber auch Teams, die den Kundenwert komplett aus den Augen verloren haben. Und das ist auch mein Hauptkritikpunkt an der Art und Weise, wie agile Methoden oft interpretiert und gelebt werden.
Aber warum wird der Customer Value vernachlässigt? Ein Wort: Velocity. (Und Ihr wisst, von der halte ich generell nicht all zu viel.) Irgendwann haben Teams nur mehr diese eine Zahl im Kopf. Die durchschnittlich erledigten Story Points je Sprint. Das Teamtempo. Und diesem Teamtempo wird alles untergeordnet. Da wird sich auch nicht mehr auf das eigene Bauchgefühl verlassen, wie viel Arbeit ich als Team in den nächsten Wochen schaffen kann. Nein, da wird brav gerechnet. Steht ja so im Scrum Guide (da sind wir wieder bei den starren Systemen). Und dann zeichnen alle brav am Burn-Down-Chart herunter, wie viele Story Points sie heute so geschafft haben. Anstatt darüber zu reden, welcher Wert heute für den Kunden generiert wurde. Anstatt darüber zu reden, wie man heute die eigene Organisation unterstützt und weitergebracht hat. Und viele Scrum Master machen bei diesem Wahnsinn mit, ohne ihn auch nur ein einziges Mal zu hinterfragen. Steht ja so im Scrum Guide. (Und ja, ich bin gerade zynisch und unfair, tut mir leid!)
Was heißt das also alles? #
Was kann ich bei den obigen Punkten besser machen? Wie kann ich das Negative vermeiden und das Positive verstärken?
Der wichtigste Punkt zuerst. Wenn ich meine Organisation verändern möchte, sollte ich mir überlegen, ob agile Projektmanagementmethoden für den Change-Teil (also die Projekte) generell überhaupt das richtige sind. Ob ich nicht von Projekt zu Projekt schauen sollte, wo ich auf der Komplexitätsmatrix bin, um dann zu entscheiden, welchen Ansatz ich überhaupt wähle - prädiktiv, inkrementell, iterativ, wasauchimmer.
Und das zweitwichtigste: wer Organisationseinheiten agilisiert, macht in meinen Augen etwas komplett falsch. Was agilisiert gehört, sind Produkte und Services. Beziehungsweise deren Herstellung. Und da habe ich es eher weniger mit einem Regelwerk, denn mehr mit einer Philosophie, einer Geisteshaltung zu tun. Da muss ich Menschen überzeugen und nicht einfach losschicken. Aber wem erzähle ich das.
Summa summarum ist "Agilität" sicher gut und richtig. Und sie ist auch noch nicht veraltet (auch, wenn es agile Projektmanagementmethoden schon wesentlich länger gibt, als der Trend uns glauben machen möchte). Vielleicht gibt es aber im Projektmanagement wirklich kein One-size-fits-all. Und vielleicht ist es deshalb wieder einmal Zeit für etwas neues. Diesmal nichts anderes, sondern etwas besseres.
#projektphilosophie #agilität
Vielen Dank für Deine Zeit! Du kannst den Artikel gerne teilen. Und ich freue mich immer, von Euch zu lesen. Bilder von Elisabeth Pieringer und Vlad Tchompalov auf Unsplash.
← Vorheriger Artikel: Die PMP Zertifizierung erfolgreich bestehen
→ Nächster Artikel: Präsentieren, aber richtig
Veröffentlicht am