Eine weitere Folge zum Thema Team Topologies. Wir haben Felix Kronlage-Dammers zu Gast. Mit ihm sprechen wir über seine Sicht auf das Buch Team Topologies und wie er das in seiner Praxis als COO bei gridscale anwenden konnte. Er skizziert unter anderem seine Herausforderungen und wie er die Ideen und Konzepte aus Team Topologies nutzen konnte, um einen verteilten Monolithen zu beherrschen. Natürlich beschreibt Felix auch, wie DevOps bei gridscale technisch und organisatorisch gestaltet ist. Er erzählt, was Winston Wolf aus Pulp Fiction mit gridscale und was Spotify mit Team Topologies zu tun hat. Zum Schluss erklären wir die Verbindung von Felix und Luca zu Dierks DevOps Mastermind Klub!
In dieser Episode des DevOps-Podcasts, moderiert von Luca Ingianni und Dierk Söllner, teilt Felix Kronlage-Dammers, COO von Gridscale, seine Einblicke in die Reise des Unternehmens hin zu Team Topologien. Die Diskussion vertieft sich in die technischen und organisatorischen Herausforderungen, die während des Wachstums von Gridscale auftraten, einschließlich ihres Übergangs von Monorepo zu Multirepo und der strategischen Bildung verschiedener Teams wie ‚Team Wolf‘. Sie erkunden die Feinheiten von DevOps, Automatisierung und wie das Lernen aus Fehlern ein wichtiger Teil ihrer Organisationskultur ist. Das Gespräch berührt auch das Spotify-Modell und seine Anwendbarkeit in verschiedenen organisatorischen Kontexten.
Inhalt
- Einführung in die Episode und die Gäste
- Hintergrund und Rolle von Felix Kronlage-Dammers bei Gridscale
- Definition und persönliche Ansichten zu DevOps
- Gridscales Übergang zu Team Topologien
- Herausforderungen bei organisatorischem Wachstum und Strukturveränderungen
- Diskussion über die Verwendung von Monorepos vs. Multirepos
- Rolle und Struktur von ‚Team Wolf‘ bei Gridscale
- Erkundung des Spotify-Modells und seiner Umsetzung
- Einblicke in das Lernen aus Fehlern und die Förderung einer Experimentierkultur
- Zukünftige Richtungen und offene Fragen zu Team Topologien
Shownotes:
Blogpost – Phoenix Project Online
Buch Empfehlung – An Elegant Puzzle: Systems of Engineering Management
Felix Blog
Felix bei Twitter
gridscale
DevOps Mastermind Klub
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps. Auf die Ohren und ins Hirn. Ein Podcast rund um DevOps. Von Luca Ingianni und Dierk Söllner.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps. Auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni und Dierk Söllner. Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns beide kulturelle, organisatorische und technische Aspekte.
Diese diskutieren wir mit Experten aus der Praxis oder in einer gemeinsamen Folge, wo nur Luca und ich etwas sprechen.
Wir freuen uns heute auf das Thema Gridscales Weg zu Team Topologies.
Zu Gast haben wir Felix Kronlage-Dammers.
Felix ist COO bei Gridscale und ich glaube es ist einfach besser, wenn sich Felix gleich selber vorstellt.
Felix, bitte sehr.
Moin und vielen Dank Dirk. Moin auch Luca.
Genau, ich freue mich hier zu sein. Zu meiner Person Felix.
Ich bin seit Herbst 2018 bei Gridscale.
Bin dort zusammen mit Hendrik Hasenkamp in der Geschäftsführung und verantworte dort den…
…technischen Bereich von Gridscale.
Der technische Bereich, das bedeutet im Prinzip Produktmanagement, Produktengineering und Betrieb unserer Plattform.
Vielleicht kurz was zu meiner Person.
Ich bin seit Ende der 90er in der Open-Source-IT-Szene unterwegs.
Hab für 15 Jahre lang die WideMine, ein Open-Source-IT-Infrastruktur-Dienstleister ursprünglich gegründet und bis Ende 2017 als Geschäftsführer begleitet.
Und hatte dort auch viele Berührungen.
Viele Berührungspunkte mit dem Thema DevOps, mit Automatisierung, mit Betrieb von großen Open-Source-Infrastruktur-Installationen und Ähnlichem.
Ich bin auf relativ vielen Baustellen unterwegs.
Ich bin nämlich auch noch im Vorstand der Open-Source-Business Alliance.
Also das Thema Open-Source treibt mich weiterhin um und bin dort viel aktiv.
Sehr schön.
Jetzt sind wir hier im DevOps-Podcast.
Und du hast ja eben selber auch schon gesagt…
…dass du dich auch mit dem Thema DevOps umtreibst.
Wir haben immer sehr viele schöne Definitionen, was DevOps ist.
Was ist denn für dich DevOps?
Ja, die Frage kommt natürlich nicht ganz überraschend, da ich ja tatsächlich ein Hörer von eurem Podcast auch bin.
Und so hatte ich ausgiebig Zeit, mich darauf vorzubereiten.
Jetzt könnte ich natürlich mit der ureigenen, langweiligen, finde ich, Definition der fünf Pfeiler kommen.
Also COIMS.
Culture, Automation, Lean, Measurement and Change.
Das will ich aber gar nicht.
Für mich setzt sich DevOps zusammen aus zwei Zitaten, die ich dafür mitgebracht habe.
Und das unterschreibt es auch schon ziemlich gut.
Das eine Zitat ist von Tim O’Reilly, dem Gründer des O’Reilly-Verlags.
Create more value than you capture.
Und das zweite Zitat ist von einem ehemaligen OpenBSD-Entwickler, Art Grabowski.
Only failures make success.
Work as experts.
Und diese zwei Zitate umfassen, also sind für mich im Prinzip zusammen die Symbiose, was für mich DevOps ausmacht.
Eben ein kultureller Mindset, der sich darüber definiert, dass man aus gemachten Fehlern lernt, diese möglichst iteriert, sodass ein besseres Ergebnis rauskommt.
Und das Bestreben danach ist, Mehrwerte zu erzeugen.
Create more value than you capture ist für mich im Prinzip der Inbegriff der Automatisierung.
Wenn ich etwas per Hand mache, mache ich es einmalig, vielleicht sehr gut, aber ich habe keinen konstanten Mehrwert geschaffen.
Mache ich eine Automatisierung, habe ich einen konstanten Mehrwert geschaffen, auf den andere wieder aufbauen können.
So, das wäre jetzt so meine Definition von DevOps.
Cool. Also ist auf jeden Fall was Neues.
Also auch zwei tolle Zitate mit dabei.
Jetzt haben wir den Titel schon angesprochen.
Gridskates Weg zu Team Topology.
Du hast ein bisschen was zu Gridscale gesagt.
Was macht denn ein COO, das ist ja deine Position bei Gridscale, was macht ein COO bei Gridscale, was macht Gridscale auch im Zusammenhang mit dem, was wir als Thema haben, Team Topologies?
Gridscale ist ein Softwarehersteller für einen vollautomatisierten Virtualisierungsdeck für das Rechenzentrum.
Das heißt, wir automatisieren und virtualisieren den Betrieb von Rechenzentren.
Das, was man auf den ersten Blick von Gridscale sieht, wenn man auf unsere Webseite kommt, ist ein Public-Cloud-Angebot.
Das Public-Cloud-Angebot realisieren wir mittels unseres eigenen Software-Stacks, den wir aber auch mittlerweile in die Data Center der Kunden bringen und dort für den Kunden betreiben.
Das heißt, anders als zum Beispiel VMware oder Nutanix, ist bei Gridscale der Betrieb, der Plattform für den Kunden.
Das heißt, dass wir tatsächlich uns als Softwarehersteller verstehen und auch mit entsprechenden Methoden bei Gridscale vorgehen, um die Dinge zu entwickeln.
Anders als zum Beispiel ein reiner Public-Cloud-Hoster, der halt nur auf den Betrieb seiner eigenen Plattform achtet, gehen wir tatsächlich einen Schritt weiter und haben überall auch Softwareentwicklungsparadigmen etabliert.
Zu meiner Rolle, du hattest mich gefragt, was ein COO macht.
Ja.
Also, es ist so, dass die Geschäftsbereiche, die bei mir liegen, ist eben Produktmanagement, Engineering und eben der Betrieb der Plattform.
Das ist allein schon deswegen so, damit Ressourcen, die innerhalb der Entwicklung und innerhalb des Betriebes sind, möglichst miteinander verzahnt sind.
Weil das natürlich auch ermöglicht, dass dort tatsächlich eben keine Silos entstehen, sondern miteinander integrativ gearbeitet wird.
Genau. Bei mir eben liegt das auch das Produktmanagement, also das Sicherstellen.
Genau. Bei mir liegt das auch das Produktmanagement, also das Sicherstellen.
Genau. Bei mir liegt das auch das Produktmanagement, also das Sicherstellen.
Okay. Das heißt, du kommst wirklich aus der Praxis, du weißt, was DevOps dann heißt auch, was das konkret für dich auch bedeutet.
Wie bist du denn auf das Buch gekommen von Team Topologies?
Vielleicht kannst du dazu nochmal ein bisschen was erzählen.
Und vor allen Dingen, warum hat es dich so begeistert, wie es auch Luca und mich begeistert hat?
Ja.
Da habe ich tatsächlich an der Stelle, muss ich zugeben,
eine gehende Leere im Kopf, weil ich nicht mehr genau weiß, wie ich auf das Buch gekommen bin.
Also entweder ich habe es bei IT Revolution auf der Webseite gesehen,
weil ich im Prinzip einen Großteil deren Portfolio mittlerweile gelesen habe und tatsächlich auf die Seite gestoßen bin.
Oder ich habe mit irgendeinem Kollegen darüber gesprochen und bin da mal hochgepoppt.
Ich weiß nur, dass ich es tatsächlich bestellt habe und dann in ziemlich kurzer Zeit sehr intensiv durchgekommen bin.
Und durchgearbeitet habe und dann festgestellt habe, dass das eines von den Büchern ist, wo, wenn man mit einem Textmarker arbeitet, im Prinzip die Hälfte des Buches gelte.
Also das war tatsächlich dann so.
Und mittlerweile habe ich es dann tatsächlich mehrfach auch durchgearbeitet, weil mich und ich glaube, das, was mich als allererstes getriggert hat bei dem Buch, war eben die Betrachtung, also Convays Law und das Inverse Convey Maneuver.
Und eben dieser Gedanke, okay, hey, wir haben hier eine Organisationsstruktur, wir haben hier eine Softwarearchitektur und lass uns das einmal von einer Seite auch betrachten, was das für Zusammenhänge hat.
Das fand ich sehr spannend und das hat mich jetzt sofort getriggert.
Okay, ja, spannend. Das war ja auch das, was mich so an dem Buch irgendwie, was mich da direkt angesprochen hat, weil ich finde, dass es einem, oder zumindest für mich war das so,
dass das endlich in Worte gefasst wurde.
Und das hat eine Sache, die mir irgendwie schon gedämmert war im Laufe der Jahre, aber wo ich halt irgendwie noch auch keinen Begriff dafür hatte.
Kannst du da irgendwie was erzählen, wo du besonders gesagt hast, ah, Donnerwetter, das ist mir doch irgendwie vorgestern begegnet oder vorletztes Jahr begegnet oder sowas?
Naja, also die Compiler-Geschichte, also das ist ja dieses Standardbeispiel, was ja in dem Buch…
…kommt, wo ich, was natürlich für jemanden wie mich, der relativ tief in der Technik ist, ja sofort und augenscheinlich war.
Und ich hatte aber das Gefühl, als ich diesen Teil vom Buch gelesen habe, dass ich im Prinzip hier saß und mir dachte, hm, im Prinzip ist das die Erklärung für das, was ich das letzte, vierte Jahr immer wieder versucht habe, an der einen oder anderen Stelle auch zu greifen.
Und für mich…
…sichtbarer zu machen, warum gewisse Dinge so sind, wie sie sind. Und so.
Mhm. Aber trotzdem, ich wäre so gespannt, ob du da irgendwie ein bisschen ein konkretes Beispiel, ob dir da was einfallen würde.
Also ich, als ich zu Gritzke gestoßen bin, also ich bin im Oktober 2018 bei Gritzke an Bord gekommen.
Also ich war, und ich war Mitarbeiter 21.
Und ab dann ging die Reise unseres Wachstums nochmal relativ gut weiter, weil wir dann innerhalb von anderthalb, zwei Jahren in Richtung 70 Mitarbeiter gesprungen sind.
Das heißt, wir haben dann da einen ziemlichen Shift gemacht, haben in dem Jahr vorher auch schon mal ein gutes Wachstum hingelegt.
Und was man da tatsächlich gesehen hat, ist, dass im Prinzip ab Mitte 2018 bis…
…anfang 2020, also so Ende 2019, durch den Wachstum in den Teams sich natürlich die Art und Weise, wie wir bei uns mit dem Arbeitsmittel, dem Quellcode umgehen und wie wir auch auf die Architektur blicken, durchaus verändert hat.
Und als ich bei Gritzke reingekommen bin, war es im Prinzip so, dass das Ideal…
…einmal wird eigentlich eine Microservice-Architektur der verschiedenen Komponenten ist.
Und was im Prinzip, wenn man guckt, es gibt einen sehr, sehr guten Blogpost von Kelsey Hightower von Google, der über den verteilten Monolithen geht.
Und also ein verteilter Monolith, also ein Monolith, was ist eine Microservice-Architektur, ist ja erstmal, dass in einer Microservice-Architektur hast du viele, viele kleine Komponenten,
…den du am Stück irgendwo hinschmeißt, startest und läufst.
Und der verteilte Monolith ist im Prinzip, du nimmst diesen Monolithen, baust ihn in eine Microservice-Architektur um, bist aber keine wirkliche Microservice-Architektur,
…sondern hast immer noch das…
…und die Herausforderung, dass du relativ viel Programmcode am Stück irgendwo hindeployen musst, damit es halt ordentlich funktioniert.
Und das ist im Prinzip etwas, wo sich dann sehr schnell auf die Abhängigkeit oder die Zusammenhänge zur Unternehmensorganisation auch zeigen.
Und ein gutes Beispiel, was ich dafür mitgebracht habe, ist, dass wir…
…also von der Architektur her haben wir verschiedene Teams, die sich um verschiedene Schichten bei uns kümmern.
Und ein guter Teil unserer inneren Schicht ist das, was seinerzeit bei uns tatsächlich das Team Python genannt wurde, weil eben ein großer Teil davon von dem Python entwickelt wurde.
Und dort gab es, ich meine Mitte 2019, dass wir das Team aufgeteilt haben in zwei Teams, nämlich ein Team, was unsere sogenannten Core-Services,
…bereitstellt, gewisse APIs, und ein Team, das nennen wir Smart-Services, was zum Beispiel unsere Datenbank-Dienste, also unsere Platform-Services, bereitstellt.
Und ursprünglich haben diese beiden Teams, waren in einem Team zusammen, das alles lebt in einem Monorepo und ist dadurch halt miteinander relativ verzahnt.
Und man könnte an der einen oder anderen Stelle tatsächlich auch sagen, dass es halt…
…also ist tatsächlich zu sehr verzahnt.
Und, ja, Dirk?
Ich habe gerade mal gedacht, Mensch, ich spiele mal jetzt denjenigen, der die Frage stellt, was ist ein Monorepo?
Sehr gut, danke.
Pardon, genau, da bin ich dann auch schon an der Stelle zu sehr Techniker.
Monorepo ist eine Art und Weise, den Quellcode zu organisieren.
…zu organisieren.
…zu organisieren.
Also ein Repository ist eine Organisationseinheit, in der du im Prinzip zusammenhängenden Quellcode organisieren kannst, mittels einer Versionskontrolle.
Also ein Versionskontrollmechanismus ist ja, dass du jede Änderung eincheckst und darüber nachverfolgbar machst.
Das heißt, darüber kannst du sehen, was ist der Unterschied zwischen einer Version und der nächsten Version im Quellcode.
Und da gibt es eben den Ansatz des Monorepos.
Alles ist in einem Repo und kann…
…dadurch sehr zusammenhängend deployed werden.
Oder du hast halt Multirepo, also pro Einzel deploybarer Komponente tatsächlich ein einzelnes Repository.
Und wir kamen ursprünglich von einer Multirepo-Welt, sind dann in eine Monorepo-Welt gewechselt und haben tatsächlich mittlerweile festgestellt, dass das…
…und das ist…
…das hat sich sehr gut dargestellt anhand dieser Teams, die wir dann wieder aufgeteilt haben, dass uns das an der Stelle tatsächlich auf die Füße fällt.
Wo man tatsächlich merkt, dass eben die Organisation und die Organisationseinheiten und das, wie andere Dinge organisiert sind, eben der Quellcode, die Deploy-Mechanismen, die ICD-Pipelines, Logik, Datenhaltung, dass das alles miteinander zu tun hat…
…und sich auch gegenseitig…
…sich tatsächlich sehr bedingt.
Weil jetzt auf einmal nämlich das eine Team, wenn es etwas ändern will, im gleichen Repo wie das andere Team arbeitet und nicht mehr unabhängig voneinander deployen kann.
Das heißt, das, was ja die Kernaussage ist oder Kernaussagen von Team Topologies, dass Architektur und Organisation zusammenhängen.
Und das habt ihr dann im Prinzip ja auch gebergt.
Das heißt, du hast ja die verschiedenen Schritte, die verschiedenen Wege aufgezeigt.
Wenn man jetzt ganz einfach schauen würde, würde man sagen, Monorepo ist gut, Monorepo ist schlecht.
Und du würdest jetzt sagen, es kommt darauf an, wie die Organisation drumherum aussieht.
Total.
Also total hängt es davon ab, wie die Organisation drumherum aussieht, wie die Software an sich strukturiert ist, ob die Software einem ermöglicht, Deployments auch aus einem Monorepo heraus singulärt zu machen.
Also das ist schon sehr individuell.
Und tatsächlich…
Und tatsächlich ist das auch eines, glaube ich, der heiligen Graal-Themen der letzten Jahre, wo man auch ganz viel im Netz so findet.
Monorepo oder nicht Monorepo.
Und tatsächlich, also für uns war ganz spannend, weil ich tatsächlich, also kurz nachdem ich angefangen habe, war eben der Switch auf Monorepo.
Das wurde halt auch durchaus unterschiedlich betrachtet.
Und mittlerweile stellt sich halt heraus, okay.
Nicht der beste Schuss.
Aber auch das, und da sind wir jetzt so ein bisschen bei dem Only Failures Makers Experts, auch das ist halt wichtig, dass so etwas in einer Organisation A möglich ist und B, dass man sich auch einsteht, dass halt nicht jeder Schuss ist unbedingt ein Treffer, aber wenn man den Schuss nicht macht, wird man es halt auch nicht herausfinden.
Das heißt also an der einen oder anderen Stelle ist es halt auch wichtig, Dinge einfach mal auszuschauen.
Ein paar Meter zu probieren, ein paar Meter zu laufen und zu gucken, wie weit kommt man damit und nicht sofort die Idee oder die Diskussion im Keim erstickt.
Würdest du, wenn ich das so höre, und wir haben ja auch anderweitig Kontakt, wenn ich das so höre, scheint mir Gridscale ein ziemlich modernes Unternehmen zu sein.
Das, was du gerade sagst, das ist ja für mich sehr, sehr modern.
Fehler machen aus Fehlern lernen.
Würdest du Gridscale als ein modernes Unternehmen bezeichnen und ist in dem Zuge dann DevOps?
Vielleicht auch für euch dann ein Selbstläufer?
Das erste Ja, das zweite Nein.
Okay.
Also wir hatten ja im Vorfeld gesagt, ich mache keine Werbung.
Aber tatsächlich muss, also eben mal nicht aus der technischen Brille, sondern erstmal aus der reinen Arbeitgeberbrille und da an der Stelle bin ich halt dann in meiner Rolle Arbeitgeber,
ist es tatsächlich so, dass Gridscale ein sehr modernes Unternehmen ist und dass die Kultur, die wir bei Gridscale haben, was das Machen, das Vorausfordern von Fehlern extrem toll ist.
Also wir ermutigen Mitarbeiter, Dinge auszuprobieren, dass Häufigkeit zitiert ist, dies fail fast.
Learn fast.
Ich finde es, ich mag den Satz gar nicht so sehr, sondern ich finde es einfach wichtig, dass Mitarbeiter in allen Bereichen dafür die Chance haben, Sachen auszuprobieren, eben ein paar Meter zu laufen und es dann tatsächlich auch eben eigentlich kein krasser Fauxpas ist, wenn es halt nicht funktioniert, sondern es einfach, hey, gucken wir uns an, ziehen Learning raus und dann laufen wir weiter.
Und so ist halt unsere Kultur insbesondere, weil wir halt auch ein Plattformbetreiber natürlich sind.
Es ist halt so, es gibt…
In jedem technischen System gibt es Fehler und eine der wichtigen Sachen, die wir einfach bei uns etabliert haben, ist ein sehr sauberer Postmortem-Prozess.
Also das tatsächlich, wenn ein Fehler auf der Plattform passiert, wenn ein Bug mit Customer Impact auftritt, dass wir einen Postmortem machen und dass dieser Postmortem aber sehr sauber gemacht wird mit einer guten Root-Course-Analysis, Stichwort Five Whys, also tatsächlich dies durchgehen und tatsächlich bis auf den Boden der…
Der Ursache kommen, um daraus dann eben das maximale, den maximalen Lerneffekt zu haben.
Und dann ist im Prinzip jeder Incident, den man hat, auf eine gewisse Art und Weise, so sehr er an einer anderen Stelle wehtut, ist er aber sehr viel wert, weil man den Fehler dann nicht nochmal machen muss.
Und das ist natürlich ein sehr hohes Gut, eine solche Organisation zu haben, die ihm das ermöglicht.
Ist deine Frage, auf die ich dann Nein gesagt habe, ist DevOps ein Selbstläufer?
Nein.
Nein.
Und ich kann dir nicht mal genau sagen, warum eigentlich nicht.
Ich stelle jetzt einfach mal die These auf und da könnt ihr gerne mir jetzt widersprechen.
Ich glaube, es wird kaum eine Organisation geben, wo DevOps tatsächlich ein Selbstläufer ist.
Einfach, du sagst ja nicht, oh, wir machen DevOps.
Das ist jetzt wie Mensch ärgerlich nicht.
Jeder kennt, es gibt halt so ein Basistregelset und das ist es.
Sondern du bringst…
Du bringst fünf oder zehn, zwanzig Menschen zusammen und guckst dir an, okay, wir sind hier, wir wollen da hinten hin und wie schaffen wir das?
Und dann hast du auf diesem, wenn du sagst, okay, ich entscheide mich für ein Werkzeug, was ich einsetze, das Werkzeug könnte zum Beispiel sein eine DevOps-Methodik oder ein DevOps-Mindset, sagen wir mal ein DevOps-Mindset,
dann werden die fünf, zehn oder zwanzig Menschen ja immer noch teilweise unterschiedliche Dinge darüber verstehen.
Allein deswegen ist es kein Selbstläufer.
Und das heißt, da hast du dann natürlich das, was ja elementar wichtig ist, damit man überhaupt vorwärtskommt, nämlich eine gewisse Reibung aneinander.
Also Konflikte sind ja wichtig, weil sonst kommt man ja nicht vorwärts.
Es geht ja immer nur darum, wie man diese Konflikte dann auch hat.
Und da ist, glaube ich, selten ein wirklicher Selbstläufer.
Aber ihr könnt mir gerne widersprechen.
Ihr seid die, die an ganz viele Unternehmen reingucken.
Dort sehen.
Naja, wenn wir jetzt hier der Verkäufer wären unserer Trainingsangebote, dann würden wir sagen, bucht ein Training vor uns.
Mit euch ist es ein Selbstläufer?
Ja, ja, nein.
Aber nein, der Podcast, der soll ja wirklich die Wahrheit berichten und soll wirklich authentisch sein.
Also insofern ist das für mich nachvollziehbar.
Also ich sehe das auch.
Es ist auch immer die Frage, was ist DevOps?
Also ich habe so einen Kontakt vor Augen von jemandem, der aus der ganz klassischen Welt kommt.
Und der hat sich jahrelang gegen meine Versuche gesperrt.
Ihm so ein bisschen.
Zu unterstützen mit Agilität, mit DevOps und dann war, hatten wir so ein halbes Jahr Funkstelle und dann haben wir telefoniert und meinte, hey, wir machen jetzt auch DevOps.
Ja, und da habe ich sofort gewusst, die machen nicht DevOps, weil das kann nicht sein, dass dieser Wechsel dann vor einem halben Jahr stattfindet.
Aber auch das, was du sagtest, zurückgezogen.
Du hast ja eben gesagt, es ist kein Selbstläufer.
Und wenn ich DevOps definieren würde oder beschreiben würde, gibt es da verschiedene Punkte.
Das, was du sagtest, Kalms, also Automation, Lean, Management und so weiter.
Also es gibt zwei.
Es gibt so viele Bestandteile, so viele Stellschrauben für DevOps, dass ich sagen würde, ihr beherrscht vielleicht das Thema Automation.
Ihr beherrscht vielleicht auch das Thema Lean.
Aber ein paar andere Dinge beherrscht ihr nicht und müsst da ein bisschen nacharbeiten.
Ja, also wir sind hier ja auch so ein bisschen, um aus dem Nähkästchen zu plaudern.
Und wir, Dirk, also wir haben uns ja letztes Jahr, Anfang letztes Jahr irgendwann kennengelernt.
Können wir ruhig erzählen, warum und wieso, ne?
Ja, wir können uns bei jemandem ganz netten bedanken, der uns zusammengebracht hat.
Genau, ein gemeinsamer Freund hat uns zusammengebracht, weil Dirk das Phoenix Project Online als Spiel mit übersetzt hat.
Oder als Online-Seminar, ist das Online-Seminar?
Online, also eigentlich ist es eine Online-Simulation.
Online-Simulation übersetzt hat und Testläufer ja brauchte, die das mit ihm einmal durchspielen.
Und das habe ich dann mit Dirk und ein paar anderen durchgespielt.
War davon so begeistert, dass ich ja Vorschläge habe, das bei uns mit den technischen Teamleads zu machen.
Und wollen wir Phoenix Project kurz erklären oder kennt der geneigte Hörer von euch das?
Der geneigte Hörer sollte das kennen.
Sag ich jetzt mal so, wir können ja in die Shownotes oder in die Beschreibung einfach einen Link reinpacken, was dahinter steckt.
Es sei denn, du bist so begeistert, dass du es immer noch wieder erzählen willst.
Nein, wir können einfach auf meinen Blog-Post dazu verlinken, den ich auch zu der Simulation geschrieben habe.
Perfekt, machen wir.
Naja, auf jeden Fall habe ich das dann ja mit dir und unseren Teamleads auch nochmal durchgespielt als ein Tages- oder Halbtages-Simulations-Workshop.
Und du wirst dich ja auch daran erinnern, dass da bei uns auch Leute dabei waren, die gesagt haben, puh, wow, das ist ja mal was.
Und tatsächlich hat das hier und dort auch nochmal einfach wirklich, glaube ich, den Blick geschärft.
Beziehungsweise die Blickrichtung verändert oder einen anderen Blickwinkel ermöglicht.
Also Stichwort zum Beispiel, du hast gesagt Automatisierung.
Automatisierung ist klar, da haben wir einen sehr starken Fokus drauf.
Wo wir aber auch tatsächlich hinwandern, ist, dass wir tatsächlich die Möglichkeit haben, x-mal am Tag unseren kompletten Stack im Prinzip zu deployen.
Und so einen kompletten Stack x-mal am Tag deployfähig zu machen.
Das ist halt auch ein Stück Weg.
Und da sind zum Beispiel Sachen, die dann schon in der Praxis wieder auftauchen, wo klar ist, okay, da machen wir gut Wegstrecke.
Aber da ist halt auch noch was.
Ja, okay.
Also ich möchte da eine Sache aufgreifen, die du vorhin gesagt hast, als es ging um die Schwierigkeiten von DevOps.
Ich glaube, dass…
DevOps deswegen kein Selbstläufer ist und deswegen nicht nur sich schwierig anfühlt, sondern auch tatsächlich ehrlich schwierig ist, weil es nicht davor zurückschreckt, sich auch um die menschlichen Seiten dieser ganzen technologischen Entwicklungen zu kümmern, mit denen wir uns befassen.
Es geht eben nicht nur um Monorepos, sondern es geht immer auch um die Leute, die die Monorepos irgendwie benutzen und betreiben.
Und es geht nicht nur um eine CI-Pipeline.
Sondern es geht auch um die Leute, die eine CI-Pipeline benutzen und Feedback von dieser CI-Pipeline bekommen.
Und so weiter.
Ja, richtig.
Das führt mich natürlich, wo du den Fokus nochmal auf die Menschen auch bringst, zu einer Sache, die natürlich auf dieser Wegstrecke…
Also ich bin jetzt seit 2018 bei Gridscale dabei.
Gridscale wurde 2014 gegründet.
2015 Markteintritt.
Das heißt also, da waren vorher schon ein paar Jahre vorher, wo viel passiert ist.
Aber was natürlich…
Jetzt haben wir die Startup-Phase ja auch gut hinter uns gelassen.
Aber was natürlich schon da ist, oder was natürlich auch in jedem Startup passiert, ist, dass du ja die Leser von The Phoenix Project kennst.
Die Rolle des Brand.
Also eben…
Also eine wichtige Sache, die in den Lebenszyklus eines Startups kommt, ist, dass du deine Brands identifizierst.
Oder deinen Brand.
Wer ist nochmal ein Brand?
Ein Brand ist die Person, zu der alle hingehen, wenn sie etwas wollen, wenn sie ein Problem haben, wenn ein Kunde nicht klarkommt.
Egal was.
Es gibt genau die eine Person.
Und die wird es lösen.
Und nur die kann es lösen.
Weil die weiß alles und kann alles.
Die weiß alles.
Die kann alles.
Und du kannst sicher sein.
Nach spätestens 24 Monaten…
Nach spätestens 24 Monaten ist Brand durch.
Wenn er überhaupt die 24 Monate dann noch schafft.
Das heißt also, in jedem Lebenszyklus eines Startups oder eines Technologie-Startups wirst du das haben.
Und was natürlich…
Es gibt da noch eine andere Formulierung aus einem anderen sehr guten Buch.
Das ist das Inelegent Puzzle Systems of Engineering Management von Will Larsen.
Sollten wir auch in die Show-Notes packen.
Exzellentes Buch.
Das hat ein Kapitel.
Das heißt Kill Your Hero Programmer.
Und da geht es halt auch genau darum, dass es wichtig ist, dass man auf dieser Reise,
wenn man ein skalierendes, wachsendes Unternehmen aufbauen will, dass es wichtig ist, dass du
verschiedene Leute in ihrer Entwicklung förderst.
Und aber auch sicherstellst, dass du eben nicht nur diesen ein oder zwei Hero Programmer
hast.
Weil das im Prinzip zwar an der einen Stelle sehr viel Geschwindigkeit erzeugt, die Organisation
drumherum aber lähmt.
Weil wenn der eine Hero Programmer komplett voranprescht, dann hat der Rest der Organisation
drumherum überhaupt keine Chance hinterherzukommen oder gemeinsam an einer Architektur zu arbeiten
etc.
pp.
Und genau.
Also das sind halt schon Herausforderungen, die ich denke mal jedes Startup kennen wird,
die dann irgendwann Geschwindigkeit aufnehmen.
Weil es natürlich, es ist extrem verlockend, jemanden wie Brent immer wieder anzusprechen,
weil das ist ja die instantane Gratifikation für dich, wenn du weißt, ich gehe dahin,
der löst mein Problem.
Aber es ist halt sehr kurzfristig dann gedacht.
Aber nicht desto weniger ist es verlockend, gerade wenn du im Prinzip Dinge sehr schnell
erreichen willst.
Und da ist es wichtig, dass man, glaube ich, am gewissen Punkt erkennt, okay, jetzt sind
wir an dem Punkt.
Wo es wichtiger ist, mittelfristiger und nicht mehr diesen kurzfristigen Blick zu haben
und dann zu schauen, dass man eben Brent identifiziert und ermöglicht, in eine andere
Rolle zu wechseln und das Wissen dann tatsächlich weiter zu verteilen.
Okay.
Wir haben ja im Titel Team Topologies drin.
Jetzt hast du viele tolle Sachen erzählt, die aber nicht alle sich auf Team Topologies
beziehen.
Wenn ich es im Prinzip so einschätze.
Können wir nochmal ein bisschen auf ein paar Begriffe eingehen?
Ich habe zum Beispiel vorhin was von dem Reverse Conveys Manoeuvre erzählt.
Ich glaube, das wäre nochmal interessant, was du da bei Gridscale erlebt hast dazu.
Ja.
Tatsächlich, als ich mich näher mit der Thematik Conveys Law, Reverse Conveys oder Inverse
Conveys Manoeuvre beschäftige, habe ich dann tatsächlich mich hier mal an den Schreibtisch
gesetzt und mich dann mit ein paar Kollegen dazu unterhalten und tatsächlich angefangen,
unsere mittlerweile ja tatsächlich auch verhältnismäßig komplexe Architektur einfach tatsächlich mal
aufzumalen.
Und der erste Schritt, den ich tatsächlich gemacht habe, war, dass ich von den technischen
Teams, die wir haben, jedes Team gebeten habe.
Dass sie mal aus ihrer Sicht die Architektur aufmalen.
Also tatsächlich, also wir haben ja im Prinzip einen, kann ich auch kurz jetzt einmal darauf
eingehen, damit man es so ein bisschen greifbar hat.
Also wir haben eben diese Core Services, die ich vorhin schon genannt habe, die APIs bereitstellen.
Wir haben die Smart Services, die unsere Plattformdienste bereitstellen.
Dann haben wir im Prinzip eine Middleware, wo sehr viel Billing etc.
pp.
läuft.
Und dann haben wir ein Frontend-Team.
Und das Frontend-Team bedient im Prinzip mit unseren Panels die APIs, die von anderen bereitgestellt
werden.
Und neben diesen Teams haben wir dann auch noch zwei weitere Teams.
Im Prinzip ein Team, was sich um Operations, Data Center etc.
kümmert.
Und ein Team, Team Wolf, da kann ich später noch so ein bisschen was zu erzählen.
Das ist aber auch ein technisches Team, was halt auch Entwicklungsarbeit leistet.
Ich habe jedes Team gebeten, die Architektur aufzumalen.
Und das war tatsächlich der erste Schritt, wie ich mich dem genähert habe, weil darüber
überhaupt mal sichtbar wurde, wie eigentlich ein Frontend-Team unsere Architektur sieht
versus wie jemand, der bei uns in den Core Services arbeitet, also dafür zuständig ist,
Provisionierung von virtuellen Maschinen und ähnliches durchzuführen.
Wie der auf die Architektur blickt.
Und das haben wir dann tatsächlich mal gegeneinander gehalten und auch miteinander abgeglichen.
Und daraus habe ich dann tatsächlich erst einmal angefangen, über die Teamstruktur nachzudenken
und dann zu identifizieren, was für Teamarten haben wir eigentlich.
Also Team Topologies geht ja erstmal von vier Teamarten aus.
Wir haben im Prinzip die Streamaligned Teams.
Wir haben die Platform Teams.
Wir haben Complicated Subsystem Teams.
Und die sogenannten Enabling Teams.
Das sind ja die vier Teamarten, die meine ich auch schon in einer der letzten Folgen hervorgestellt habe.
Und dann bin ich beigegangen und habe halt erstmal geschaut, okay, wo fällt es mir einfach,
das tatsächlich zuzubehalten, also tatsächlich so ein Label ranzukleben.
Also ist das Team Streamaligned oder nicht?
Und für mich war es der erste Schritt,
war der erste Indikator, oh, da muss man näher hingucken, wo es mir nicht leicht fiel.
Also niemand, wo ich auf ein Team geblickt habe und gefragt habe, okay, Streamaligned ist es nicht.
Platform, ja, wäre schön, aber auch nicht?
Okay, aber was, Complicated Subsystem Team?
Nee, auch nicht.
Und da war dann klar, okay, da muss man dann vielleicht mal genauer schauen.
Und das war dann tatsächlich an der Stelle, wo, ja, ich bezeichne ja gerne Team Topologies tatsächlich als Framework oder als Werkzeug,
wo tatsächlich dann das Team Topologies eben wie so ein Werkzeugkasten zum Einsatz kommt,
um damit eher einfach dann auch erstmal zu helfen, Sachen sichtbarer zu machen und greifbar zu machen,
dass man da eventuell weiter reinschaut.
Und ein Verständnis dafür zu entwickeln.
Genau.
Du hast ja im Prinzip genau diese vier Teamarten genommen und hast geguckt, ist das so eins?
Also ist das Team eins dieser vier Teamarten?
Plus natürlich, dass das Team Topologies ja auch ein Verständnis davon hat, wie welche Teams miteinander interagieren, also zusammenarbeiten.
Und wenn man das dann gegeneinander hält und feststellt, hm, das passt aber eventuell gar nicht zu dem,
was in der Realität stattfindet oder wie die Realität aussieht, ist das auch natürlich ein Indikator,
dass man da einfach mal näher reinschaut.
Ja, aber das ist, da sagst du so im Vorbeigehen ganz irgendwie lässig, eine ganz, ganz wichtige Sache.
Nämlich etwas, was glaube ich viel zu häufig ausbleibt, dass die Leute dann, so wie du das jetzt gemacht hast,
sich irgendwie so ihre Teams zurechtlegen und sagen, ja, das da, ist das jetzt ein Streamer-Line-Team oder nicht oder so.
Und es gibt ganz viele, die dann einfach, glaube ich, dabei verharren und sagen so, das muss jetzt irgendwie in dieses Schema reingepresst werden.
Das ist das Team, das ich habe, wird schon Streamer-Line sein.
Aber was du gemacht hast, ist eben genau das ganz Tolle dabei.
Nämlich zu fragen so, Moment, wenn mir das schwerfällt, dann sagt mir das was.
Dann, wenn der Schuh drückt, dann ist es wohl nicht der Richtige.
Und das ist nicht zu unterschätzen, glaube ich.
Genau, und ich hatte ja gerade schon eins der Teams erwähnt, wo ich sagte, da kann ich dann nochmal was zu sagen.
Das Team Wolf.
Das Team Wolf, als wir das ursprünglich aufgemacht haben, das Team, also das war eine,
es entsprang einer Diskussion, die ich mit einem Freund aus der Schweiz hatte.
Und wir saßen in einem Hotel in Berlin zusammen und haben uns so ein bisschen überlegt,
Und wir saßen in einem Hotel in Berlin zusammen und haben uns so ein bisschen überlegt,
über eben Unternehmensorganisation, Struktur etc. pp. unterhalten.
über eben Unternehmensorganisation, Struktur etc. pp. unterhalten.
Und das Resümee daraus war, dass wir im Prinzip beide sagten, eigentlich braucht jedes technische Unternehmen,
braucht ein Team Wolf.
Ein Team Wolf, benannt nach Vincent Wolf aus PathFiction, dem Problemlöser.
Wo klar ist, okay, dieses Team, das löst einfach nur Probleme.
Und wenn man zum Beispiel ein Unternehmen hat, was Software herstellt,
Und wenn man zum Beispiel ein Unternehmen hat, was Software herstellt,
dann muss man in dieser Organisation immer wieder Aufgaben haben,
dann muss man in dieser Organisation immer wieder Aufgaben haben,
die mit dem Kernprodukt überhaupt nichts zu tun haben.
Scrape mir mal bitte die Daten von diesen Webseiten,
oder transformiere mir diese Daten von A nach B,
oder schau doch mal, ob du nicht in der Datenbank ein paar QBs machen kannst,
dass wir ein paar Analysen fahren können.
Also Aufgaben, die zwar in den Kosmos des Unternehmens passen,
die aber eben nicht zur Kernproduktentwicklung gehören.
die aber eben nicht zur Kernproduktentwicklung gehören.
Und was ja dann passiert ist, dass du zu einem Produktentwickler gehst
und sagst, hey, du machst ja eh gerade an der Datenbank rum,
kannst du mir auch noch mal die drei Query schreiben?
Oder kannst du mir noch mal das analysieren?
Oh, du kannst die Programmiersprache XY,
Scrape mir doch mal die Webseite da.
Und damit findet aber ja eine Defokussierung statt.
Das heißt also, im Prinzip Entwickler, die am Kernprodukt arbeiten, werden defokussiert.
Und das ist ja eines der Sachen, die dafür Sorge tragen,
dass Entwicklungsprozesse dann langsamer werden,
weil Leute ständig defokussiert werden.
Weil Leute ständig defokussiert werden.
Und ein solches Problemlöserteam, die Idee ist,
dass dabei dann eigentlich dort Sachen landen,
die sonst andere defokussieren würden.
Und das ist das Team Wolf.
Damit sind wir dann auch losgelaufen.
Tatsächlich erfordert natürlich so ein Team Wolf,
wie es da angedacht war, relativ viel Disziplin.
Nämlich, dass man dann nicht anfängt,
oh, wir haben da einen Entwickler,
lass uns die auch mal für Produktentwicklung auch benutzen.
Und das ist natürlich was,
wo wir,
wo man dann auch sich selber gegenüber,
glaube ich, an der einen oder anderen Stelle dann ehrlich sein muss.
Wo man tatsächlich dann durchaus aus dem,
aus dem im Alltag dann eventuell,
wenn man nicht ganz so konsequent ist,
durchaus da dann,
durchaus dann auch mal reingeht
und daraus Produktentwicklung heraus machen lässt.
Oder also bei uns ist zum Beispiel das Team Wolf,
sind die, die unser Ecosystem bauen.
Also Terraform Provider oder unser Go SDK
und andere Libraries werden halt dort gebaut.
Das sind wichtige Teile,
aber halt eben nicht Kernbestandteil der Produktentwicklung.
Ja, das finde ich spannend.
Das ist, das ist auch so ein Team,
von dem ich das Gefühl habe,
es sollte existieren,
aber das ist so ein Kunstgriff,
den glaube ich viele,
den Schritt gehen viele glaube ich nicht.
Sondern sie verharren dann in dem,
was du beschrieben hast.
Ja, genau.
Und jetzt nehmen wir mal,
jetzt nehmen wir nochmal Team Topologies
und jetzt kannst du, Luca,
mir mal sagen,
wo bei den Team Topologies passt dieses Team rein?
Es ist nicht Steam,
es ist nicht Stream-aligned,
es ist keine Plattform,
also es baut ja keine,
es ist ja nicht X-as-a-Service,
außer vielleicht Human Resource X-as-a-Service,
also Human Resource X-as-a-Service.
Es ist auch kein Complicated SAP System Team.
Und wenn ich ehrlich bin,
nach der strengen Definition ist es auch kein Enabling Team.
Das ist jetzt insofern gemein,
als ich dir eigentlich diese Frage stellen wollte,
aber sei es drum.
Ich hatte die extra mitgebracht.
Ich finde das gut.
Jetzt bettelt ihr euch mal hier.
Genau.
Nee, aber ich meine,
die Frage ist einerseits spannend,
oder sie ist eigentlich auf jeden Fall spannend,
sie ist nur aus zwei verschiedenen Perspektiven spannend.
Nämlich entweder man kann sagen,
okay, wo finden wir dieses Team jetzt wieder?
Innerhalb des Systems,
das Team Topologies aufspannt.
Und dann würde ich sagen,
es ist tatsächlich noch am ehesten
irgendwie ein Enabling Team,
das Unterstützungsleistungen bietet,
temporärer Natur für andere.
Oder man kann den Spieß umdrehen und kann sagen,
alle Modelle sind falsch, aber manche sind nützlich.
Jetzt haben wir einfach eine Grenze des Modells
Team Topologies gefunden.
An der Stelle verliert es vielleicht
so ein bisschen seine Tragfähigkeit.
Also das ist ja tatsächlich,
also das wäre eh immer das,
wozu ich tendieren würde,
weil ich bin ja nicht so der Fan von Dogmatismus.
Das heißt also,
ich finde es ja super,
Team Topologies als Werkzeug einzusetzen,
habe aber nicht den Anspruch,
dass ich meine komplette Welt
nach Team Topologies ausrichte.
Das an das Enabling hatte ich halt auch schon gesagt,
weil im Prinzip ist,
Enabled ist ja die anderen Fokus zu wahren.
Oder es baut halt tatsächlich Sachen,
die in anderen Teams wiederum eingesetzt werden.
Von daher ist halt durchaus,
aber das war so eine der Sachen,
die ich da in der Überlegung ganz spannend fand,
wie man das eigentlich da,
da sich darin wiederfinden würde.
Ja, aber das ist mir so wichtig,
dass ich da tatsächlich nochmal drauf eingehen möchte,
weil mir ging das nämlich auch so,
als ich Team Topologies gelesen habe,
habe ich auch gesagt, also dürfen die das?
Braucht man wirklich nur diese vier Team-Geschmacksrichtungen?
Das geht doch nicht und so.
Ich kann mir da noch andere auch noch ausdenken
und dann bin ich halt auch drauf gekommen,
ist doch total wurscht.
Es geht ja nur darum,
dass man ein Werkzeug hat,
an dem man sich orientieren kann.
Ich sehe Team Topologies,
ich sehe Team Topologies
und diese vier Topologien oder sowas
mittlerweile nicht mehr als diskrete Orte oder sowas,
sondern das ist für mich ein Koordinatensystem.
Und da kann ich sagen,
dieses Team hat,
das ist eher so in der linken unteren Ecke,
was auch immer sich da befindet,
keine Ahnung.
Und insofern,
mei, wenn du möchtest,
nenn dein Team Wolf ein Enabling-Team
und wenn du es nicht möchtest,
ist auch okay,
aber du hast verstanden,
dass es etwas ist,
was ungefähr so aussieht,
wie ein Enabling-Team,
aber vielleicht nicht gemäß der reinen Lehre.
Und jetzt kannst du die Schlüsse daraus ziehen,
die du daraus ziehen möchtest.
Okay.
Ich würde gerne noch einen Punkt ansprechen.
Ich weiß,
dass Felix ein sehr spezielles Verhältnis
zu Spotify,
zum Spotify-Modell hat.
Kannst du das Spotify-Modell
vielleicht doch mal zu Team Topologies mappen?
Das ist jetzt insofern wirklich lustig,
als dass ich tatsächlich noch eine andere Sache mitgebracht habe,
die auf das Spotify-Modell anspricht.
Tatsächlich muss man,
finde ich,
hat ein spezielles Verhältnis zum Spotify-Modell.
Ich finde,
da muss man ein bisschen mehr Kontext geben.
Klar,
das war ich doch erwartet.
Also tatsächlich finde ich es einfach,
findet man ja an der einen oder anderen Stelle
immer wieder die Referenz auf Spotify-Modell.
Und ich pointiere das jetzt mal,
dass das Spotify-Modell der Heilsbringer überhaupt ist.
Und da wird,
das ist halt maximal kurz gedacht,
weil immer vergessen wird,
dass man never ever eine Sache von einer Organisation
auf die andere blind kopieren kann.
Also du kannst halt einfach kein Copy-Paste
von Organisationsentwicklung machen.
Das funktioniert nicht.
Und ich finde es deswegen auch schwierig,
ich finde Copy-Paste an der Stelle schwierig,
auch mit Begrifflichkeiten,
weil das automatisch,
aber das ist jetzt ein sehr persönlicher Gedanke an der Stelle,
das automatisch eine gewisse Schubladenerwartungshaltung
mit sich bringt.
Und ich finde es wichtig,
dass man nicht einfach nur sagt,
oh ja,
Tribes und Guilds und Squads,
sondern dass man sich tatsächlich überlegt,
was wollen wir eigentlich bezwecken
und was ist das Ziel?
Und sich dann das überlegt.
So, das einfach nur so als Kontext dazu.
Also es ist nicht so,
dass ich glaube,
dass das, was Spotify da gemacht hat, Käse ist,
sondern ich glaube,
für Spotify ist das ein sicherlich sehr gutes Modell.
Interessant finde ich tatsächlich die,
wenn man mal so ein bisschen weiterguckt,
was da doch für kontroverse Dinge,
also Berichterstattung und Blogposts
und Erfahrungsposts so gibt,
weil es halt auch nicht,
also es ist ja nur eine Momentanaufnahme gewesen
und auch Spotify hat sich weiterentwickelt
und auch das muss man da immer bedenken.
Und ich meine,
wenn man sich anguckt,
wie eine Organisation wie Spotify wächst,
da hast du ja im Prinzip konstant einfach Änderungen.
Das heißt,
da kannst du gar nicht sagen,
das ist das Modell
und das funktioniert auf x Jahre.
Tatsächlich zu Team Topologies.
Es ist ja so,
dass wenn man sich das Spotify-Modell anschaut
und sowas wie den Tribe oder die Guild hat,
was ja im Prinzip fachliche Zusammenschlüsse sind,
dann habe ich zum Beispiel mir die Frage gestellt,
kann ein Tribe ein Complicated Subsystem Team darstellen?
Also kann man in seiner Organisation,
wenn man,
wenn man,
man hat,
nehmen wir mal einfach mal an,
du hast fünf Stream-Aligned Teams
und über diese fünf Stream-Aligned Teams
könntest du ja im Prinzip etwas wie ein Tribe bauen,
nämlich aus jedem dieser fünf Stream-Aligned Teams
nimmst du die Leute,
die sich mit den Datenbank-Servern beschäftigen,
packst die in ein Tribe
und wäre das dann ein Complicated Subsystem Team?
Das ist was,
wo ich tatsächlich im Augenblick auch gedanklich noch hänge.
Weil man nämlich sonst durchaus sagen kann,
wenn sowas funktioniert und auch tatsächlich gut funktioniert,
dass du halt tatsächlich sagen kannst,
okay, hey, die ganzen Leute,
die sich sonst um die Datenbank-Server kümmern,
die wollen wir ja nicht alle,
wir wollen ja kein Datenbank-Administratoren-Team,
sondern wir wollen halt die Stream-Aligned Teams haben,
wo zum Beispiel überall Leute drin sind,
die von Datenbanken Ahnung haben,
aber die können dann halt eben diesen Interessens,
also diesen fachlichen Interessensverbund
nämlich in Datenbank-Server als Tribe bilden,
was ein Complicated Subsystem Team wäre.
War das okay?
Konnte man dem folgen?
Also ich ja.
Ich konnte ihm folgen,
aber ich konnte ihm nicht zustimmen.
Deswegen habe ich so eine Frage mitgebracht.
Also bei Ihnen.
Okay.
Genau.
Weil sagen wir es mal so.
Ich glaube,
das war nicht das,
was Spotify sich unter einem Tribe vorgestellt hat.
Was hat sich Spotify unter einem Tribe vorgestellt?
Sondern die,
ich sage jetzt mal,
die kleinste Organisationseinheit,
in der Leute aufgehängt sind,
die heißt dann bei Spotify ein Squad.
Das ist dann halt irgendwie einfach nur ein Team.
So zock.
Zum Beispiel ein Complicated Subsystem Team oder sowas.
Genau.
Und Leute mit derselben Funktion
innerhalb verschiedener Squads
sind in einem Tribe drin.
Genau.
Das heißt,
ein Tribe ist sozusagen per Definition
orthogonal zu einem Squad.
Genau.
Stopp.
Ja.
Kann es sein,
dass ihr Tribe falsch interpretiert?
Für mich sind das die Chapter.
Oder ich habe es falsch verstanden?
Du hast recht.
Nein, nein, nein.
Du hast recht.
Ich bringe die auch immer übers Kreuz.
Okay.
Also die Squads sind im Tribe
und dann habe ich die Chapter,
die entsprechend so orthogonal darüber gehen.
Genau.
Dirk hat völlig recht.
Also lass es uns noch mal kurz zusammenfassen,
damit wir auch unsere Hörer
maximal verstehen können.
Ja.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Genau.
Sehr gut.
Genau.
Also,
Squads sind,
ne,
sind kleine Einheiten,
sagen wir mal,
nicht mehr als zehn Leute,
einfach nur ein anderes Wort für Team.
Wenn du die zu größeren Organisationseinheiten
zusammengefasst,
zusammenfassen willst,
heißen die bei Spotify Tribes.
Ja.
Richtig.
Ja.
Und du hast ein, was weiß denn ich, Python-Entwickler-Chapter.
Und was dir halt sonst noch so einfällt.
Und insofern kann ich mir schon vorstellen,
dass es in einem Complicated-Subsystem-Team
von Python-Entwicklern wimmelt aus irgendeinem Grund.
Aber das ist halt trotzdem kein Chapter.
Ein Chapter soll ja eine Möglichkeit schaffen,
damit zwischen verschiedenen Squads ein Austausch stattfinden kann.
Dass die sich abstimmen können, dass die Wissen teilen können und so fort.
Dass die zum Beispiel gemeinsam definieren,
wie aber gewisse Sachen in der Datenbank-Server-Architektur stattfinden.
Zum Beispiel, ja.
Genau.
Sie stimmen sich darüber ab,
wie gewisse Sachen in der Datenbank-Server-Architektur stattfinden.
Und sind auch die, die ja per se dann die meiste Ahnung
von den Datenbanken im Unternehmen haben.
Da wäre halt die Frage, ob das nicht dann,
wie automatisch damit dann auch die Ohner von dem Complicated-Subsystem
der Datenbank-Server sind.
Nee, sondern die Idee hinter einem Chapter,
so wie ich das Spotify-Modell verstehe.
Ja, ich meine, wir können es ja verstehen.
Genau.
Die Frage ist aber, ob man, wenn man Streamalign-Teams hat,
ob man eben über das Identifizieren von verschiedenen Fachspezifika,
eben zum Beispiel Datenbank-Server-Menschen,
dann tatsächlich dort eine Gruppierung schaffen kann,
die in einem zusätzlich sozusagen über diesen Interessensverbund
auch die Rolle eines Complicated-Subsystem-Teams erfüllen.
Ja, das könnte sein.
Aber die Idee hinter einem Chapter-Virum ist ja,
das ist eben genau kein separates Team.
Das ist kein Squad.
Sondern die sind weiterhin ganz klar ihrem Squad zugeordnet.
Die sind dem verpflichtet.
Die arbeiten für dieses Squad.
Und haben halt, und reden ab und zu mal mit ihren Kollegen.
So muss man es sehen.
Das ist kein Team.
Ich stimme dir zu, das ist das, was häufig in der Praxis passiert.
Das sind die berühmten Shadow-Org-Charts.
Dass du plötzlich geheime Teams hast,
die sich da irgendwie gebildet haben aus Notwendigkeiten heraus.
Genau.
Und jetzt haben wir aber die Chance,
dass wir eben diesen Shadow-Org-Chart verlassen
und sagen, wir machen das nochmal an einem anderen Beispiel.
Wir nehmen jetzt nicht mal die Datenbank-Server,
sondern wir nehmen das Thema Open Source.
Das heißt also, du hast,
du hast in deinem Unternehmen wiederum fünf Stream-aligned-Teams
oder zehn oder was auch immer und im Prinzip ist es so,
dass aus jedem dieser Teams potenziell Sachen rausfallen,
die entweder für Open Source fähig werden, würdig werden,
die mit der Open Source-Community agieren oder wie auch immer.
Du hast aber nur eine relativ kleine Zahl an Leuten,
die tatsächlich den Erfahrungsschatz haben,
wie man mit einer Open Source-Community interagiert.
Und die hast du aber verteilt auf deine,
deine Stream-aligned-Teams und die Idee ist aber ja,
dass du aus, aus dem Unternehmen heraus in einer Art und Weise
mit der Community interagierst und nicht auf zehn verschiedene Arten und Weisen,
je nachdem wie das und dass du darüber, dass du im Prinzip schaffst,
Stream-aligned-Team übergreifend, weil du in jedem deiner Teams welche hast,
die sich dann aber wiederum als ein Verbund sehen,
um sich daran auszutauschen.
Und wie, die, die Frage ist komplizierte Subsystem-Team ist der falsche Begriff,
aber wie nennt man denn diesen Zusammenschluss?
Um eben nicht diesen Shadow-Org-Chart zu haben und zu sagen,
das ist halt irgendwas, was sich implizit bildet, sondern um es explizit zu machen.
Also wir haben es halt bei uns Cross-Team-Efforts genannt.
Also wir haben halt zum Beispiel einen API-Cross-Team,
wo halt aus jedem Team, was APIs baut, Leute drin sind,
die sich darum kümmern, dass wir halt einen Standard-Weg haben,
wie bei uns APIs auszusehen.
Ja.
Damit alle APIs, die wir haben, dem gleichen Paradigmen folgen.
Wir haben einen CI-CD-Cross-Team.
Wir haben es bei uns halt Cross-Team genannt.
Dass wir einfach Cross-Team-Effort sagen, wo im Prinzip jedes Team die Leute hinschickt,
die in dem Teil wirklich Clou haben, damit sich dort dann alle gut austauschen
und die Ergebnisse wieder in die Teams zurückfließen können,
damit dieser Informationsfluss gewährleistet ist.
Damit eben nicht du pro Team, jeder macht so seine CI-Pipeline,
und dann hast du am Ende irgendwie zehn unterschiedliche Art und Weisen,
wie im Unternehmen CI-CD-Pipelines gebaut werden.
Was ja im Prinzip, das will ja keiner.
Das ist ja dumm.
Habe ich dich jetzt komplett verwirrt, Luca?
Nein.
Aber ich bin mir momentan noch so ein bisschen unschlüssig,
wie da die richtige Antwort aussieht,
weil wir jetzt dann in irgendwelche ganz vertrackten Nuancen reinwandern.
Und ich glaube, wir verwirren dann unsere Hörer zu sehr.
Das ist die Gefahr, die ich sehe.
Ja, aber tatsächlich ist, glaube ich,
und das ist an der Stelle vielleicht die Kurve zu kriegen,
ich glaube, man wird irgendwo immer diese Nuancen dann haben.
Und ich glaube, es ist tatsächlich gut, wenn man,
oder das wäre jetzt so, wenn man tatsächlich mal so ein bisschen schaut,
was man so machen kann.
Ich mag es halt zum Beispiel, über den Tellerrand zu gucken
und hier und dort zu gucken, aber halt nicht blind zu kopieren,
sondern tatsächlich dann einfach zu gucken,
okay, was von dem, was man woanders findet,
kann uns tatsächlich helfen, um es dann mit Bedacht rüberzuholen
und zu adaptieren.
Also eher ein, nicht copy-paste, sondern copy-adaptieren.
Also ich sage immer, kapieren und nicht kopieren.
Ja.
Aber ich habe noch eine gute Idee.
Wir können mit dieser Frage, die wir ja jetzt nicht endgültig gelöst haben,
können wir eine Brücke bauen,
zu Folge 50.
Wir haben jetzt halt die Folge 46.
In der Folge 42 und 43 haben Luca und ich so die theoretischen Grundlagen gelegt.
Jetzt haben wir den Felix mit der Praxis.
Und in der Folge 50 haben wir Matthew Skelton zu Gast,
der einer der beiden Autoren ist.
Also insofern, Luca, Felix, schreibt euch die Frage auf.
Dann können wir die Matthew stellen und an alle Hörer da draußen,
die vielleicht auch Fragen haben zu Team Topologies,
gerne an uns.
Dann können wir die in der Folge 50,
das ist zumindest jetzt der Plan,
das wäre der August,
mit Matthew direkt klären.
Und insofern freuen wir uns,
dass der Matthew zu Gast sein wird.
Und wenn ich jetzt auf die Uhr blicke,
dann sage ich mal so,
wir haben einen Zeitpunkt erreicht,
der zu einem Abgesang führen könnte.
Es sei denn, ihr habt noch zwei Punkte,
also ihr zwei habt noch Punkte, die ihr ansprechen wollt.
Viel zu viele.
Viel zu viele.
Lass uns lieber die Kurve kriegen.
Okay, na gut.
Felix, hast du noch irgendwas?
Nö, aber wir könnten noch.
Also ich habe familyfrei heute Abend.
Ja, also für die geneigten Zuhörer,
wir haben es jetzt hier viertel vor zehn.
Also wir drei haben keinen anderen Termin bekommen,
als hier wirklich spät abends das zu machen.
Ich habe nicht familyfrei, Felix.
Ich muss ja auch ehrlicherweise zugeben,
dass ihr euch nach meinem Terminplan gerichtet habt.
Von daher bin ich auch sehr dankbar,
dass wir überhaupt einen solchen Abendslot machen konnten.
Ja, ja, okay.
Aber es hat sich nicht gelohnt, oder?
Das denke ich schon, ja.
Also insofern, wir haben das zum dritten Mal,
das Thema Team Topologies.
Wir kriegen es dieses Jahr zum vierten Mal.
Also insofern wird das das Team Topologies Jahr
für uns an der Stelle.
Also dann die Bitte, die Aufforderung,
auch an die Zuhörer, Fragen zu stellen zu Team Topologies.
Die können wir gerne mit Messius Gelten dann klären im August.
Ich wollte noch auf einen anderen Punkt hinweisen.
Und zwar auf zwei Punkte eigentlich.
Erstens, nochmals Ergänzung zu Team Topologies.
Wir haben von zwei Hörern des Podcasts die Frage bekommen,
ob wir auch Schulungen haben.
Also ob man da irgendwo eine Schulung buchen kann
zu Team Topologies.
Und wir haben dazu noch keine Idee,
noch kein fertiges Webinar.
Oder wie auch immer.
Aber wenn weiterer Bedarf da ist,
und wenn ihr uns schreibt,
was ihr so in der Schulung haben wolltet,
dann gerne raus damit.
Dass wir einfach auch sehen,
vielleicht gibt es ja am Markt einen gewissen Bedarf,
eine wie auch immer geartete Team Topologies Schulung
oder so ein Webinar oder einen Workshop zu initiieren,
dass man so etwas macht.
Und…
Ich würde dir da…
Ja, bitte.
Bevor du weiterredest,
ich möchte da nochmal ein bisschen konkreter werden.
Hörer, Freunde von Hörern, kommt auf uns zu.
Wir können euch sowas machen.
Wir können euch sowas machen.
Sehr schön.
Das ist nicht nur so hypothetisch,
sondern ich habe total Bock,
da draußen eine Schulung zu machen.
Und wenn mir jemand eine Ausrede liefert,
dann mache ich die auf der Stelle.
Gut.
Also ich würde sie nicht auf der Stelle machen.
Ich würde sie vorbereiten.
Aber das kriegen wir ja hin, Lukas.
Also nicht bis übermorgen.
Aber…
Nee, nee.
Das ist fest auf dem Terminplan.
Ich möchte das ganz gerne machen.
Und insofern,
wenn mir jemand einen Vorwand liefert,
dann bin ich ihm höchst dankbar.
Sehr schön.
Und da kommt der zweite Punkt.
Jetzt kommt ein kleiner Werbeblock.
Aber ich glaube, dass der genehmigt ist.
Wir haben ja auch gesagt,
mit Felix möglichst wenig Werbung.
Aber es kommt ja von sich aus heraus.
Es gibt den DevOps Mastermind Club.
Und die beiden, Luca und Felix,
sind in dem nächsten DevOps Mastermind Club.
Auch da packen wir die URL,
die Webseite dazu rein.
Der Marketing…
Ja, der Marketing.
Der DevOps Mastermind Club.
Startet wieder am 8.
Juli.
8.
Juli startet der.
Und wer Informationen haben will,
wie gesagt, packen wir rein.
Luca wird der Überraschungsgast sein.
Jetzt ist es keine Überraschung mehr,
aber…
Ihr habt es gehört.
Am Ende vom Mastermind Club
gibt es immer so eine Überraschung
oder einen Gast,
der als Überraschung da ist,
zu einem Thema,
was ich mit dem Gast vorbereite.
Und einer der Mitglieder im DevOps Mastermind Club
ist Felix.
Also, wem Felix mit seiner Art
und mit seiner Fachkompetenz sehr gefallen hat,
der kann ihn gerne wiedersehen.
Er muss einfach nur in den Mastermind Club kommen.
Wie gesagt,
Hinweis dazu,
Webseite dazu,
packen wir auch in die Shownotes
beziehungsweise in die Beschreibung.
Gut.
Jetzt haben wir über eine Stunde.
Gibt es noch irgendwas,
was ihr beide sagen wollt?
Ansonsten würde ich sagen,
vielen Dank fürs Zuhören.
Vielen Dank, Luca,
für die Begleitung
und vor allem dir, Felix,
vielen Dank,
dass du uns hier
eine Stunde deiner Zeit geschenkt hast.
Weil auch wenn du Family,
Freie hast,
es gibt ja noch andere Dinge,
mit denen man machen könnte.
Also vielen Dank an dich,
dass du uns hier ein bisschen
bei Gridscale hast reingucken lassen.
Vielen Dank für die Einladung.
Hat mich sehr gefreut.