Als ich 2015 zum ersten Mal als Sprecherin auf internationalen Tech-Konferenzen rund um Agil und DevOps unterwegs war, hat mich diese Frage immer wieder irritiert. Sie kam mir irgendwie nicht richtig vor und erzeugte jedes Mal ein undefinierbares Gefühl der Ratlosigkeit in mir. Auch ich konnte keine passende Antwort geben. Gleichzeitig schien diese Frage aber von Bedeutung zu sein, da sie immer wieder gestellt wurde. Und Heerscharen von renommierten Sprecher*innen bemühten sich, nachvollziehbare Antworten zu liefern. Dabei kristallisierten sich drei Meinungslager heraus:
Das Lager „Bottom-up“
Die Verfechter des Bottom-up Ansatzes sagen vollkommen zu Recht, dass die Entwicklung hin zu Agil und Devops von der Basis aus kommen muss. Dort wird die Arbeit gemacht und eines der wichtigen Prinzipien sowohl in der agilen als auch der DevOps-Welt sind selbstorganisierende Teams, die ihre eigenen Entscheidungen in Bezug auf die Arbeit treffen. In DevOps geht es sogar so weit, dass ganz klar gesagt wird, dass Entscheidungen dort getroffen werden müssen, wo die Arbeit gemacht wird. So ist bereits in den Prinzipien des Agilen Manifest verankert, dass Projekte rund um motivierte Individuen aufgebaut werden sollen. Und was ist motivierender als sich seine Arbeitsumwelt so zu schaffen, wie sie für uns motivierend ist, um so den Magic Stuff zu kreieren und uns zu einem High Performing Team zu entwickeln? Außerdem ist es einfacher, Veränderungen umzusetzen, für die wir uns selbst entschieden haben, als die Veränderungen, die uns von außen bzw. von oben auferlegt werden. Diese Gründe sind allesamt richtig und gut nachvollziehbar. Und doch machen sie mich nicht zufrieden.
Das Lager Top-down
Die Fürsprecher des Top-down Ansatzes sagen ganz klar, dass eine Grassroot-Bewegung im Unternehmen nicht erfolgreich sein kann. Schließlich ist ein Unternehmen ein großes Konstrukt, dass von einzelnen an der Basis nicht in Gänze überblickt werden kann. Und sobald die Unterstützung durch das Management nicht da ist, fehlt es an Ressourcen zur Erreichung der Ziele. Daher müssen solche Transformationen Top-down umgesetzt werden. Nur dann kann das Verständnis dafür im ganzen Unternehmen erzeugt werden, die Voraussetzungen geschaffen und die nötigen Ressourcen bereitgestellt werden. Absolut richtig! Der Weg hin zu Agil und DevOps erfordert Ressourcen wie Zeit und Geld und bedarf auch etlicher struktureller und organisatorischer Veränderungen. Und ja, als Führungskraft und Manager sollen wir ja auch die Arbeitsumgebung schaffen, in der Teams selbstorganisiert arbeiten und ihre intrinsische Motivation ausleben können! Doch irgendwie gefiel mir auch dieses Bild nicht, dass eine einzelne Person und eine ganz kleine Gruppe, weit weg von den einzelnen Arbeiten im Unternehmen – schließlich haben sie andere Aufgaben –, darüber entscheidet, wie die Mitarbeiter*innen zukünftig am besten arbeiten. Die Frage, die regelmäßig in mir aufkam, war, ob sie das überhaupt beurteilen können bzw. welchen Aufwand es bedarf, damit sie es überhaupt vernünftig beurteilen könnten. Denn eine Veränderung hin zu Agil und DevOps einfach nur, weil es derzeit ein großer Hype ist, sollte nicht oder zumindest nicht die einzige Motivation sein.
Das Lager „Es kommt darauf an!“
Das dritte Lager kommt zu keiner eindeutigen Aussage, sondern nutzt eine in der agilen und DevOps Welt absolut gerechtfertigte Aussage: Es kommt darauf an! Es kommt auf das Unternehmen, die Teams, die Führungskräfte, die Individuen, die Kultur, den Reifegrad, das Business Modell und vieles mehr an. Dave Snowden hat in seinem Cynefin-Framework herausgearbeitet, dass Agilität und Devops die besten Lösungen für komplexe Umgebungen und Problemstellungen liefern. Und immer, wenn wir es mit komplexen Umgebungen zu tun haben, gibt es laut Snowden weder Best Practices noch Good Practices. Dort müssen wir unsere eigenen Lösungsansätze kreieren – und das gilt nicht nur für die zu entwickelnden Problemlösungen, sondern auch für die Art und Weise, wie wir diese Lösungen entwickeln. Denn auch Unternehmen, Teams und Kollaboration sind komplexe Umgebungen und Aufgaben. Daher kann es also sein, dass in einem Unternehmen eine Grassroot-Bewegung erfolgreich ist, in einem anderen aber scheitert. Ebenso verhält es sich mit dem Top-down Ansatz. Ich selbst benutze die Aussage „Es kommt darauf an“ sehr häufig, wenn Kunden wissen wollen, wie sie vorgehen sollen. Daher war diese Antwort auf die Frage für mich bislang zwar die eingängigste, aber auch sie stellte mich nicht zufrieden. Das Gefühl lässt sich am besten mit Inkongruenz gepaart mit einer kognitiven Dissonanz beschreiben. Das eine, was man sagt, das andere, was man eigentlich meint. Und das ergibt sich aus dem, was alles an Wissen vorhanden ist, aber noch nicht den richtigen Match ergibt.
So landete ich schließlich an dem Punkt, an dem ich mir folgende Frage stellte: Wenn also alle drei Antworten auf die Frage zwar plausibel und nachvollziehbar sind, aber gleichzeitig sich nicht richtig anfühlen, liegt das vielleicht gar nicht an den Antworten, sondern an der Frage selbst! Mir wurde klar, dass das genau der Punkt war: Die Frage selbst stellt das Problem für mich dar. Als ich mich 2015 ersten Mal auf dem öffentlichen Parkett von Agilität und DevOps bewegte, hielt ich meinen Unmut über diese Frage für mein persönliches Einstiegsproblem mangels Erfahrung und Wissen. Doch je länger ich mich professionell in diesem Umfeld bewege und mein Wissen und meine Erfahrungen erweitere, desto weniger kann ich mich mit der Frage anfreunden. Die Gründe dafür sind für mich so gravierend, dass die Frage „Top-down oder Bottom-up“ für mich provokant gesprochen zu einem Zeichen von „Setzen, noch nicht verstanden“ geworden ist. Und ja, wer sich bislang mit agil und DevOps noch nicht intensiv auseinandergesetzt hat, dem fehlen höchstwahrscheinlich die wichtigen Wissensbausteine. (ANMERKUNG: ich erwarte nicht, dass sich jeder mit Agilität und DevOps bereits beschäftigt hat oder sich beschäftigen muss!)
Ein wichtiges Ziel in Agil und DevOps: der Abbau von Silos!
Wer sich mit Agil und DevOps beschäftigt, der weiß, dass der Abbau von Silos eine wichtige Rolle spielt. Wir wollen interdisziplinär und abteilungsübergreifend arbeiten, um gemeinsam übergeordnete Ziele zu erreichen. Silos per se beinhalten, dass sie sich abschotten und die Silo-Ziele erreichen wollen. Diese sind aber zum Teil nicht vereinbar mit den übergeordneten Zielen. Doch impliziert die Frage „Top-down oder Bottom-up“ nicht schon zwei Silos, nämlich „oben“ und „unten“? Je nach Perspektive des Fragenden ist es dann „die da oben“ und „wir hier unten“ oder „wir hier oben“ und „die da unten“!
Silos und das Blame Game
Wenn starke Silos vorhanden sind, findet häufig zwar eine Identifikation der Mitarbeiter*innen mit dem Silo statt aber nicht mit dem übergeordneten Ziel, dass von verschiedenen Silos gemeinsam erreicht werden muss. Dieses Verhalten ist in verschiedenen wissenschaftlichen Experimenten erforscht worden. Doch diese starke Identifikation mit dem eigenen Silo führt auch dazu, Blame – also die Schuld, wenn etwas schiefgeht – auf die anderen Silos zu schieben. Die bieten sich in diesem Konstrukt geradezu dafür an, per se schuldig zu sein. Doch sowohl im Agilen als auch in DevOps wissen wir, dass das Blame Game uns nicht weiterbringt. Wir müssen über Fehler und Probleme offen sprechen können, um gemeinsam daraus zu lernen und uns kontinuierlich weiterzuentwickeln. Auf mich wirkt die Frage „Top-down oder Bottom-up“ wie eine vorab schon einmal entwickelte Exit-Strategie für den Fall, dass der Change nicht so gut funktioniert. Wer ist schuld? Klar, die anderen – entweder die da oben (bei der Grassroot-Bewegung) oder die da unten (bei dem Top-down Ansatz).
Agil, DevOps und starre Hierarchien
In Agil und DevOps wollen wir nicht nur abteilungsübergreifend und interdisziplinär arbeiten, sondern auch über die Hierarchien hinweg. Das Management trifft keine einsamen Entscheidungen mehr. Mitarbeiter*innen geben Informationen und Feedback auch „nach oben“. Es herrscht Vertrauen und Miteinander. Meine persönliche Meinung dabei ist, dass es nicht zwangsläufig darauf ankommt, ob Hierarchien vorhanden sind, sondern vielmehr wie sie gelebt und (aus)genutzt werden. Doch eine Frage nach „Top-down oder Bottom-up“ verbalisiert für mein Empfinden die Kluft, die sich zwischen „oben“ und „unten“ auftut, sehr deutlich. Sie zeigt das vorherrschende Denken und das vorhandene Mindset auf. Statt Vertrauen auszudrücken, ist sie für mich ein Zeichen von Misstrauen und „Kastendenken“ – und damit eine denkbar schlechte Voraussetzung für eine erfolgreiche Transformation.
Und was ist mit denen in der Mitte?
Für mich ist die Welt auch nicht nur schwarz und weiß. Wer gehört eigentlich zu Top und wo hört es auf. Geht es gleich in Bottom über oder haben wir noch eine Mitte – sozusagen die 50 Shades of Gray? Und wenn es die „Mitte“ gibt, können die dann gar nichts bewegen?
Selbstverständlich gibt es viele Unternehmen, für die die von mir aufgeworfenen Fragen den tatsächlichen Arbeitsalltag charakterisieren. Doch wenn das so ist, bin ich fest davon überzeugt, dass diese Unternehmen erst noch viele kleine Schritte gehen müssen, bevor sie sich erfolgreich mit der Umsetzung der „großen“ agilen Methoden wie Scrum oder Kanban oder sogar mit DevOps beschäftigen können. Zunächst muss da kultureller Boden geschaffen werden, um notwendige Voraussetzungen wie Vertrauen und psychologische Sicherheit zu schaffen. Doch gerade diese vielen kleinen Schritte – der Weg – sind schon ein wichtiges Ergebnis: der Beginn, sich selbst als Unternehmen immer wieder infrage zu stellen, sich um kontinuierliche Verbesserung zu bemühen. Sie stellen den Beginn des agilen Vorgehens dar.
Wie ein Schmetterling!
Und wenn wir die Transformation hin zu Agil und DevOps als genau diesen Weg der vielen kleinen Schritte sehen, wird schnell deutlich: Jeder kann anfangen – bei der eigenen Arbeit, dem eigenen Verhalten und dem eigenen Denken! Und jede kleine Veränderung bei sich selbst wird Auswirkungen haben auf andere in ihrer Wahrnehmung, ihrem Verhalten, ihrem Denken. Dieser Ansatz wird auch als der Butterfly-Effekt bezeichnet. Hierbei kommt es nicht darauf an, in welcher Hierarchieebene sich die einzelne Person befindet oder welche Rolle oder Position sie innehat. Vielmehr geht dieser Ansatz davon aus, dass jeder in einem Unternehmen Einfluss und Macht hat und dies entsprechend (positiv) nutzen kann. Wir müssen uns dessen nur bewusst sein und die Verantwortung dafür übernehmen, etwas ändern zu wollen. Hierbei kommt auch der Responsibility Process von Christopher Avery wieder ins Spiel: nur in der „Opferrolle“ zu verharren und darauf warten, dass andere etwas ändern, wird das Problem nicht lösen. Nur wer aktiv Verantwortung dafür übernimmt und aktiv wird, trägt zur Lösung bei.
Was kann ich dazu beitragen?
Wenn wir also in dieser Transformation hin zu Agil und DevOps vom Weg der vielen kleinen Schritte ausgehen, sollte meines Erachtens die Frage lauten: Was kann ich dazu beitragen, dass wir uns in diese Richtung bewegen? Die Antworten hierauf können sehr vielfältig sein und hängen stark von Person und Umgebung ab. Es können Gespräche geführt, die eigene Arbeitsweise auf den Prüfstand gestellt oder das eigene Handeln reflektiert werden, um herauszufinden, was denn die eigene Rolle innerhalb eines Prozesses ist. Jeder kann aber auch schauen, wie das eigene Handeln und das eigene Verhalten unter Umständen genau das unterstützen, was eigentlich abgeschafft werden soll. Wir können überprüfen, wie es zum Beispiel um unser eigenes Vertrauen steht – in Bezug auf uns selbst, auf unser Team und auf unsere Vorgesetzten. Wer allerdings auf die Frage „was kann ich dazu beitragen“ nur mit einem ernsthaften „Nichts“ antworten kann, sollte sich eine andere die Frage stellen: Was ist eigentlich meine Bedeutung für dieses Unternehmen?
Veränderung von innen heraus
Mit gutem Beispiel voranzugehen, ist ein hilfreicher Ansatz, der andere motivieren wird, zu folgen. Multiplikatoren entstehen und helfen dabei, die Veränderungen voranzubringen. Und ja, das alles bedeutet, dass wir Mut brauchen und Ausdauer haben müssen! Kleine Schritte, sanfter Flügelschlag, steter Tropfen! Und an einem bestimmten Punkt, wenn schon ein paar Multiplikatoren mit dabei sind, kommt eine andere wichtige Frage ins Spiel: Was können WIR gemeinsam tun, um Agilität und DevOps zu etablieren und weiterzuentwickeln? Wenn wir dort angekommen sind und die Fragen nach dem „Wir“ stellen, haben wir die richtige Ausgangsposition für Agil und DevOps geschaffen: denn bei beiden geht es um das „Wir“, das Team und die gemeinsamen Ziele!
Fazit: Sei mutig, übernimm Verantwortung, gehe deine ersten kleinen Schritte! Sei der Schmetterling, der stete Tropfen und das gute Beispiel! Wenn du auf diesem Weg einen neutralen Gesprächspartner oder eine andere Sichtweise brauchst, kann dir Coaching oder Sparring helfen. Probiere es einfach einmal aus – online oder persönlich!
