Hin zu agil und DevOps: Warum „Top down oder Bottom up“ die falsche Frage ist!

Als ich 2015 zum ersten Mal als Sprecherin auf inter­na­tionalen Tech-Kon­feren­zen rund um Agil und DevOps unter­wegs war, hat mich diese Frage immer wieder irri­tiert. Sie kam mir irgend­wie nicht richtig vor und erzeugte jedes Mal ein undefinier­bares Gefühl der Rat­losigkeit in mir. Auch ich kon­nte keine passende Antwort geben. Gle­ichzeit­ig schien diese Frage aber von Bedeu­tung zu sein, da sie immer wieder gestellt wurde. Und Heer­scharen von renom­mierten Sprecher*innen bemüht­en sich, nachvol­lziehbare Antworten zu liefern. Dabei kristallisierten sich drei Mei­n­ungslager heraus:

Das Lager „Bottom-up“

Die Ver­fechter des Bot­tom-up Ansatzes sagen vol­lkom­men zu Recht, dass die Entwick­lung hin zu Agil und Devops von der Basis aus kom­men muss. Dort wird die Arbeit gemacht und eines der wichti­gen Prinzip­i­en sowohl in der agilen als auch der DevOps-Welt sind selb­stor­gan­isierende Teams, die ihre eige­nen Entschei­dun­gen in Bezug auf die Arbeit tre­f­fen. In DevOps geht es sog­ar so weit, dass ganz klar gesagt wird, dass Entschei­dun­gen dort getrof­fen wer­den müssen, wo die Arbeit gemacht wird. So ist bere­its in den Prinzip­i­en des Agilen Man­i­fest ver­ankert, dass Pro­jek­te rund um motivierte Indi­viduen aufge­baut wer­den sollen. Und was ist motivieren­der als sich seine Arbeit­sumwelt so zu schaf­fen, wie sie für uns motivierend ist, um so den Mag­ic Stuff zu kreieren und uns zu einem High Per­form­ing Team zu entwick­eln? Außer­dem ist es ein­fach­er, Verän­derun­gen umzuset­zen, für die wir uns selb­st entsch­ieden haben, als die Verän­derun­gen, die uns von außen bzw. von oben aufer­legt wer­den. Diese Gründe sind alle­samt richtig und gut nachvol­lziehbar. Und doch machen sie mich nicht zufrieden.

Das Lager Top-down

Die Für­sprech­er des Top-down Ansatzes sagen ganz klar, dass eine Grass­root-Bewe­gung im Unternehmen nicht erfol­gre­ich sein kann. Schließlich ist ein Unternehmen ein großes Kon­strukt, dass von einzel­nen an der Basis nicht in Gänze überblickt wer­den kann. Und sobald die Unter­stützung durch das Man­age­ment nicht da ist, fehlt es an Ressourcen zur Erre­ichung der Ziele. Daher müssen solche Trans­for­ma­tio­nen Top-down umge­set­zt wer­den. Nur dann kann das Ver­ständ­nis dafür im ganzen Unternehmen erzeugt wer­den, die Voraus­set­zun­gen geschaf­fen und die nöti­gen Ressourcen bere­it­gestellt wer­den. Abso­lut richtig! Der Weg hin zu Agil und DevOps erfordert Ressourcen wie Zeit und Geld und bedarf auch etlich­er struk­tureller und organ­isatorisch­er Verän­derun­gen. Und ja, als Führungskraft und Man­ag­er sollen wir ja auch die Arbeit­sumge­bung schaf­fen, in der Teams selb­stor­gan­isiert arbeit­en und ihre intrin­sis­che Moti­va­tion ausleben kön­nen! Doch irgend­wie gefiel mir auch dieses Bild nicht, dass eine einzelne Per­son und eine ganz kleine Gruppe, weit weg von den einzel­nen Arbeit­en im Unternehmen – schließlich haben sie andere Auf­gaben –, darüber entschei­det, wie die Mitarbeiter*innen zukün­ftig am besten arbeit­en. Die Frage, die regelmäßig in mir aufkam, war, ob sie das über­haupt beurteilen kön­nen bzw. welchen Aufwand es bedarf, damit sie es über­haupt vernün­ftig beurteilen kön­nten. Denn eine Verän­derung hin zu Agil und DevOps ein­fach nur, weil es derzeit ein großer Hype ist, sollte nicht — oder zumin­d­est nicht die einzige Moti­va­tion sein.

Das Lager „Es kommt darauf an!“

Das dritte Lager kommt zu kein­er ein­deuti­gen Aus­sage, son­dern nutzt eine in der agilen und DevOps Welt abso­lut gerecht­fer­tigte Aus­sage: Es kommt darauf an! Es kommt auf das Unternehmen, die Teams, die Führungskräfte, die Indi­viduen, die Kul­tur, den Reife­grad, das Busi­ness Mod­ell und vieles mehr an. Dave Snow­den hat in seinem Cynefin-Frame­work her­aus­gear­beit­et, dass Agilität und Devops die besten Lösun­gen für kom­plexe Umge­bun­gen und Prob­lem­stel­lun­gen liefern. Und immer, wenn wir es mit kom­plex­en Umge­bun­gen zu tun haben, gibt es laut Snow­den wed­er Best Prac­tices noch Good Prac­tices. Dort müssen wir unsere eige­nen Lösungsan­sätze kreieren – und das gilt nicht nur für die zu entwick­el­nden Prob­lem­lö­sun­gen, son­dern auch für die Art und Weise, wie wir diese Lösun­gen entwick­eln. Denn auch Unternehmen, Teams und Kol­lab­o­ra­tion sind kom­plexe Umge­bun­gen und Auf­gaben. Daher kann es also sein, dass in einem Unternehmen eine Grass­root-Bewe­gung erfol­gre­ich ist, in einem anderen aber scheit­ert. Eben­so ver­hält es sich mit dem Top-down Ansatz. Ich selb­st benutze die Aus­sage „Es kommt darauf an“ sehr häu­fig, wenn Kun­den wis­sen wollen, wie sie vorge­hen sollen. Daher war diese Antwort auf die Frage für mich bis­lang zwar die eingängig­ste, aber auch sie stellte mich nicht zufrieden. Das Gefühl lässt sich am besten mit Inkon­gruenz gepaart mit ein­er kog­ni­tiv­en Dis­so­nanz beschreiben. Das eine, was man sagt, das andere, was man eigentlich meint. Und das ergibt sich aus dem, was alles an Wis­sen vorhan­den ist, aber noch nicht den richti­gen Match ergibt.

So lan­dete ich schließlich an dem Punkt, an dem ich mir fol­gende Frage stellte: Wenn also alle drei Antworten auf die Frage zwar plau­si­bel und nachvol­lziehbar sind, aber gle­ichzeit­ig sich nicht richtig anfühlen, liegt das vielle­icht gar nicht an den Antworten, son­dern an der Frage selb­st! Mir wurde klar, dass das genau der Punkt war: Die Frage selb­st stellt das Prob­lem für mich dar. Als ich mich 2015 ersten Mal auf dem öffentlichen Par­kett von Agilität und DevOps bewegte, hielt ich meinen Unmut über diese Frage für mein per­sön­lich­es Ein­stiegsprob­lem man­gels Erfahrung und Wis­sen. Doch je länger ich mich pro­fes­sionell in diesem Umfeld bewege und mein Wis­sen und meine Erfahrun­gen erweit­ere, desto weniger kann ich mich mit der Frage anfre­un­den. Die Gründe dafür sind für mich so gravierend, dass die Frage „Top-down oder Bot­tom-up“ für mich — pro­vokant gesprochen — zu einem Zeichen von „Set­zen, noch nicht ver­standen“ gewor­den ist. Und ja, wer sich bis­lang mit agil und DevOps noch nicht inten­siv auseinan­derge­set­zt hat, dem fehlen höchst­wahrschein­lich die wichti­gen Wis­sens­bausteine. (ANMERKUNG: ich erwarte nicht, dass sich jed­er mit Agilität und DevOps bere­its beschäftigt hat oder sich beschäfti­gen 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 inter­diszi­plinär und abteilungsüber­greifend arbeit­en, um gemein­sam über­ge­ord­nete Ziele zu erre­ichen. Silos per se bein­hal­ten, dass sie sich abschot­ten und die Silo-Ziele erre­ichen wollen. Diese sind aber zum Teil nicht vere­in­bar mit den über­ge­ord­neten Zie­len. Doch impliziert die Frage „Top-down oder Bot­tom-up“ nicht schon zwei Silos, näm­lich „oben“ und „unten“? Je nach Per­spek­tive des Fra­gen­den 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 vorhan­den sind, find­et häu­fig zwar eine Iden­ti­fika­tion der Mitarbeiter*innen mit dem Silo statt aber nicht mit dem über­ge­ord­neten Ziel, dass von ver­schiede­nen Silos gemein­sam erre­icht wer­den muss. Dieses Ver­hal­ten ist in ver­schiede­nen wis­senschaftlichen Exper­i­menten erforscht wor­den. Doch diese starke Iden­ti­fika­tion mit dem eige­nen Silo führt auch dazu, Blame – also die Schuld, wenn etwas schiefge­ht – auf die anderen Silos zu schieben. Die bieten sich in diesem Kon­strukt ger­adezu dafür an, per se schuldig zu sein. Doch sowohl im Agilen als auch in DevOps wis­sen wir, dass das Blame Game uns nicht weit­er­bringt. Wir müssen über Fehler und Prob­leme offen sprechen kön­nen, um gemein­sam daraus zu ler­nen und uns kon­tinuier­lich weit­erzuen­twick­eln. Auf mich wirkt die Frage „Top-down oder Bot­tom-up“ wie eine vor­ab schon ein­mal entwick­elte Exit-Strate­gie für den Fall, dass der Change nicht so gut funk­tion­iert. Wer ist schuld? Klar, die anderen – entwed­er die da oben (bei der Grass­root-Bewe­gung) oder die da unten (bei dem Top-down Ansatz).

Agil, DevOps und starre Hierarchien

In Agil und DevOps wollen wir nicht nur abteilungsüber­greifend und inter­diszi­plinär arbeit­en, son­dern auch über die Hier­ar­chien hin­weg. Das Man­age­ment trifft keine ein­samen Entschei­dun­gen mehr. Mitarbeiter*innen geben Infor­ma­tio­nen und Feed­back auch „nach oben“. Es herrscht Ver­trauen und Miteinan­der. Meine per­sön­liche Mei­n­ung dabei ist, dass es nicht zwangsläu­fig darauf ankommt, ob Hier­ar­chien vorhan­den sind, son­dern vielmehr wie sie gelebt und (aus)genutzt wer­den. Doch eine Frage nach „Top-down oder Bot­tom-up“ ver­bal­isiert für mein Empfind­en die Kluft, die sich zwis­chen „oben“ und „unten“ auf­tut, sehr deut­lich. Sie zeigt das vorherrschende Denken und das vorhan­dene Mind­set auf. Statt Ver­trauen auszu­drück­en, ist sie für mich ein Zeichen von Mis­strauen und „Kas­ten­denken“ – und damit eine denkbar schlechte Voraus­set­zung für eine erfol­gre­iche 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 gle­ich in Bot­tom über oder haben wir noch eine Mitte – sozusagen die 50 Shades of Gray? Und wenn es die „Mitte“ gibt, kön­nen die dann gar nichts bewegen?

Selb­stver­ständlich gibt es viele Unternehmen, für die die von mir aufge­wor­fe­nen Fra­gen den tat­säch­lichen Arbeit­sall­t­ag charak­ter­isieren. Doch wenn das so ist, bin ich fest davon überzeugt, dass diese Unternehmen erst noch viele kleine Schritte gehen müssen, bevor sie sich erfol­gre­ich mit der Umset­zung der „großen“ agilen Meth­o­d­en wie Scrum oder Kan­ban oder sog­ar mit DevOps beschäfti­gen kön­nen. Zunächst muss da kul­tureller Boden geschaf­fen wer­den, um notwendi­ge Voraus­set­zun­gen wie Ver­trauen und psy­chol­o­gis­che Sicher­heit zu schaf­fen. Doch ger­ade diese vie­len kleinen Schritte – der Weg – sind schon ein wichtiges Ergeb­nis: der Beginn, sich selb­st als Unternehmen immer wieder infrage zu stellen, sich um kon­tinuier­liche Verbesserung zu bemühen. Sie stellen den Beginn des agilen Vorge­hens dar.

Wie ein Schmetterling!

Und wenn wir die Trans­for­ma­tion hin zu Agil und DevOps als genau diesen Weg der vie­len kleinen Schritte sehen, wird schnell deut­lich: Jed­er kann anfan­gen – bei der eige­nen Arbeit, dem eige­nen Ver­hal­ten und dem eige­nen Denken! Und jede kleine Verän­derung bei sich selb­st wird Auswirkun­gen haben auf andere in ihrer Wahrnehmung, ihrem Ver­hal­ten, ihrem Denken. Dieser Ansatz wird auch als der But­ter­fly-Effekt beze­ich­net. Hier­bei kommt es nicht darauf an, in welch­er Hier­ar­chieebene sich die einzelne Per­son befind­et oder welche Rolle oder Posi­tion sie innehat. Vielmehr geht dieser Ansatz davon aus, dass jed­er in einem Unternehmen Ein­fluss und Macht hat und dies entsprechend (pos­i­tiv) nutzen kann. Wir müssen uns dessen nur bewusst sein und die Ver­ant­wor­tung dafür übernehmen, etwas ändern zu wollen. Hier­bei kommt auch der Respon­si­bil­i­ty Process von Christo­pher Avery wieder ins Spiel: nur in der „Opfer­rolle“ zu ver­har­ren und darauf warten, dass andere etwas ändern, wird das Prob­lem nicht lösen. Nur wer aktiv Ver­ant­wor­tung dafür übern­immt und aktiv wird, trägt zur Lösung bei.

Was kann ich dazu beitragen?

Wenn wir also in dieser Trans­for­ma­tion hin zu Agil und DevOps vom Weg der vie­len kleinen Schritte aus­ge­hen, sollte meines Eracht­ens die Frage laut­en: Was kann ich dazu beitra­gen, dass wir uns in diese Rich­tung bewe­gen? Die Antworten hier­auf kön­nen sehr vielfältig sein und hän­gen stark von Per­son und Umge­bung ab. Es kön­nen Gespräche geführt, die eigene Arbeitsweise auf den Prüf­s­tand gestellt oder das eigene Han­deln reflek­tiert wer­den, um her­auszufind­en, was denn die eigene Rolle inner­halb eines Prozess­es ist. Jed­er kann aber auch schauen, wie das eigene Han­deln und das eigene Ver­hal­ten unter Umstän­den genau das unter­stützen, was eigentlich abgeschafft wer­den soll. Wir kön­nen über­prüfen, wie es zum Beispiel um unser eigenes Ver­trauen ste­ht – in Bezug auf uns selb­st, auf unser Team und auf unsere Vorge­set­zten. Wer allerd­ings auf die Frage „was kann ich dazu beitra­gen“ nur mit einem ern­sthaften „Nichts“ antworten kann, sollte sich eine andere die Frage stellen: Was ist eigentlich meine Bedeu­tung für dieses Unternehmen?

Veränderung von innen heraus

Mit gutem Beispiel voranzuge­hen, ist ein hil­fre­ich­er Ansatz, der andere motivieren wird, zu fol­gen. Mul­ti­p­lika­toren entste­hen und helfen dabei, die Verän­derun­gen voranzubrin­gen. Und ja, das alles bedeutet, dass wir Mut brauchen und Aus­dauer haben müssen! Kleine Schritte, san­fter Flügelschlag, steter Tropfen! Und an einem bes­timmten Punkt, wenn schon ein paar Mul­ti­p­lika­toren mit dabei sind, kommt eine andere wichtige Frage ins Spiel: Was kön­nen WIR gemein­sam tun, um Agilität und DevOps zu etablieren und weit­erzuen­twick­eln? Wenn wir dort angekom­men sind und die Fra­gen nach dem „Wir“ stellen, haben wir die richtige Aus­gangspo­si­tion für Agil und DevOps geschaf­fen: denn bei bei­den geht es um das „Wir“, das Team und die gemein­samen Ziele!

Faz­it: Sei mutig, übern­imm Ver­ant­wor­tung, gehe deine ersten kleinen Schritte! Sei der Schmetter­ling, der stete Tropfen und das gute Beispiel! Wenn du auf diesem Weg einen neu­tralen Gesprächspart­ner oder eine andere Sichtweise brauchst, kann dir Coach­ing oder Spar­ring helfen. Pro­biere es ein­fach ein­mal aus – online oder persönlich!