Seit ein paar Jahren ist alles Agile. Die ganze Sache ist schon längst nicht mehr der neue heiße Scheiß für alle Early Adopters sondern Mainstream wie es mainstreamiger nicht sein kann. Mittlerweile ist jedes Unternehmen agil, jedes Projekt agil und jedes Meeting agil. Wenn man fragt, was damit gemeint ist, schwanken die Antworten zwischen dürftig und unterhaltsam. Ich werde den Eindruck nicht los, dass Vieles nur agil ist, um agil zu sein.
Es ist nicht ganz einfach, bei all dem noch den Überblick zu behalten. Vor ein paar Tagen habe ich mir den Spaß gemacht, durch meine Amazon Buchvorschläge zu stöbern. Fast alle Bücher (die nicht nur Privatvergnügen sind) hatten in irgendeiner Form »agil« im Titel. Ein guter Teil davon in einem für mich nur schwer nachvollziehbaren Zusammenhang. Im Unternehmen, für das ich gerade tätig bin, liegen Angebote für Kurse in »Agiler Moderation« vor. Die Anbieter meinen damit aber jeweils Unterschiedliches. Wer sich ein wenig umsieht, kann jede Menge Beispiele für Dinge finden, die plötzlich agil geworden sind.
Mein Problem damit ist, das ein Begriff noch weiter verwässert wird, der sowieso nur dürftig definiert ist. Frage ich den großen Bruder Google nach der Definition von Agilität, bekomme ich die üblichen 50 Millionen Treffer, die sich leider nicht einig sind. Manchmal ist Agilität die Fähigkeit eines Unternehmens, flexibel auf sich ändernde Bedingungen zu reagieren, manchmal ist es die Beweglichkeit von Organisationen in Strukturen und Prozessen (und auch wenn diese Dinge ähnlich klingen und dicht beieinander liegen, sind sie dennoch nicht identisch). Manchmal wieder etwas ganz anderes. Vor diesem Hintergrund kann alles agil sein, und mit der Ausschlachtung eines Buzzwords kann man ganz wunderbar Geld verdienen.
Ich komme jetzt mal mit einem anderen Ansatz um die Ecke: Für mich ist Agilität das Prinzip eines iterativ empirischen Vorgehens – nicht mehr und nicht weniger. Kontinuierliches Lernen aus Erfahrung in stetigen kurzen zeitlichen Abständen. Das ist nichts anderes als der alte Regelkreis Plan-Do-Check-Act oder Build-Measure-Learn oder Inspect & Adapt. Ist alles das gleiche. Wenn ich dabei konsequent bin, macht mich das beweglicher, weil ich schnell Informationen bekomme und sie verarbeite.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Bei dem ganzen Scheiß, der momentan so wunderbar Agile superduper-neue-Welt ist, frage ich mich, wie weit das auf das Prinzip Plan-Do-Check-Act passt. Es wird wohl niemanden überraschen, dass Vieles, das unter dem Label »Agile« geführt wird, sich mit allen möglichen aktuellen Anforderungen und Problemen befasst, ohne auch nur das Geringste mit kontinuierlichem Lernen zu tun zu haben (auch nicht mit der Beweglichkeit einer Organisation, oder welche Definition man auch immer bemühen möchte).
Ganz wichtig: Einige dieser Bücher und Kurse, auf denen »agil« steht, in denen aber kein »agil« drin ist, sind ganz großartig. Sie haben nur nichts mit meiner Definition von Agilität zu tun. Andere Dinge sind reine Geldschneiderei, von denen ich dringend abraten würde. Und ich werde hier jetzt nicht sagen, was für mich was ist.
Worauf will ich eigentlich hinaus? Ist das hier nur ein kurzer Rant darüber, wie geldgeil und schlecht die Welt ist? Mitnichten. Mein Punkt ist: Trefft Eure Entscheidungen bewusst. Erst wenn mir klar ist, was ich unter Agilität genau verstehe (nicht die Methode, sondern das darunter liegende Prinzip), kann ich beurteilen, ob das Ganze eine Antwort auf meine Frage ist, was bedeutet, dass ich meine Frage ebenso konkret formulieren muss.
Damit komme ich wieder zu einem alten Thema, nämlich dem der Motivation. Wenn ich frage, warum im Unternehmen die Transformation zur Agilität angestrebt wird, sollte eine klare Aussage kommen, die unterschiedliche Personen in der Organisation zumindest sinngemäß gleich treffen. Ist doch ganz logisch. Wenn ich viel Zeit und Geld in eine Sache stecke (und ein Transformationsprozess ist reichlich aufwändig), dann sollte ich eine sehr klare Vorstellung davon haben, was ich damit erreichen will.
Falls Ihr gerade in einer solchen Transformation steckt, fragt doch einfach mal, warum Ihr den ganzen Kram eigentlich macht. Ich wette, Ihr werdet eine ganze Reihe unterschiedlicher Antworten bekommen, weil genau hier der erste große Fehler gemacht wird: wir schaffen keine Klarheit über unsere Motivation.
Ganz egal, wie die Entscheidung hin zu mehr Agilität oder der direkten Einführung von Scrum oder Kanban getroffen wurde, es haben nicht alle verstanden, oder es haben nicht alle das Gleiche verstanden. Das führt zu einer Organisation, die sich nicht einig ist, was sie will. Für uns ist das ein riesiges Problem, weil wir dann fast zwangsläufig in unterschiedliche Richtungen laufen. Ganz davon abgesehen wachsen damit auch die Widerstände.
Diese Sache hat aber noch ein weiteres Problem: ohne klare Zielsetzung wird Agilität zum Selbstzweck. Ob es dieses Ziel nicht gibt, oder ob es nur keiner verstanden hat, ist schnurzpiepegal. Ich werde dann Teil einer Organisation, die einer Methode folgt (wir machen jetzt Scrum, weil damit alles besser wird), um einer Methode zu folgen.
Wie zur Hölle will ich denn so irgendjemanden motivieren? Wie kann ich da die notwendige Disziplin erwarten, ohne mit der neunschwänzigen Katze zu spielen? Im Zweifel schaffen sich dann einzelne Personen eigene Motivationen, womit wir wieder dabei wären, in unterschiedliche Richtungen zu laufen. Ich schaffe nur große Reibungsverluste, und Agile bringt nichts (in welcher Form auch immer implementiert – viele denken noch immer, Scrum einzuführen, würde eine Organisation automatisch agil machen – falsch gedacht). Ohne klar formuliertes und überall gleich verstandenes Ziel schaden wir uns möglicherweise sogar, weil die Mischung aus Konfusion und Widerständen uns bremst.
Und trotzdem sehen wir diese Dinge immer wieder. Warum ist das so? Das hat mehrere mögliche Gründe:
Zum einen sind wir oft genug der Meinung, dass unsere Motivation und unsere Ziele allen klar sind. Schließlich haben wir darüber gesprochen und alle informiert. Dabei vergessen wir nur allzu gern, dass unsere Kollegen grundsätzlich nur die Dinge hören, die sie hören wollen, und dass Verstehen und Gemeinsames Verstehen zwei vollkommen unterschiedliche Dinge sind.
Zum anderen ist Agilität inzwischen die Antwort auf alles, und ich brauche nicht einmal mehr einen Grund für Agilität. Das beginnt damit, dass der Begriff »besser« immer wieder und in allen möglichen Zusammenhängen verwendet wird. Teams werden besser, Produkte werden besser, Organisationen werden besser, Kommunikation wird besser, alles wird besser. Das ist mir viel zu weich, zu wenig konkret und zu wischiwaschi. Agilität macht uns besser, aber was meine ich genau damit? Schaffen wir mehr, produzieren wir weniger Bugs, werden wir glücklicher?
Diese unkonkreten Motivationen und Ziele machen Agilität und die damit verbundenen Methoden immer zum Selbstzweck. Jetzt passieren aber ganz furchtbare Dinge: Man bemerkt einzelne positive Effekte.
Inwiefern ist das schlimm?
Wir denken, auf einem guten Weg zu sein, sind es aber nur scheinbar, dennoch fühlen wir uns bestätigt. Das führt dazu, dass ich die Frage nach Ziel und Motivation nicht mehr stelle, weil sich ja offenbar alles zum Guten wendet. Da wir eine gute Entwicklung erwarten (was auch immer wir damit meinen), und einzelne Stimmen oder Ereignisse diese Erwartung bestätigen, bemerken wir entweder die durch die Konfusion entstehenden negativen Auswirkungen nicht (weil wir sie nicht sehen wollen), oder wir tun sie leicht als Transformationsschmerz ab, weil sich all die neuen Dinge noch einrütteln müssen, und weil man sowieso ein klein wenig Zeit zur Anpassung braucht. Es hält uns oft genug davon ab, die negativen Auswirkungen ernsthaft zu betrachten.
Wenn das in einer Organisation geschieht (und es geschieht oft), ist Agilität zu einem sich selbst erhaltenden System geworden, das eingesetzt wird, um eingesetzt zu werden. Da es keinem echten Ziel dient, kostet es Kraft, am Leben erhalten zu werden. Damit erziele ich sogar einen negativen Effekt (mehr Aufwand). Eine positive Entwicklung in der Organisation (was auch immer ich damit meinen mag) ist dann immer zu einem hohen Prozentsatz zufällig und dauert auch sehr viel länger.
Der normale Weg der Dinge ist doch der, dass ich ein Problem (oder ein positives Ziel) habe, eine Lösung für dieses Problem suche, mich dann frage, ob meine mögliche Lösung mein Problem tatsächlich löst (durch Analyse oder Experiment), und ich darauf basierend schließlich eine Entscheidung treffe. Danach gehe ich in meinen iterativen Modus, um immer wieder einen Blick auf meinen Weg und meine Lösungen zu werfen – wie wir es kennen. Bin ich nachlässig in einem dieser Punkte, ist mein Ergebnis zufällig. Hinzu kommt, dass ich dann auch niemals Erfolg messen kann.
Erst wenn ich etwas finde, woran ich den Erfolg meiner Maßnahmen messen kann, bin ich konkret genug. »Besser« ist nicht messbar, weniger Bugs sind messbar. Hier kann ich etwas zählen. Ich kann einen NPS (Net Promoter Score) bemühen, ich kann Anforderungen und Tickets zählen, die ich bearbeite, ich kann Supportanfragen zählen, ich kann mir viele Dinge einfallen lassen.
Mir ist bewusst, dass die Frage nach der Messbarkeit von Agilität eine schwierige ist, und dass die Welt wenig Antworten darauf kennt. Meine Meinung ist, dass ich Agilität selbst nicht messen kann. Ich kann lediglich Auswirkungen messen, und da bin ich bei meinen Zielen.
Ich bin übrigens kein großer Fan des Nokia Sheets. Der sagt wenig darüber aus, ob wir tatsächlich agil sind, sondern sehr viel mehr, ob wir uns an die Scrum Regeln halten. Um ganz offen zu sein, ist mir das Erste wichtiger als das Zweite.
Kurz zusammengefasst: Die Zeit, die ich darauf aufwände, die Ziele für Agilität klar auszuformulieren und allen verständlich zu machen, ist keinesfalls verschenkt. Erst wenn ich Dinge messbar habe, bin ich konkret genug.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
