👋 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!
Eine Definition von Agilität - der Versuch, einer Kartographierung.
Schlechte Angewohnheiten #
Ich (ja ich weiß, man soll seine Sätze nicht mit „ich“ beginnen – ich mache es trotzdem) bin im Lauf der Jahre schon in vielen Seminaren, Vorträgen, Reden zum Thema Agilität gesessen. So wie Ihr alle hier. Und diese Seminare, Vorträge, Reden haben so gut wie alle eine Sache gemeinsam (neben dem Thema natürlich): die Vortragenden beginnen mit einem Beispiel, das verdeutlichen soll, wie schlecht Wasserfall denn nicht sei. Furchtbare Dinge passieren, wenn man dieses Wasserfall macht. Und nach dem Todeschaoswasserfallprojekt erklären sie uns dann, dass das alles mit Agilität nicht passiert wäre. Weil Feenstaub.
Aber was bedeutet denn Agilität? Und was bedeutet Wasserfall? Und worum geht es überhaupt und generell? Diese Fragen bekommen wir selten bis gar nicht beantwortet. Schade eigentlich. Denn diese Metathemen, dieses Big Picture, dieser Überblick ist recht spannend. Deshalb wollen wir uns das mal näher ansehen.
Die grundlegende Unterscheidung (die eigentlich gar keine ist) #
Wenn wir, von unserem Projekt- bzw. Programmmanagement ausgehend, einen großen Schritt zurück machen, dann stehen wir a) eine Stufe unterhalb der Business administration und b) sehen wir zwei große Ströme: Veränderung und Operations. Change und Run. Projekte und Prozesse. Projektmanagement und Prozessmanagement. Ich weiß, ich erzähle hier nichts Neues. Aber diese Unterscheidung müssen wir stets beachten, wenn wir über eine Definition von Agilität reden. Denn genau diese Differenzierung wird ganz gerne weggelassen, wenn es so richtig in media res geht.
Im echten Leben ist die Unterscheidung mittlerweile sehr schwer geworden. Beziehungsweise war sie das immer schon, wenn man es ganz genau betrachtet - Projektmanagement ist eine Unterkategorie des Prozessmanagement. Ein Versuch, den Ablauf, die Unklarheit von Projekten mittels Prozessen abzubilden. Und in den letzten Jahren konnte selbst die statischste Organisation beobachten, dass die Abgrenzung zwischen Change und Run immer mehr verschwimmt.
Früher war das einfach. Da gab es das Tagesgeschäft. Und alle paar Jahre kam ein großes Projekt ums Eck, das die Organisation ordentlich umgestellt hat. Und dann kam wieder eine lange Phase voll ruhigen Tagesgeschäfts. In unserer heutigen Zeit, wo uns die Veränderung konstant um die Ohren klatscht, gibt es diese Organisationen nicht mehr. Entweder, sie haben sich umgestellt, oder sie wurden abgestellt.
Ein Schritt zurück zurück #
Machen wir nun einen Schritt zurück zurück. Wieder in unser Projektmanagement. Und ich werde hier jetzt sehr oberlehrerhaft werden. Im Projektmanagement gibt es in allen Metaframeworks irgendwo und irgendwie die Unterscheidung zwischen dem Projektplan und dem Project Life Cycle. Zwischen Plan und Ablauf. Und bei Letzterem gibt es vier große Ansätze, wie ich meine Projekte abwickeln kann.
- Prediktiv
Auch gerne klassisches Projektmanagement genannt. Die Projektmanagerin / der Projektmanager / das Projektteam plant das Projekt (Scope, Cost, Time) von Anfang bis Ende durch und an diesen Plan halten sich dann alle, an der Umsetzung beteiligten Personen. Das ist natürlich ideal für große Projekte mit wenig fachlichen und technischen Unklarheiten.
Der prediktive Ansatz ist übrigens das, was Scrum-Coaches gerne verächtlich als Wasserfall bezeichnen. - Iterativ
Schrittweise wiederholend. Ich plane nicht den großen Wurf auf einmal komplett durch, sondern immer nur die kommenden Schritte anhand einer Projektvision. Im englischen gibt es dafür den wundervollen Ausdruck Rolling-wave planning. Hier wird gerne und oft der Scope genauer geplant und dann nach jedem Durchlauf gemeinsam mit Cost- und Time-Baselines angepasst. Quasi ein Wasserfall in Schleifen und mit viel Kundenfeedback. - Inkrementell
Der inkrementelle Ansatz ist dem iterativen recht ähnlich. Ich schaue, dass ich schnell einen Prototypen erstelle und den dann schrittweise und mit viel Kundenfeedback verbessere. - Adaptiv
Auch als change-driven bekannt. Im Grunde habe ich, wie beim prediktiven Ansatz, mein Projekt in Phasen unterteilt. Nur arbeite ich nicht mit einem vorher fixierten Scope, sondern mit einer Projektvision, der ich mich schrittweise annähere. Das bringt zwar viel Overhead mit sich (konstantes Planen), garantiert mir dafür aber auch eine hohe Flexibilität. Deshalb ist die adaptive Vorgehensweise perfekt für Projekte mit hoher fachlicher und / oder technischer Unklarheit geeignet, wie wir sie vor allem in der IT finden.
Und wenn jemand von "agil" redet, ist meißt genau das hier gemeint - ein adaptiver Project Life Cycle.
Warum nur eines, wenn ich alles haben kann? #
In den letzten 20 Jahren habe Organisationen mehr und mehr festgestellt, dass der Druck zunimmt. Ja, die eierlegende Wollmilchsau, die gibt es nicht, das war immer schon allen klar. Gut, fast allen. Aber Firmen, die ihre Projekte prediktiv abwickelten, haben damit alle Fälle und Eventualitäten im Projektgeschäft recht gut abdecken können. Mal mehr, mal weniger einfach. Und adaptiven Projektorganisationen ging es genauso. Nur funktioniert das mittlerweile oft einfach nicht mehr. Das spüren vor allem Organisationen, die in einem umkämpften und dynamischen Umfeld tätig sind.
Und genau hier hat sich eine Einsicht durchgesetzt: warum soll ich mich auf ein Modell, auf eine Vorgehensweise fixieren? Im Normalfall ist Projektmanagement keine monotheistische Religion. Auch wenn es oft so gehandhabt wird. Aber wenn ich ein handwerklich gutes PMO habe, kann es mir als Organisation eigentlich egal sein, ob meine Projekte prediktiv, iterativ, inkrementell, oder adaptiv umgesetzt werden. Denn eigentlich ist es wichtiger, dass ein Projekt sauber und effektiv und effizient abgewickelt wird. Und diese Erkenntniss war die Geburtsstunde des hybriden Projektmanagements: ich wähle situationselastisch die Methodik aus, die zu meinem aktuellen Projekt am besten passt.
And now for something completely different #
Lasst uns einen Blick auf die große Schwester der Projekte werfen: Prozesse. Hier wird die Sache im Grunde wesentlich einfacher. Zumindest für uns Projektarbeiter und zumindest, was den theoretischen Teil angeht. Ich breche das jetzt radikal herunter: im Prinzip gibt es zwei Möglichkeiten, meine Prozesse handzuhaben. Ich kann sie kartographieren, dokumentieren und jede und jeder hat sich genau an diese Dokumentation zu halten. Wir alle kennen die Bilder aus den 1950er-Jahren von Wissenschaftlern in weißen Kitteln, die mit Stoppuhr und Klemmbrett in den Händen an den Fließbändern stehen und fleißig Prozesse erfassen und kontrollieren. Die Wissenschaftler gibt es nicht mehr, aber Prozessmanagement wird nach wie vor oft so gehandhabt.
Kommen neue Tätigkeiten hinzu (zum Beispiel als Resultat eines Projektes), wird ein neuer Workflow, ein neuer Prozess geplant und überlegt. Hierbei sind natürlich alle Beteiligten dabei. Die Entscheidung liegt aber eindeutig bei der Führungskraft.
Die zweite große Herangehensweise (und ich weiß, das ist eine sehr grobe Betrachtungsweise, und da gibt es noch viel mehr, und da kommen noch Qualitätsmanagement und PM dazu; aber dann wäre das hier kein Blogbeitrag, sondern ein dickes, dickes Buch) ist, die Entscheidungsverantwortung von oben nach unten zu verlagern. Von der Chefetage zum Gemba - dem Ort, wo die Arbeit passiert. Denn die dort wissen am besten, wie die Arbeit ideal umgesetzt wird. Im Grunde genommen ist das das, was bei uns Continual improvement process heißt, früher mal Continuous improvement hieß und im asiatischen Raum unter Lean Management zusammengefasst wird. Wobei Letzteres - ähnlich wie agil - eine wahre Müllkippe an Buzzwords ist. Aber zurück zu Lean. Hauptgedanke ist es, Werte ohne Verschwendung zu erschaffen. Und damit sind wir bei Kaizen angelangt. Und wenn mir die kleine Spitze erlaubt ist: das ist das, was viele Coaches meinen, wenn sie von Kanban reden. Aber da sind wir wieder auf dem nächsten Buzzwordfriedhof.
Von Missverständnissen #
Kaizen kann einem im Grunde so richtig leid tun. Denn so wirklich verstanden wird es hier nur selten. Und damit will ich nicht behaupten, dass ich es verstehen würde. Aber ich beobachte, dass es in unseren Breitengraden oft komplett verbogen wird. Beweis gefällig? Wir nennen unsere Variante davon Continual improvement process. Process. Dabei ist es viel mehr eine Geisteshaltung, eine Philosophie, eine Grundeinstellung. Aber in jedem von uns steckt ein kleiner Teutone und darum lieben wir es wohl, alles in Schubladen zu stopfen. Kaizen, bzw. CIP wird bei uns sehr qualitätsorientiert gelebt. Das ist es auch, sieht sich aber mehr als gesamtheitlichen Ansatz. Eine "ewige Veränderung". Vor allem sichtbare Veränderung. Ein Versuch, auf die Veränderungen um uns herum nicht nur zu reagieren, auch nicht, sie zu antizipieren, sondern selbst ein Teil dieser Veränderungen zu sein. Zugegeben, das erinnert sehr an die Sätze der alten Senseis in den Karatefilmen der 1980er-Jahre. Und das lässt sich natürlich nur sehr schwer in den einen idealen, perfekten, magischen Prozess pressen. Und damit schließt sich der Kreis.
Also #
Was ist sie nun, die Agilität? Was bedeutet es, agil zu sein? Und damit meine ich nicht, agil im Sinne der Betriebswirtschaftslehre, oder agil als Sammelbegriff für einige Projektmanagementframeworks, sondern generell und überhaupt. Agil zu sein bedeutet für mich a) situationselastisch zu leben und b) Kaizen zu leben. Ständige Veränderung. Die Grundeinstellung, dass nichts, aber auch gar nichts in meiner Arbeitswelt perfekt ist. Und der Antrieb, die Dinge um mich herum konstant verbessern zu wollen. Small steps, right direction, wie sie in den USA so schön sagen. Kleine Schritte auf eine große Vision zu. Und da ist es vollkommen egal, welche Methoden, welche Methodiken, welche Prozesse ich da verwende. Ob das jetzt Scrum ist (das übrigens in meinen Augen eher wenig mit Agilität zu tun hat), ob das jetzt Kanban ist, ob das ATDD ist, ob das Wasserfall ist, ob das das gute alte V-Model ist. Hauptsache, ich kann damit meine Arbeitswelt ein Stück weit besser machen.
#methodik #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 Ferenc Horvath auf Unsplash.
← Vorheriger Artikel: Kompetenzmatrix - der wertvolle Helfer in meiner Teamplanung
→ Nächster Artikel: Wasauchimmer - was wir aus Zufällen lernen können
Veröffentlicht am