DevOps and Unicorns

Lucas:

Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcasts! Heute habe ich mir die Anja eingeladen. Hallo Anja!

Anja:

Hallo Lucas!

Lucas:

Und wir reden heute über DevOps und Einhörner, mal schauen wo uns die Reise hinführt! Anja, bist du eigentlich ein DevOps Engineer?

Anja:

Nein, das bin ich nicht. Und ich behaupte auch, dass es die Rolle des DevOps Engineers gar nicht gibt.

Lucas:

Okay. Dann bin ich mal gespannt! Auf das Thema kommen wir auf jeden Fall gleich nochmal zurück. Aber bevor wir dahin kommen, ich glaube wir sollten einmal nochmal ganz kurz das Thema DevOps anschneiden. Woher kommt DevOps? Woher kam diese Idee? Und ja, wie hat sich das vielleicht auch ein bisschen entwickelt?

Anja:

Ja, gut. Also das war so ein langsamer und stetiger Entwicklungsprozess. John Willis, das ist ein Co-Autor von dem DevOps Handbuch, hat das ganz gut beschrieben als DevOps Konvergenz. Das heißt es hat ein bisschen gedauert bis DevOps das geworden ist was es ist und DevOps entwickelt sich auch immer weiter. Also DevOps kam ursprünglich aus dem Lean Movement. Das formierte sich so in den 90er Jahren, ist natürlich noch immer präsent, aber da tauchte das auf. Dann das Agile Manifesto hat auch seinen Teil dazu beigetragen 2001. Dann kam Continuous Delivery auf 2006 und so entwickelte sich langsam alles Richtung DevOps. DevOps an sich wurde als erstes genannt 2009 bei einer Konferenz. Ja.

Lucas:

Okay und was verstehst du unter dem Begriff DevOps? Ich glaube viele Leute verstehen ja verschiedene Sachen drunter? Also ich habe in vielen Projekten jetzt schon DevOps-Engineers… bin ich begegnet und du sagst ja, sowas gibt es gar nicht. Was ist denn für dich DevOps?

Anja:

Ja, gut. Also um ehrlich zu sein, DevOps… also das Ziel von DevOps, das ist im Grunde die Delivery Performance verbessern, die Software Delivery Performance zu verbessern. Wer hätte gedacht, dass es dann eigentlich so eine menschzentrierte Kultur ist? Denn es ist Kultur. Also wenn du mich danach fragst was das ist, es gibt eine kurze und eine lange Antwort.

Lucas:

Wir haben Zeit, dann gib mal die lange Antwort!

Anja:

Die lange Antwort. Ich will trotzdem kurz mal die kurze nehmen, weil ich finde man kann es ganz kurz machen, indem man sagt: DevOps ist im Grunde, hat drei kulturelle Werte meiner Meinung nach: Vertrauen, Wissenstransfer und Experimente. Und die lange Antwort, die kommt auch aus dem DevOps Handbuch. Das ist wirklich ein sehr gutes Buch muss ich sagen! Da sind auch drei Prinzipien… werden dort genannt. Also: Prinzip von Flow, Feedback und Experimenten und Lernen. Also das Prinzip von Flow, da geht es um fast iterations, schnelle Iterationszyklen, schnelle Development-Zyklen, kleine batch sizes, also dementsprechend kleine Code-Teile, die deployed werden. Dementsprechend ist man schneller am Markt, der Durchsatz ist erhöht. Das alles soll aber auch visibel passieren. Das heißt, die Arbeit soll sichtbar sein. Die Nutzung von Kanban Boards wurde da zum Beispiel empfohlen, die Art wie wir heutzutage arbeiten. Es geht aber auch darum die Prozesse generell zu verbessern, und zwar kontinuierlich. Also eine Kultur von continuous change zu etablieren, wo man immer wieder Prozesse sieht, misst und verändert und daraus lernt und sie vielleicht wieder umschmeißt. Ja, das wäre Flow. Dann Feedback, sagt im Grunde schon vieles aus. Dadurch, dass ich diese schnellen Release-Zyklen habe, habe ich auch schneller Feedback. Wenn ich Monitoring und Alerting aufsetze, weiß ich wie es um die Qualität meiner Software bestellt ist, kann das schnell fixen. Dadurch, dass ich Monitoring und Alerting habe, habe ich auch… sind auch alle Daten zu sehen. Hoffentlich sind sie zu sehen. Und daraus können Teams lernen. Und sie können lernen und das erhöht natürlich auch die Softwarequalität. Ja und das dritte Prinzip ‚continuous learning and experimenting, ist so ein bisschen finde ich überall drin, aber da wird nochmal explizit darauf hingewiesen, dass wenn etwas schief läuft, das gut ist. Weil daraus kann man lernen. Und dementsprechend sollte man vielleicht auch versuchen zu scheitern. Öfter zu scheitern, Experimente auszuprobieren, daraus zu lernen und dann hat man am Ende vielleicht neue Technologien adaptiert, die einem sehr viel weiterhelfen und man hat eine neue Technologie implementiert, die funktioniert. Oder eben auch nicht und man weiß warum sie nicht funktioniert.

Lucas:

Okay. Du hast eben schon gesagt, irgendwie ein zentraler Wert von DevOps ist Vertrauen. Meine Beobachtung ist, dass Vertrauen auf jeden Fall so eine Sache ist, die sowohl Unternehmen besser macht, ist ja auch ein Kernprinzip von INNOQ, ist ja auch so Vertrauen, aber auch die Projektarbeit wird dadurch viel schneller in ganz vieler Hinsicht. Wenn man den anderen Leuten vertraut, dann kann man auch Aufgaben abgeben und kontrolliert sie nicht die ganze Zeit, hat nicht irgendwie diese ganzen Abnahmen und so weiter. Wo siehst du da die Rolle von DevOps in Vertrauen?

Anja:

Die Rolle von DevOps in Vertrauen… Also ich kann nicht sagen: Ich implementiere DevOps ohne das Vertrauen in der Organisation stattfindet. Also ein ganz großer Teil von DevOps ist Vertrauen und das impliziert dann ja auch die Teamautonomie. DevOps-getriebene Organisationen halten Teamautonomie sehr hoch.

Lucas:

Okay. Also für dich ist Autonomie auch ein ganz wichtiger Teil von DevOps.

Anja:

Ja, auf jeden Fall! Das ist ein sehr wichtiger Bestandteil, ja.

Lucas:

Okay. Und ich glaube wir sollten nochmal kurz auf das Wort Autonomie eingehen, weil das glaube ich auch mache Leute verschieden verstehen. Was ist für dich Autonomie?

Anja:

Für mich persönlich ist Autonomie das Teams handlungsfähig sind. Also das sie nicht viele Abhängigkeiten haben und ihre Arbeit tun können.

Lucas:

Okay, cool! Wir haben im Vorgespräch auch so ein bisschen darüber gesprochen, dass DevOps oft falsch verstanden wird. Eine Sache, die man da irgendwie hört ist dieses ‚you build it, you run it‘. Und ich glaube das löst bei vielen Leuten, mich eingeschlossen für eine ganze Zeit, die Angst vor diesem: jetzt muss ich auch noch Operations können, jetzt muss ich auch noch verstehen wie man so einen Server laufen lässt. Wie siehst du das? Wiederspricht das… Also ist das notwendig? Muss ich jetzt neben Frontend und Backend auch noch Operations vollständig beherrschen? Wie siehst du das?

Anja:

Ja, ich glaube das ist genau dasselbe Problem, was auch diese imaginäre Rolle ‚DevOps-Engineer‘ hat. Also es kommt eben aus der selben Richtung. Also man… Es gibt Leute, die interpretieren den DevOps-Engineer zum Beispiel als eine Person, die kennt sich mit Betrieb aus, ja und wurde früher Operations-Engineer genannt. Das ist im Grunde nur ein neuer Name für eine etablierte Rolle. Und dann, wie du schon sagst, gibt es halt eine Interpretation von DevOps-Engineers, die sind… die machen Entwicklungsarbeit, die kennen sich aber auch mit Betrieb aus, CI/CD im Speziellen und sind irgendwie ähnlich wie eben diese Full Stack Engineers irgendwie eine Person, die einfach alles können muss. Die im Alleingang eine Applikation hinstellt. Also you build it, you run it, wie du gesagt hast. Ja, aber solche Unicorns, die erwartet man doch gar nicht. Bei DevOps geht es um Teamarbeit. Das heißt: Nicht jeder muss alles können, aber das Team sollte… sollte auch nicht alles können, aber sollte wenigstens handlungsfähig sein alles durchführen zu können. Das heißt, wenn ich nicht weiß wie ein Betrieb funktioniert, wie ich meine Applikation in Betrieb stellen kann, dann brauche ich Hilfe dazu. Ich kann mir Hilfe nehmen, weil die Organisationsstruktur gibt mir Hilfe.

Lucas:

Okay, also… Das heißt also die Erwartung von DevOps ist nicht, dass jede einzelne Person ein Kubernetes Cluster betreiben kann, sondern dass ein Team weiß wen… also wie sie bestimmte Teile selber macht. Oder wie siehst du das?

Anja:

Ja, zum Beispiel wenn du jetzt über ein Kubernetes Cluster redest, vielleicht gibt es ja ein Team, die mir helfen. Ein Enabling Team zum Beispiel, die sagen: ‚Hey, du möchtest deployen? Klar, wir sagen dir wie!‘. Oder noch besser, es gibt Tools, die mir das abnehmen. Indem ich nur eine kleine YAML schreiben muss, in der steht wo mein Container liegt, wie die Applikation heißt, welche Endpunkte sie braucht und ich das dann mit irgendeiner Art von Tool deployen kann. Dann habe ich zwar auf Kubernetes deployed, brauche aber kein Fachwissen wie Kubernetes funktioniert, sondern das wurde mir abgenommen durch Teams, die mir helfen, andere Teams, die mir helfen.

Lucas:

Und wie unterscheidet sich das jetzt von so einem klassischen Betrieb? Also wenn du das jetzt so beschreibst, klingt das ein bisschen wieder so als ob ich doch wieder etwas über den imaginären Zaun werfe und sagen: ‚Ihr auf der anderen Seite, bitte betreibt das mal für mich!‘ Nur dass ich irgendwie noch eine YAML dazugelegt habe. Wo siehst du da den Unterschied?

Anja:

Es gibt auf jeden Fall einen Unterschied zwischen Operations- und zum Beispiel Plattformteams. Also Operationsteams die haben, wie du schon sagtest, traditionell Betrieb gemacht. In modernen Organisationen ist ja so, dass sie mehr bei der Ressourcenbeschaffung helfen. Also ich kann mir Ressourcen wie VMs oder Datenbanken also über ein Ticketsystem zum Beispiel bestellen, warte dann darauf. Im schlimmsten Fall vielleicht sogar mein Git Repository, was ich mir dann bestellen muss auf diese Art. Genau. Die haben mir aber auch vielleicht bei incidents geholfen. Also so ein Operationsteam ist schon ganzschön wichtig, aber dieses Ticketsystem ist schon ganzschön schwerfällig. So ein Plattformteam arbeitet da anders. So ein Plattformteam stellt mir eine Plattform bereit, Tools bereit, dass ich mir selber helfen kann. Ich bin also nicht abhängig von so einem Plattformteam. Im Gegenteil, so ein Plattformteam, die kümmern sich im Grunde nur um die Plattform und gar nicht um meine Applikation. Um meine Applikation kümmere ich mich selber, ich habe alle Tools. Ich habe ein Deployment Tool, ich habe Monitoring und Logging. Das heißt: Ja, ich betreibe meine Applikation selbst, aber ich habe Tooling, das mir das super einfach macht. Und wenn ich wirklich Probleme habe bei einem incident, dann gibt es hoffentlich Menschen, die mir dann helfen durch Enabling Teams oder was für Facilitator-Rollen, die mir da Unterstützung anbieten, was nicht unbedingt das Plattformteam sein muss.

Lucas:

Also du hast jetzt so ein paar Worte zwischendurch reingeworfen, die müssen wir glaube ich nochmal kurz auseinander nehmen. Also das erste wäre für mich das Wort Plattform. Was verstehst du unter einer Plattform? Was gehört da so zum Beispiel dazu? Also was muss ich mir da vorstellen?

Anja:

Ja, eine Plattform kann im Grunde eine Dokumentation sein die sagt: ‚So deployst du!‘ Zum Beispiel kann das so CloudFormation Templates sein, damit ich auf AWS deployen kann. Oder irgendwelche Runbooks oder auch einfach eine Markdown Dokumentation. Also wenn das reicht um mir zu helfen, dass ich schnell deployen kann, dann… oder halt Betrieb machen kann, dann ist das vollkommen ausreichend. Aber heutzutage hat sich etabliert, dass man zum Beispiel Kubernetes als Basis nimmt und darauf dann eine komplexe Applikationsplattform drauf baue. Das ich vielleicht eine UI habe in der ich sage: Ich möchte eine neue Applikation deployen, da liegt der Container, diese Endpunkte brauche ich und so weiter. Oder eben diese kleine YAML, die ich dann irgendwo hochlade. Das ist eine Plattform, so irgendwie zum Beispiel das kann eine selfe-service API sein oder auch Deployment-Tools. Oder eine Dokumentation.

Lucas:

Also eine Sache mit der ich in der Vergangenheit viel gearbeitet habe ist Heroku. Das heißt ich kann mir das so ein bisschen vorstellen wie auch in Heroku, wo ich sage ‚git push‘ und dann kann ich mir auch Logs auf so einen Webinterface angucken. Und so in die Richtung.

Anja:

Genau, das wäre sozusagen die komplexeste Art davon. So eine komplexe Applikationsplattform. Aber man muss auch dabei sehen, Heroku gibt es, also könnte man es auch benutzen. Das heißt es muss einen Mehrwert geben, dass ich meine eigene Plattform erstelle. So Heroku ist zwar sehr einfach, aber vielleicht auch nicht so flexibel. Vielleicht muss ich wirklich eine eigene Plattform für meine Teams aufbauen und die genau die Use Cases abbildet, die die Entwicklungsteams brauchen und denen einfach Arbeit abnimmt. Damit sie sich auf die Fachdomäne konzentrieren können.

Lucas:

Ja, also ich bin auf jeden Fall auch schon bei Heroku ein paar Mal an unangenehme Grenzen gestoßen. Sieht man auch gerade, wenn man dann eine Datenbank braucht, die bei denen vielleicht nicht im Portfolio ist. Dann stößt man relativ schnell an die Grenze. Du hast ein anderes… anderen Begriff den du verwendet hast war ‚Enabling Teams‘. Was muss ich mir darunter vorstellen? Was bedeutet das?

Anja:

Also ich muss sagen, das ist ein Begriff aus ‚Team Topologies‘, ein anderes sehr gutes Buch was ich empfehlen kann. Enabling Teams sind dafür da um Teams zu unterstützen. Also ich muss vorher die Terminologie glaube ich mal erklären. Es gibt Stream-aligned Teams, die entwickeln entlang einer bestimmten Fachdomäne. Also die produzieren sowas wie self-contained systems oder Microservices. Ein… Also wirklich ein System, was in sich abgeschlossen ist zu einer Domäne, damit die sich drauf konzentrieren können. Enabling Teams sind die Unterstützung bei Architekturarbeit, bei technischen Fragen, bei Delivery Fragen. Das sind Teams, die zu anderen Teams gehen und sagen: ‚Okay, du brauchst Hilfe? Ich helfe dir!‘ oder ‚Schau mal, ich habe hier eine Dokumentation geschrieben, das kann dir helfen.‘ oder ‚ Ich habe hier eine Pipeline, eine generische Pipeline, vielleicht hilft die dir.‘ Team Topologies definiert auch Plattformteams übrigens, die dann eben auch für diese Stream-aligned Teams halt unterstützend wirken. Es geht eigentlich immer nur darum die Stream-aligned Teams zu unterstützen, damit sie handlungsfähig sind, damit sie autonom sein können. Obwohl sie nicht alles können, aber sie sind wendig.

Lucas:

Das heißt also, wenn ich mir die Topologie jetzt vorstelle, dann habe ich also mehrere nebeneinanderlaufende unabhängige Stream-aligned Teams und dann können die sich aus verschiedenen Enabling Teams quasi Hilfsstellungen suchen.

Anja:

Ja, genau! So kann man sich das vorstellen.

Lucas:

Okay. Eine Sache, die du auch schon erzählt hast, ist das Thema Plattform. Ich glaube eine Idee, die sich dabei ändert… also gerade wenn man darauf schaut und sagt so: ‚Wir brauchen ein Heroku, was mehr unseren Vorstellung entspricht.‘ Dann führt das ja irgendwie zu einem Produkt. Was denkst du bedeutet das? Also was bedeutet das seine Plattform als Produkt zu begreifen?

Anja:

Okay, also meine Applikation, die läuft ja auf dieser Plattform und meine Applikation ist vielleicht, hat Kundschaft, die dafür zahlt, dass diese Applikation läuft und verfügbar ist. Also muss meine Plattform auch hoch verfügbar sein. Also sogar verfügbarer als die Anwendung selbst, sie ist also schon relevant für das Endprodukt. Also ist es wichtig diese Plattform auch als Produkt zu behandeln, vielleicht hat diese Plattform sogar einen eigenen Product Owner. Ja, es gibt vielleicht Feature Requests von Entwicklungsteams, die priorisiert werden müssen. Das heißt, diesen Software Lebenszyklus den wir für allgemeine Anwendungen haben, den müssen wir auf die Plattform bringen und wir haben dementsprechend auch genau so Stakeholder, die im Endeffekt auch der Endkunde ist.

Lucas:

Warum muss den die Plattform verfügbarer sein als mein Endprodukt?

Anja:

Ja, wenn mein Endprodukt eine höhere Verfügbarkeit hat als meine Plattform, dann heißt das ja, dass dann meine Plattform nicht erreichbar ist und… dass meine Anwendung auch nicht erreichbar ist. Das sollten wir verhindern! Also die Plattform sollte verfügbarer sein.

Lucas:

Ja, also das ist einfach gar nicht anders möglich, sonst würde das irgendwie magisch ohne die Plattform passieren. Das heißt, ich muss mir das auch so ein bisschen vorstellen, also ich bin jetzt einer von den Stream-enabled Teams. War das der richtige Begriff?

Anja:

Ein Stream-aligned Team.

Lucas:

Stream-aligned, okay. Ein Stream-aligned Team und ich habe mich jetzt entschieden MongoDB ist genau die richtige Datenbank für mein Produkt. Und dafür gibt es jetzt noch kein Runbook oder irgendwas anderes Fertiges. Das heißt also, ich würde dann zum Product Owner oder zur Product Ownerin gehen und sagen: ‚Wir brauchen in unserer Plattform MongoDB, bitte ordne das mal ein in eure Priorisierung.‘? Oder wie muss ich mir das vorstellen?

Anja:

Ja, also wenn man sich das so vorstellt, dann bin ich ja trotzdem wieder abhängig als Team. So, ich brauche meine MongoDB, aber die ist noch nicht da und ich muss das irgendwo einkippen, dann wird das wieder zum Ticket. Dann sind wir wieder bei den Operationsteams. Ich bin so ein Fan von der Philosophie: ‚Prinzipien statt Regeln‘. Weil Autonomie sonst halt wertlos ist. Also eine Regel ist ein Verbot und ein Prinzip ist eine Empfehlung. Das habe ich mir nicht selbst ausgedacht, sondern, ich weiß nicht ob ich ihn richtig ausspreche, der Beat Kunz hat sich das ausgedacht. Das heißt Teams brauchen den Freiraum auch mal selbst entscheiden zu können, was für das Produkt das beste ist. Und wenn das halt… Wenn so eine MongoDB noch nicht existiert, dann kann ich mir die auch anderweitig holen. Vielleicht habe ich da Hilfe sie mir anderweitig zu holen, aber ich habe die Autonomie, die Freiheit, sie mir anderweitig zu holen und von der Plattform sozusagen abzuweichen. Wo sonst als Prinzip eigentlich beispielsweise so PostgreSQL gesetzt ist. Aber das halt zum Wohle des Produkts, damit ich handlungsfähig bin, damit das Produkt schnell verfügbar gemacht werden kann. Genau. Und diese Art von Freiheit sollte man Team zugestehen, damit das Produkt halt auch davon profitieren kann.

Lucas:

Okay. Aber bedeutet das also, dass das so ein bisschen so ein Trade-off ist? Also dass man eventuell so ein bisschen in den Wildwuchs reinläuft und nachher hat man irgendwie 30 verschiedene Datenbanken, die man managen muss und 240 Programmiersprachen? Kann das passieren oder ist das eine unbegründete Furcht?

Anja:

Also im Grunde sollte man sich immer an die Prinzipien halten. Also wenn ich sage ‚Prinzipien statt Regeln‘, dann sind die Prinzipien dennoch immer noch Prinzipien. Ich sollte mich grundsätzlich an Prinzipien halten. Wenn gesagt wird: ‚Bitte entwickelt nur auf Java oder auf Go.‘, dann habe ich halt nicht so wirklich Wildwuchs und nur manchmal irgendwelche JavaScript Ausbrecher oder ähnliches. Aber man könnte zum Beispiel auch sagen: ‚Okay, das Prinzip ist entwickelt…‘ oder halt ‚Macht einfach einen Container draus!‘. Dann habe ich das alles abstrahiert und da ist die Sprache total egal. Ich kann meine Plattform so entwickeln, dass sie mir halt Freiheiten einräumt, ohne dass die Plattformteams einen Wildwuchs managen müssen. Aber ich weiß was du meinst. Es gibt zum Beispiel auch shared libraries, die ich für alle möglichen Sprachen vielleicht brauche. Das ist ein Problem, auf jeden Fall, aber das Problem hatte ich halt auch schon vorher.

Lucas:

Ja. Ja, klar. Also das Problem existiert auf jeden Fall. Wir müssen halt irgendwie immer so ein bisschen die Balance zwischen finden. Wenn wir dann nachher fünf Teams haben und jedes hat einen vollständigen anderen Stack, dann ist es fast unmöglich eine Person von Team A zu Team B zu verschieben, weil man dann erstmal alles neu lernen muss. Aber wenn man es zu rigoros gestaltet, dann nimmt man den Teams auf jeden Fall ihre Autonomie weg und wenn man dann halt irgendwie, rein hypothetisches Beispiel, irgendwie eine Cassandra als Unternehmensdatenbank festgelegt hat, dann ist es halt blöd, wenn die Cassandra überhaupt nicht zu meinen Problemen passt.

Anja:

Auf jeden Fall! Da stimme ich dir zu.

Lucas:

Okay. Ein Thema, das auch in DevOps immer wieder ein Thema wird, weil ich glaube, dass das auch einfach sowas ist, wo viele Narben von haben, ist das Thema ‚Übergaben‘. Also man muss irgendetwas in den Betrieb übergeben oder irgendetwas braucht eine Abnahme. Wie vermeiden wir das in dieser Denkweise, in dieser Teamstruktur?

Anja:

Also ich behaupte, dass wir es damit vermieden haben. Also wirklich DevOps-getriebene Teams betreiben ihre Software bis sie irgendwann stirbt, sollte sie sterben. Das bedeutet, so ein Team ist tatsächlich gebunden an ihren Service. Es gibt keine Übergabe, ich meine warum auch? Also wenn es keinen… Wenn es eine Plattform gibt in der ich selbstständig meine Applikation betreuen und administrieren kann, gibt es keinen Grund irgendwann so ein Handoff zu machen. Ich kenne, dass da anderen… Also ich kenne das manchen Projekten, dass ein Team, zum Beispiel war so high performing. Die haben immer sehr gut gearbeitet. Und haben dann eine Software abgeliefert und tatsächlich abgeliefert. Und dann wurde gesagt: ‚Okay, das wird jetzt zu einen low performing Team rübergeschoben und jetzt bekommt das high performing Team einen weiteren Service, dass sie wieder aufmotzen können und dann wird das wieder rumgeschoben.‘ Und das ging dann immer so weiter bis die Services dann vielleicht irgendwann alle richtig gut sind. Ja, das halte ich nicht für sinnvoll. So ein Team…, haben wir ja gesagt, so ein Team kümmert sich nur um eine Fachdomäne und das sollte auch so bleiben. Also wir wollen, dass ein Team möglichst wenig Kontextwechsel hat, immer nur in der selben Fachdomäne bleibt. Und wenn vielleicht weitere Services hinzukommen, dass sie in der Nähe der Fachdomäne sind und eher kleinere Nebendomains sozusagen sind. Wir wollen keinen… Wir wollen das nicht, denn… Ich meine das kennst du ja auch, du kannst nicht ein Experte in X sein und ein Experte in Y sein, irgendwo ist da ein Trade-off. Dann bist du halt in allem nur so mäßig gut. Und wenn ich eine Plattform habe in der ich meine Anwendung selbstständig betreiben kann und Hilfe dazu bekomme, dann brauche ich ja keine Übergabe.

Lucas:

Ergibt Sinn!

Anja:

Und was dabei auch noch passiert, das darf man nicht vergessen, wir sind alle Menschen. Ich meine wir wollen alle irgendetwas bauen, wir wollen da gut darin sein und wir möchten zeigen: ‚Schaut mal, das haben wir gebaut und ich bin der Experte in dieser Fachdomäne. Und dieser Service ist richtig gut!‘ Ich meine warum sollte man das aufgeben wollen, um wieder neu von vorne beginnen zu müssen?

Lucas:

Okay. Also das heißt, also für dich ist das auch so eine Frage der Motivation.

Anja:

Auf jeden Fall!

Lucas:

Dass man den Leuten mehr Autonomie gibt, erhöht einfach die Motivation der Leute.

Anja:

Also bei mir ist das so, auf jeden Fall!

Lucas:

Ja, bei mir ist das definitiv auch so! Okay. Okay, also das klingt ja alles sehr cool! Klingt so als würde ich schneller mein Produkt bauen können. Also möchte ich das jetzt haben, wie komme denn da hin?

Anja:

Ja, das ist nicht so einfach. Es kommt darauf an in welcher Art von Organisation du arbeitest. Ob die groß ist, ob die klein ist, wie verkrustet die Strukturen schon sind. Man kann sich leider nicht für eine Kultur entscheiden und dann hat man die einfach so. Also Kultur entsteht von allein. Aber man kann tatsächlich so eine Richtung beeinflussen, dass es vielleicht in die Richtung geht, die man gerne hätte. Es gibt ein… Also es gibt ein Gesetz des Organisationsverhaltens von Larman, der hat das entdeckt oder sich ausgedacht. Und das vierte Gesetz heißt: ‚Culture follows structure.‘, also Kultur folgt aus Struktur. Das ist erstmal so ein bisschen kontraintuitiv finde ich. Dabei heißt Struktur, also Organisationsstruktur, also Gruppen, Teams, Verantwortlichkeiten, aber auch so Belohnungsmechanismen und Richtlinien, über die wir schon gesprochen haben. Und so eine Organisationsstruktur muss sich ändern, damit eine angestrebte Kultur möglich ist. So verkrustete Strukturen muss ich aufbrechen und reorganisieren. Keiner hat da Lust drauf, aber das kann dazu führen, dass eine Kultur sich ändert, die sich vielleicht schon etabliert hat. Es gibt… Ein anderer sehr schlauer Mensch hat auch etwas gesagt zu Organisationskulturen und dass es halt auch pathologische Organisationskulturen geben kann. So eine pathologische Organisationsstruktur oder halt Kultur, die bestraft zum Beispiel Boten von schlechten Nachrichten. Also diejenigen, die die Fehler entdecken und diese vielleicht auch beheben wollen. Und einfach nur sagen wollen: ‚Hey, wir haben hier ein Problem!‘. Im Gegensatz zu generativer Organisationskulturen, die fördern den freien Informationsfluss, also um eben besser zu werden. Das heißt wir haben mehr Vertrauen und wir lernen aus Fehlern. Ja, also ich muss meine Organisationsstruktur verändern, um einer Kultur freien Raum lassen zu können. Und da empfehle ich eben auch noch das Buch ‚Team Topologies‘, was auch auf jeden Fall darauf eingeht: Wie kann ich mit der Umstrukturierung meiner Struktur eine Kultur fördern? Die DevOps Kultur fördern im Grunde.

Lucas:

Cool! Ja, dann danke ich dir Anja! Wir werden auf jeden Fall ein paar Bücher als Lektüre in die Shownotes packen für die Leute, die sich da noch ein bisschen mehr mit beschäftigen wollen, mit Team Topologien und auch DevOps an sich. Ja und dann sage ich danke dir und allen Zuhörerinnen und Zuhörern! Und bis zum nächsten Mal!

Anja:

Bis dann!

Lucas:

Tschüss!