Webinar – Data, Explored #7 – Neue Perspektiven auf Teamtopologien

Zunächst einmal ein herzliches Willkommen, Manuel Pais, bei „Data Explored“. Vielen Dank. Vielen Dank.

Es ist mir eine Ehre, Sie hier zu haben. Den Zuhörern und Zuschauern kann ich mitteilen, dass Sie ein sehr erfahrener Keynote-Speaker sind. Sie sind Mitbegründer des Konzepts der Team-Topologien, das sowohl als Buch als auch als Akademie existiert.

Sie sind also offensichtlich auch Mitautor des „Platform Manifesto“, das Sie ebenfalls verfasst haben, und Sie sind Fast-Flow-Vordenker. Und Sie sprechen Portugiesisch. Ach so – das tue ich zwar, aber nicht in diesem Webinar.

Nein. Ich wollte etwas auf Portugiesisch sagen, aber ich kann es nicht. Tut mir leid.

Aber – das ist schon in Ordnung … es ist mir eine große Freude, Sie hier zu haben, Manuel Pais. Ich habe Ihre Arbeit sehr genossen und Sie aufmerksam verfolgt.

Und wir haben dieses Gespräch vereinbart, um über die zweite Auflage Ihres Buches „Team Topologies“ zu sprechen. Und ich weiß, dass ich gerade meine Kopfhörer aufhabe, daher bin ich mir nicht sicher, ob ich … Aber ich habe sowohl die erste als auch die zweite Auflage – schön … denn ich habe die …

Ja. Ich habe mir mittlerweile angewöhnt, Erstausgaben der Bücher, die ich in der zweiten Auflage kaufe, nicht wegzuwerfen, weil ich manchmal Notizen mache und nachdenke und irgendwie den Überblick verliere, wenn ich nicht zurückblättern und das wiederfinden kann. Ich weiß, ich bin ein Nerd, aber egal, so bin ich nun mal.

Aber ich habe Ihr Buch gelesen, das Sie gemeinsam mit Matthew Skelton verfasst haben. Ich habe also im Grunde genommen viele Fragen, und wir hatten vor der Live-Schaltung auch Zeit, einige Dinge durchzugehen, und vielleicht haben wir während dieses Gesprächs Zeit, darüber zu sprechen. Wir haben etwa eine Stunde Zeit.

Und falls jemand Fragen stellen möchte, nutzt bitte den Q&A-Bereich und nicht den Chat. Was dieses Webinar angeht, schlage ich jedoch vor, dass wir zu Beginn über einige Aspekte rund um das Buch sprechen – nicht über das Buch selbst, sondern über das, was es umgibt. Denn es ist natürlich noch etwas zu früh, um darüber zu sprechen, wie die zweite Auflage gestaltet sein wird.

Aber die Erstausgabe, weil sie ja gerade erst erschienen ist, oder? Aber die Erstausgabe – Ja, im September letzten Jahres. Oh, schon im September.

Ja. Die Zeit vergeht so schnell. Ist das wirklich schon September letzten Jahres?

Ja. Oh, wow. Ja.

Na bitte. Aber was ich wissen möchte: Die erste Auflage hat mehrere tausend Rezensionen auf Amazon, also nenn mir keine konkrete Zahl. Ich finde zwar nicht, dass du das tun solltest, aber das Buch läuft doch gut, oder?

Wie fühlt es sich denn an, ein Buch geschrieben zu haben, das so gut läuft? Nun, das fühlt sich wirklich gut an. Aber ich wollte mich auch dafür bedanken, dass ihr mich eingeladen habt.

Natürlich bewundere ich auch deine Arbeit als Autor, und du hast das wirklich gut gemacht. Und ich habe auch unseren Austausch über verschiedene Themen sehr genossen. Das Buch, also „Team Topologies“, erschien 2019 in der ersten Auflage.

Es ist wirklich gut gelaufen. Ich denke – und darüber haben wir ja schon kurz gesprochen, bevor wir angefangen haben –, dass das Buch für mich und auch für Matthew nicht einfach etwas war, bei dem wir gesagt haben: „Oh, wir haben diese tolle Idee. Lass uns darüber schreiben.“ Es war vielmehr etwas, das sich über viele Jahre hinweg aus meinen und seinen Erfahrungen herauskristallisiert hat, und ich glaube, es gab mehrere Faktoren, die zum Erfolg beigetragen haben.

Ich glaube, die letzten Zahlen, an die ich mich erinnere, lagen bei etwa 200.000 Exemplaren in den ersten fünf Jahren, so in etwa. Das ist also ziemlich gut.

Wow. Ich glaube, es war eine Kombination verschiedener Faktoren – unsere Erfahrungen, meine und die von Matthew, haben sich wirklich gut ergänzt. Wir haben das Buch zu einer Zeit geschrieben, in der viele Unternehmen – und das haben wir immer wieder gehört – sagten: „Genau das haben wir gebraucht“, denn wir wussten zwar, dass wir einige organisatorische Probleme hatten, aber uns fehlte ein strukturierter Ansatz, um darüber nachzudenken.

Es baute auch darauf auf, dass Matthew und ich mehrere Jahre lang als Berater in den Bereichen DevOps und Continuous Delivery tätig waren. Wenn man sich also die Prinzipien dahinter ansieht, stimmen sie sehr gut mit den Prinzipien von „Team Topologies“ überein, nur dass wir uns hier eher auf die organisatorische Seite konzentrieren als auf die technische Seite und die konkreten Praktiken. Und ich glaube, es war genau der richtige Zeitpunkt, dieses Buch zu schreiben.

Wir hatten uns bereits zuvor mit sogenannten DevOps-Topologien beschäftigt. Das Projekt wurde von Matthew ins Leben gerufen, und ich habe dann dabei geholfen, es weiterzuentwickeln – es handelte sich dabei um eine Website. Sie ist immer noch online, falls jemand sich die DevOps-Topologien ansehen möchte.

Und dann wurde uns klar, dass diese Muster über DevOps hinausgehen, das damals ein großes Thema war. Und was wirklich cool ist – jetzt schweife ich ein bisschen ab, aber ihr könnt mich jederzeit unterbrechen. Nein.

Aber was jetzt wirklich cool ist, ist, dass natürlich alle über KI reden, oder? Wenn wir an die Muster denken, die wir in „Team Topologies“ beschrieben haben, und an die Prinzipien – die wir in der zweiten Auflage stärker hervorheben wollten –, gibt es ein neues Vorwort, das tiefer auf die Prinzipien eingeht, die hinter „Team Topologies“ in der ersten Auflage standen, denn darüber haben wir eigentlich nicht allzu viel geschrieben. Wir sind eher direkt auf die Muster und die Ziele eingegangen.

Es gibt jedoch eine Reihe von Grundsätzen, und wenn man KI aus organisatorischer Perspektive betrachtet, würde ich sagen, dass fast alles, was wir in der ersten Auflage geschrieben haben, nach wie vor gilt – was das Management der kognitiven Belastung angeht, die Frage, wie man sich für einen schnellen Arbeitsfluss organisiert, wenn man Teams mehr Eigenverantwortung überträgt, und all diese Dinge. Natürlich kann der Einsatz von KI bestimmte Dinge beschleunigen, aber sie kann auch andere Dinge verlangsamen, wenn man nicht so organisiert ist, dass der Fokus auf der Wertschöpfung für die Kunden liegt. Aber ich schweife hier ein wenig ab.

Nein, überhaupt nicht.

Darauf können wir gleich noch näher eingehen. Aber bevor wir das tun, gibt es so viele Dinge in dem Buch, die mir gefallen und die überraschend sind. Ich vermute, viele Leute aus der Tech-Branche haben schon von Conways Gesetz gehört, weil es so präzise widerspiegelt, welchen Einfluss Computersysteme auf Organisationen haben.

Es ist also wirklich interessant, über Conways Gesetz und dessen Folgen zu sprechen und darüber, wie man es vermeiden kann und so weiter. Du beziehst dich auch auf Conways Gesetz. Aber darüber hinaus ziehst du noch viele andere Bücher und zahlreiche weitere Perspektiven heran.

Und eines der Bücher, die Sie zitieren, ist dieses Buch, das Sie inspiriert hat: „Improving Performance: How to verwalten Whitespace on the Organization Chart“. Ja. Und das ist eine wirklich interessante Beobachtung. Welches Potenzial sehen Sie – das Sie damals gesehen haben, aber vermutlich natürlich auch heute noch sehen – in den „weißen Flächen“ des Organigramms?

Und um den Zuhörern einen kleinen Überblick zu verschaffen: Ein Organigramm besteht natürlich aus Kästchen und Pfeilen sowie den Bezeichnungen der Geschäftsbereiche und so weiter. Doch direkt daneben befindet sich natürlich der weiße Raum. Sie sagen jedoch, dass sich in diesem weißen Raum etwas befindet, dass in diesem weißen Raum ein Potenzial schlummert, das sich entfalten muss, damit Organisationen effektiv werden können.

Was hast du denn in den Leerräumen gesehen, Manuel? Ja. Das war ja das wichtigste Konzept in diesem Buch – diese Idee der Leerräume.

Weil es viele der, sagen wir mal, Missstände in Organisationen verdeutlicht: Wenn wir uns das Organigramm ansehen, ergibt das normalerweise Sinn. Wir organisieren uns so, die verschiedenen Bereiche und so weiter. Aber dann sind da all die Lücken – all das, was dort nicht dargestellt ist, was aber im Alltag passiert.

Es ist also fast so, als ob es um Dinge geht, die nicht bewusst festgelegt und verstanden werden, und oft hat das mit den Schnittstellen zwischen Teams und Abteilungen zu tun. Denn wenn man sich dann ein Organigramm ansieht, wie du gesagt hast, besteht es nur aus Kästchen und Pfeilen, und man sieht, wie man organisiert ist. Wenn man darüberlegt, wie die Arbeit tatsächlich erledigt wird, wird dort der weiße Raum, wie soll ich sagen, sichtbarer, dass es eine Menge Dinge gibt, über die nicht klar und bewusst nachgedacht wurde, und genau dort fängt man an, das zu erkennen.

Und das ist interessant: Eine ganz einfache Übung, die man in der eigenen Organisation durchführen kann, besteht darin, an eine Arbeit zu denken, die man erledigt hat – vielleicht eine neue Funktion oder etwas Wertvolles –, und dann eine Linie durch das Organigramm zu ziehen, um zu zeigen, welche Abteilungen und Teams daran beteiligt waren, und oft gerät man dabei in ein riesiges Durcheinander. Und es ist interessant: Selbst in der zweiten Auflage von „Team Topologies“ gibt es eine Fallstudie. In der zweiten Auflage gibt es also 10 neue Fallstudien, denn eines der Ziele der zweiten Auflage war es, Beispiele dafür zu haben, wie Unternehmen damit begonnen haben, „Team Topologies“ anzuwenden.

In der ersten Ausgabe konzentrierten sich die Fallbeispiele eher auf bestimmte Muster. Jetzt geht es jedoch um Unternehmen, und zwar um große Unternehmen, die diese Ideen tatsächlich aufgegriffen und umgesetzt haben. So gibt es beispielsweise in Belgien ein Unternehmen namens Telenet.

Sie gehören zu den führenden Telekommunikationsanbietern. In der case study stellte sich heraus, dass der Ausgangspunkt darin bestand, dass sie all diese Teams hatten. Betrachtet man die Organisation also nur nach diesen Teams, ergibt das auf dem Papier durchaus Sinn.

Okay, es gibt einen „Tribe“ für den Kundensupport, einen für dies und einen für das. Und dann haben sie, wie ich schon sagte, die Grenzen gezogen: Wenn die Arbeit tatsächlich anfängt, wie sehen dann die Abhängigkeiten aus?

Und im Grunde genommen sind das einfach überall Linien. Mm-hmm. Und genau dort wird der weiße Raum, der vorher da war, zu – okay, vielleicht können wir ihn jetzt als dunklen Raum bezeichnen.

Ich weiß es nicht. Es wird einfach deutlich, dass vieles nicht gut funktioniert hat. Und diese case study übrigens super interessant, weil sie tatsächlich einige der Konzepte und Teamtypen, über die wir in „Team Topologies“ sprechen, auf der Ebene der „Tribes“ umgesetzt haben.

Man sagt also, dieser Stamm konzentriere sich auf den Endkunden, dieser Stamm sei ein Plattform-Stamm, der interne Fähigkeiten bereitstellt, Fähigkeiten so weiter. Aber ja, aus dieser Perspektive betrachtet sind die „White Spaces“ jene Dinge, die nicht bewusst und klar definiert sind und die letztendlich zu massiven Hindernissen bei der Wertschöpfung für unsere Kunden werden. Ja.

Ich betrachte den Freiraum sowohl als ein verborgenes Labyrinth als auch als den Weg, auf dem Arbeit tatsächlich erledigt wird. Ja. Es ist also beides.

Es ist das geschäftige Treiben des Arbeitsalltags, das in diesen sehr formellen Diagrammen nicht wirklich zum Ausdruck kommt. Und wir werden noch auf die Fallstudien und die Änderungen zurückkommen, die Sie in der zweiten Auflage vorgenommen haben, denn das alles ist wirklich sehr lesenswert. Wir werden also auf jeden Fall noch darauf zurückkommen.

Aber ich nehme mal an – und ich weiß, dass du das schon unzählige Male gemacht hast, also bitte schlaf nicht vor Langeweile auf dem Stuhl ein, Manuel. Das ist sozusagen... Aber beschreibe doch ganz kurz, welche Teams du Unternehmen empfehlen würdest. Ja.

Klar. Kein Problem. Das ist so, als würde eine Band ihre größten Hits spielen, oder?

Jeden Abend. Ja. Nein, aber eigentlich, wie ich schon sagte, als wir die erste Auflage geschrieben haben, glaube ich, dass das einer der Hauptunterschiede zur zweiten Auflage ist.

Die erste Ausgabe entsprach weitgehend dem, was wir bei diesen Mustern und dieser Arbeit beobachtet hatten, und wir hatten, wie ich bereits sagte, viele dieser Muster und Ideen aus unserer Arbeit gefestigt und wollten sie dann in das Buch einfließen lassen. Und so habe ich früher immer so gesagt: „Okay, das ist diese Art von Team und jene Art von Team.“ Heute gehe ich gerne – und mit Ihnen – vom „Warum“ aus.

Bei „Team Topologies“ geht es darum, einen schnellen Wertfluss zum Kunden zu erreichen. Das sollte man also im Hinterkopf behalten: Es geht nicht nur darum, zu sagen: „Lasst uns schnell vorankommen und zu einer Maschine werden, die Dinge liefert.“ Der Wert wird erst dann realisiert, wenn jemand das nutzt, was man bereitstellt, und es ihm hilft – und es hilft auch dem eigenen Unternehmen. Genau da entsteht der gelieferte Wert.

Es geht nicht nur darum, Funktionen oder irgendwelchen KI-Mist oder was auch immer zu liefern. Wenn wir das also wollen, dann sind die Teamtypen, über die wir in „Team Topologies“ sprechen, gewissermaßen als Magneten gedacht – in dem Sinne, dass dies das Ziel sein sollte, das wir anstreben. Und der erste Typ ist das, was wir als „stream-aligned“ Teams bezeichnen.

Das ist also vergleichbar mit funktionsübergreifenden Produktteams. Der Grund, warum wir bei den Strömen eine Unterscheidung treffen wollten, ist, dass Produkte in der Regel sehr komplex sind und man daher nicht ein einziges Team für ein ganzes Produkt verantwortlich machen kann. Wir müssen also innerhalb der Produkte überlegen: Welche verschiedenen Ströme gibt es?

Und die Arbeitsstränge können so ausgerichtet werden, dass es für dasselbe Produkt unterschiedliche Nutzer gibt. Daher benötigen wir vielleicht verschiedene Teams, die sich auf die erfahreneren Personas, die weniger erfahrenen oder – je nachdem, worin der Unterschied besteht – auf andere Gruppen konzentrieren. Oder wir haben natürlich verschiedene Nutzer innerhalb des Produkts, und vielleicht ist es gerade das, was unterschiedliche Arbeitsstränge sinnvoll macht.

Oder manchmal handelt es sich um eine Reihe von Funktionen oder Features, die relativ unabhängig voneinander sind – das könnten beispielsweise Ihre Streams sein. Oft ist es eine Kombination dieser verschiedenen Faktoren. Und das knüpft tatsächlich an das an, was Sie vorhin über Conways Gesetz gesagt haben, wonach wir aus Sicht der technischen Architektur offensichtlich von der Ansicht abgewichen sind, dass Monolithen schlecht sind – es handelt sich um große Anwendungen, die schwer zu ändern und weiterzuentwickeln sind.

Und dann kamen die Microservices, und man dachte sich: Okay, wenn wir all diese Modularität und diese kleinen Dienste haben, können wir sie schneller weiterentwickeln. Aber dann fehlte uns eigentlich etwas dazwischen – man kann es Makroservices nennen oder wie auch immer –, also Dienste, die gut zu einem Team passen. Denn man möchte wahrscheinlich nicht Hunderte kleiner Dienste haben, mit denen sich ein und dasselbe Team herumschlagen muss.

Idealerweise sollten diese prozessorientierten Teams also für einen Dienst oder einen Teil eines Produkts verantwortlich sein, der weitgehend unabhängig vom Rest ist, sich eigenständig weiterentwickeln kann und den Kunden einen Mehrwert bietet. Es handelt sich also nicht nur um eine technische Komponente, sondern um etwas, das einen klaren Mehrwert hat, und wir wissen, wer die Nutzer sind und welche Bedürfnisse sie haben. Die Schwierigkeit bei solchen Teams besteht nun darin, dass man von einem relativ kleinen Team erwartet, dass es über viele verschiedene Kompetenzen und Fähigkeiten verfügt.

Und es gibt auch viel zu tun, wenn es darum geht, die Kunden zu verstehen, die Anforderungen zu ermitteln und diese dann tatsächlich in konkrete Software oder das zu entwickelnde Produkt umzusetzen, es an die Kunden auszuliefern und anschließend zu analysieren, ob es genutzt wird, ob es die Geschäftskennzahlen verbessert und all das. Im Idealfall fällt das in den Aufgabenbereich des stream-orientierten Teams. Das ist also eine Menge Arbeit, und das ist der Hauptgrund, warum wir andere Arten von Teams einbeziehen.

Es gibt also noch drei weitere Arten von Teams, nämlich die unterstützenden Teams, die in der Regel Experten auf einem bestimmten Gebiet sind. Ihre Aufgabe besteht nicht darin, die Facharbeit selbst zu erledigen, sondern den Teams dabei zu helfen, sich das nötige Wissen anzueignen, damit diese die Arbeit selbst ausführen können.

Das ist also eine sehr wichtige Veränderung gegenüber der traditionellen Sichtweise, bei der es eine Art von „gemeinsamen Experten“ gibt. Das sind die einzigen Leute, die wissen, wie man X macht. Wenn diese Leute unterstützend arbeiten, dann handeln sie nach dem alten Sprichwort: „Gib den Menschen keinen Fisch, sondern bring ihnen das Fischen bei, damit sie selbstständiger werden können.“ Mm-hmm.

Das betrifft also eher den Bereich der Kompetenzen. Und dann gibt es noch die Plattform-Teams, die wir in der zweiten Auflage etwas näher erläutert haben. Im Wesentlichen handelt es sich dabei um Teams, die interne Produkte bereitstellen – man könnte sie als Produkte betrachten, die den internen Teams zur Nutzung dienen, damit diese sich um weniger kümmern müssen.

Sie haben eine geringere kognitive Belastung, wie wir es nennen, da wir über interne Dienste verfügen, die uns dabei helfen können. Oft geht es zunächst um viele technische Aspekte, wie zum Beispiel die Bereitstellung, die Überwachung und die Infrastruktur. All das lässt sich automatisiert erledigen – im Idealfall durch die Plattform selbst – und ist zudem benutzerfreundlich.

Dadurch werden dem stream-orientierten Team viele Sorgen abgenommen, sodass es sich auf die Kundenbedürfnisse konzentrieren kann. Und dann hatten wir Teams für komplexe Teilsysteme, über die wir viel diskutiert haben, weil man sich fragen muss, ob diese wirklich notwendig sind; es gibt jedoch gelegentlich Situationen, in denen man einen sehr komplexen Algorithmus oder ein Teilsystem hat, oder sogar einen Dienst, der komplexe Verarbeitungsprozesse durchführt oder sehr hohe Anforderungen an die Verarbeitungs- oder Rechenleistung stellt. Und manchmal braucht man ein Team, das sich ausschließlich diesem Dienst oder Subsystem widmet, denn wenn man das stream-orientierte Team damit beauftragt, wird das seine kognitiven Kapazitäten einfach übersteigen.

Und so kann man diese komplexen Subsystem-Teams fast wie eine Art Mini-Plattform betrachten. Es handelt sich zwar nur um eine Art von Subsystem oder Dienst, aber er sollte so bereitgestellt werden, dass er für die streamenorientierten Teams leicht nutzbar ist. Ja.

Danke. Das sind also die vier – Danke ... – Arten.

Ja. Danke. Und danke, dass Sie sich die Zeit genommen haben.

Das muss schon das x-te Mal gewesen sein – ich weiß nicht, wie oft du das schon gesagt hast, aber … ich habe den Überblick verloren. Ja. Klar.

Aber wir mussten das irgendwie klarstellen, denn im Grunde arbeiten die Teams, die du vorschlägst, in Topologien, oder? Das ist ja der Grundgedanke von Team-Topologien. Es geht darum, dass diese Teams – ja …

Sie arbeiten in bestimmten Konstellationen, in bestimmten Unternehmen, um bestimmte Aufgaben zu erfüllen, oder? Ja. Und sie entwickeln sich weiter.

Oder sie sollten sich ziemlich kontinuierlich weiterentwickeln. Die Struktur besteht also aus einer Kombination verschiedener Teamtypen und deren Interaktionen, richtig? Betrachtet man das Ganze als ein System, in dem – idealerweise – nur auf den Arbeitsablauf abgestimmte Teams mit allen erforderlichen Kompetenzen und einer angemessenen kognitiven Belastung für alle Beteiligten vorhanden wären, dann wäre das alles, was wir bräuchten.

Man könnte einfach Teams, die auf den jeweiligen Arbeitsablauf abgestimmt sind, parallel arbeiten lassen, um den Kunden einen Mehrwert zu bieten. Aber wir wissen, dass das nicht sehr realistisch ist. Die Struktur entspricht also fast dem Konzept eines „Teams aus Teams“, die effektiv zusammenarbeiten, um den Kunden diesen Mehrwert zu bieten.

Aber dann sollte sich das im Laufe der Zeit weiterentwickeln. Ausgehend von den Herausforderungen, vor denen wir heute stehen. Wenn wir an die heutige Situation denken, gibt es vielleicht noch einige Lücken bei der Einführung von KI in den Teams oder beim Verständnis dafür, wie KI auf ethische Weise in unsere Arbeitsabläufe und Produkte integriert werden kann.

Und es gibt viele Fragen, bei denen wir vielleicht die Hilfe von Experten oder einem unterstützenden Team benötigen, das den streambasierten Teams dabei helfen kann, diese Dinge zu klären. Vielleicht brauchen wir auch Plattform-Tools, die die Anwendung einiger dieser neuen Ansätze vereinfachen. Das könnten also die aktuellen Herausforderungen sein.

Aber vielleicht hat sich das Ganze in ein, zwei oder drei Jahren mehr oder weniger in der Organisation etabliert. Wir wissen dann ungefähr, was wir nutzen sollen, und die Teams verfügen über genügend Wissen, sodass wir vielleicht nicht mehr dieselben Unterstützungsteams brauchen – oder vielleicht gibt es dann neue Plattformdienste, weil das, was früher eher experimentell war, sich inzwischen etabliert hat. Das ist ein guter Ansatz, und wir können das dann quasi als Plattformdienst anbieten.

Es ist also sehr wichtig, Topologien nicht als etwas Statisches zu betrachten. Es handelt sich nicht um ein statisches, sagen wir mal, Betriebsmodell.

Es geht darum, was heute funktioniert, um die Herausforderungen zu bewältigen, denen wir gegenüberstehen – Herausforderungen, die sich in den nächsten Monaten und Jahren weiterentwickeln werden. Ja, und mir gefällt diese Flexibilität. Es ist eine Organisationsstruktur, die in der Lage ist, sich anzupassen, zu verändern und neu auszurichten – und jeder, der in der Tech-Branche tätig ist, weiß, dass dies für ein Unternehmen möglich sein muss.

Ja. Sonst hat man diese extrem aufwendigen Strukturen mit Teams, die sehr komplex sind und im Grunde genommen nur wenig Wertschöpfung liefern.

Ich glaube, das haben wir alle schon mal in unserer Karriere erlebt. Und es ist auch interessant: Mir fällt auf, dass viele Unternehmen nicht nur in Tools, sondern auch in Fachwissen und bewährte Verfahren investieren. Natürlich sprechen wir jetzt über KI, aber das war vor DevOps und CI/CD; wenn wir über eher technische Aspekte sprechen – Sie sind ja im Datenbereich tätig –, dann geht es um Dinge wie Data Mesh und all diese Themen.

Natürlich benötigen sie oft Fachwissen und Werkzeuge, und sie investieren viel darin, aber sie investieren nicht in die Voraussetzungen dafür. Es ist also so, als hätten wir wirklich gute Werkzeuge, die wir nutzen könnten, aber die Leute nutzen sie nicht, weil die streambasierten Teams oder Produktteams mit ihrem Tagesgeschäft beschäftigt sind, unter großem Lieferdruck stehen und niemand da ist, der ihnen hilft, herauszufinden, wie man diese Dinge gut macht, oder? Oft führen sie vielleicht einige Dinge ein, weil ein gewisser Druck besteht, dass wir DevOps oder was auch immer machen müssen.

Aber oft gehen sie dabei eher planlos vor. Der Teil, bei dem es darum geht, die Voraussetzungen zu schaffen, ist wirklich interessant und gehört – zumindest für mich – zu den Dingen, auf die ich bei „Team Topologies“ besonders stolz bin. Das ist etwas, das vielen Organisationen fremd ist, und wenn sie sehen, wie es funktioniert, erkennen sie auch die Auswirkungen, die es hat – dabei ist es doch so einfach: Man muss den Leuten nur beibringen, wie sie diese großartigen Werkzeuge und Methoden nutzen können.

Man kann ihnen das doch nicht einfach nur geben und erwarten, dass sie es wie von Zauberhand lernen, oder?

Weil oft nicht genug Raum bleibt, um Dinge zu lernen und sie in der Praxis wirklich umzusetzen. Nein, ich glaube, ich kann zugeben, dass ich ein Geek bin. Aber zu sehen, wie Unternehmenstechnologie tatsächlich funktioniert, ist für mich einfach eine große Freude, und das habe ich schon oft selbst erlebt.

Ich finde natürlich, dass die Ausfallrate bei Unternehmenstechnologie dramatisch hoch ist. Als ich noch in anderen Positionen tätig war, habe ich das ja immer wieder beobachtet, oder? Diese gescheiterten IT-Projekte – ja …

oder jene Teams, die eingestellt wurden – und typischerweise waren das vor etwa zehn Jahren Datenwissenschaftler, oder? Und die hatten riesige Gehälter, haben aber eigentlich nichts oder nur sehr wenig geleistet, waren lediglich mathematische Genies – wie enttäuschend kann das denn sein, oder? Aber wie auch immer, das berührt wirklich die Flexibilität und die usability technischen Fähigkeiten, Menschen und Technologie, und ich denke, diese Team-Topologie ist so etwas wie die organisatorische Dimension dieser technologischen Dezentralisierungen, die wir gesehen haben: Data Mesh, Microservices.

Inwieweit hängen diese Dinge zusammen, und wie siehst du diesen Zusammenhang mit diesen Dezentralisierungs- – ja … – technologischen Bewegungen? Ja, ich würde sagen, wenn man das Ganze aus der Vogelperspektive betrachtet, ist es tatsächlich genau das, was du zuvor erwähnt hast.

Conways Gesetz befasst sich mit den Auswirkungen unserer Organisationsstruktur und unserer Kommunikationsmöglichkeiten sowie mit den Schnittstellen zwischen Teams und der Art von Systemen, die wir entwickeln können. Doch es gibt noch eine dritte Dimension, nämlich die eigentliche Geschäftsarchitektur, wenn man so will. So verwenden verschiedene Unternehmen, wenn man so will, unterschiedliche Begriffe, um zu beschreiben, wie ihr Geschäft organisiert ist.

Ich spreche gerne über Wertströme. Wenn Unternehmen Ansätze wie Domain-Driven Design genutzt haben, sprechen sie meist von Geschäftsbereichen und Unterbereichen. Letztendlich geht es aber um dasselbe, nämlich darum, die eigene Geschäftsarchitektur zu verstehen.

Welchen Mehrwert bieten Sie welchen Kunden, und wie ist dies organisiert? Was gehört zu den verschiedenen Wertströmen oder Bereichen usw. Und diese Geschäftsarchitektur sollte auf Ihre Organisationsarchitektur abgestimmt sein – also auf Ihre Struktur und Ihr Organigramm, aber auch auf die Kommunikationskanäle und all das.

Und wenn das mit Ihrer technischen Architektur übereinstimmt, dann haben Sie den großen Vorteil, dass diese Dinge aufeinander abgestimmt sind. Sie stehen nicht im Widerspruch zueinander. Ich glaube also, was passiert ist – ich weiß nicht, ob es ein bisschen, wie soll ich sagen, arrogant von mir ist, das zu sagen, aber ich glaube, bis zu „Team Topologies“ gab es eine Art Trennung zwischen, okay, da ist die technische Architektur, und da kommen Dinge wie Microservices und Data Mesh bis zu einem gewissen Grad ins Spiel.

Und diese Dinge – diese Muster, diese Ideen – sind zwar gut und hilfreich, aber sie standen nicht im Zusammenhang mit dem Rest, also der organisatorischen Seite. Wir haben vielleicht nicht so sehr die Auswirkungen gesehen, die entstehen, wenn wir einfach nur Microservices einführen – wie ich bereits sagte: Okay, wenn man am Ende Hunderte oder Tausende von Microservices hat, ist der Aufwand für die Verwaltung all dieser Dienste viel höher. Und oft merken Unternehmen dann, dass dies uns eigentlich nicht dabei hilft, schneller voranzukommen.

Wir haben mehr Arbeitslasten als früher, weil es all diese kleinen Dienste gibt, die oft nicht nach Kundengruppen aufgeteilt oder getrennt wurden. Wir arbeiten eher funktionsorientiert. Und ich glaube, genau darin lag die Lücke: Wir haben diese bewährten technischen Verfahren übernommen, aber sie haben nicht die Wirkung auf das Geschäft und die Fähigkeit, schnell Mehrwert zu schaffen, die wir erwartet hatten.

Und genau deshalb denke ich, dass wir irgendwann versuchen, auch Teamtopologien einzuführen, damit Teams – oder wenn man über die technische Architektur nachdenkt – darüber nachdenken können, was für ein Team von in der Regel bis zu acht oder neun Personen sinnvoll ist. Was als Dienst oder Teil eines Produkts sinnvoll ist, damit ein Team diesen spezifischen Dienst oder diesen spezifischen Arbeitsstrang weitgehend eigenständig bearbeiten und einen Mehrwert liefern kann. Richtig?

Das ist also sozusagen das Zusammenfügen der Puzzleteile, wenn man so will. Ja. Ich glaube, ich kann da ganz offen sein.

Ich weiß nicht, ob ich mich dafür schämen sollte oder nicht, aber ich wusste schon vor dem Lesen, dass „Team Topologies“ ein wichtiges Buch ist. Ich wusste nur wirklich nicht, warum. Und es dauerte…

Ich habe gelesen und gelesen, und am Anfang habe ich immer noch nicht verstanden, warum das wichtig ist. Und dann hat es Klick gemacht, oder? Genau das, was du ansprichst, hat mir klar gemacht: Okay, wir sind es gewohnt, Technologien als etwas zu betrachten, das man erst einmal aufschlüsseln muss.

Sie müssen die Datenarchitekturen aufbrechen. Sie müssen die großen ERP-Systeme aufbrechen. Was auch immer es ist: Sie müssen den Monolithen aufbrechen, um das Potenzial dessen, womit Sie es zu tun haben, freizusetzen.

Und dann wurde mir plötzlich klar: Okay, in diesem Buch geht es darum, dass man dasselbe tun kann – oder dass man dasselbe für seine Organisation tun muss. Auch das ist ein Monolith, und auch den kann man aufbrechen. Und genau darum geht es in diesem Buch.

Und dann habe ich es verstanden. Zumindest glaube ich, dass ich es verstanden habe, aber sag du es mir. Wie auch immer.

Ja, ich glaube schon. Nun, danke. Das haben wir aufgezeichnet.

Danke. Wenn du das mit deiner vorherigen Frage verbindest, warum das Buch so erfolgreich war, denke ich, dass es zum einen daran liegt, dass viele Leute sagten: „Ich fühlte mich verstanden“, etwa wenn wir über Schwachstellen sprechen und das, was Sie gerade gesagt haben: Wenn wir nur in einer Dimension betrachten, dann geben wir unser Bestes, um beispielsweise die technische Architektur und unsere Arbeitsweise zu verbessern, und wir sehen die Auswirkungen auf der anderen Seite nicht. Die Leute konnten sich also sehr gut mit unserer Beschreibung der Probleme identifizieren.

Und dann sagten einige Leute auch – und da stimme ich zu –, dass die Ideen, die wir in Bezug auf Lösungen oder, sagen wir mal, die Muster eingebracht haben, auf vielem aufbauen, was bereits in der Vergangenheit getan wurde: der DevOps-Bewegung, in gewissem Maße auch Agile, und Systemdenken ist ebenfalls sehr wichtig. Manche würden also sagen: „Nun, an Team Topologies ist nichts besonders Neues“, aber es ging darum, wie diese Dinge zusammengeführt und mit einem Vokabular versehen wurden. Und wie ich bereits sagte, denke ich, dass der Teil der Ermöglichung derjenige ist, bei dem viele vielleicht nicht daran gedacht hatten, dies bewusster zu gestalten.

Aber vieles davon baut natürlich auf dem auf, was wir bereits aus der Vergangenheit kennen, sogar Konzepte wie „Platform as a Product“. Es ging aber darum, die verschiedenen Aspekte zusammenzuführen. Ich glaube, genau das hat „Team Topologies“ letztendlich bewirkt.

Und vielleicht sagst du deshalb, dass es eine Weile gedauert hat, zu verstehen, warum das wichtig ist – weil es meiner Meinung nach viele Dinge miteinander verknüpft, die wir gefühlt und gewusst haben. Irgendetwas stimmt hier nicht. Warum sehen wir keine anderen Ergebnisse?

Ich denke also, für mich liegt die Stärke von „Team Topologies“ darin, dass es in einem relativ kurzen Buch die verschiedenen Aspekte zusammenführt und ein Verständnis für die organisatorische Seite vermittelt – und dass es zudem sehr gut mit den technischen Prinzipien und den Ideen hinter DevOps und Continuous Delivery im Einklang steht.

Das hat also auch für viele technisch versierte Leute Sinn ergeben. Auf jeden Fall. Auch ich habe mich durch dieses Buch verstanden gefühlt, genau wie viele andere Leser.

Lass uns nun etwas näher auf die zweite Auflage eingehen. Es gibt einige Änderungen, und du hast das bereits kurz angesprochen, aber lass uns das noch etwas genauer betrachten. Ja.

Ich möchte das Gespräch mit den Fallstudien beenden, denn es gibt so viele davon, und sie sind so interessant und so unterschiedlich. Nicht wahr? Deshalb möchte ich dieses Thema für etwas später aufheben.

Das Erste, worüber wir meiner Meinung nach sprechen sollten, ist im Grunde genommen etwas, das mir sehr am Herzen liegt, da ich den Großteil meiner beruflichen Laufbahn damit verbracht habe. Lassen Sie mich also zunächst kurz den Hintergrund erläutern. Dies ist eine lange Einleitung zu einer kurzen Frage.

Bitte habt etwas Geduld mit mir. Ich habe den Großteil meiner Karriere in großen Unternehmen verbracht, sowohl als festangestellter Mitarbeiter als auch als externer Berater, und habe viele Kunden beraten. Das hat im Grunde damit angefangen, dass ich als Autor für Technikthemen tätig wurde und meine Texte großen Anklang fanden. Also habe ich neben meiner Festanstellung meine eigene Beratungsfirma gegründet.

Was ich tat und womit ich oft konfrontiert wurde, waren diese zahlreichen identischen Technologien oder Technologien, die mehr oder weniger dasselbe taten, aber vielleicht nicht ganz dasselbe. Das lag vor allem an der Richtung, die ich auf der Metadaten eingeschlagen hatte. Diese Technologien, die meiner Meinung nach in ein Netz, ein sogenanntes „Meta-Netz“, eingebunden werden können. Aber genug von mir.

Was ich so interessant finde, ist, dass du in der Teamtopologie-Konfiguration ein bestimmtes Team geändert hast, nämlich das Plattform-Team. Und das beruht darauf – ich glaube, dein Co-Autor Matthew hat gesagt, dass ihr das eigentlich schon während der Arbeit an der ersten Auflage besprochen habt, aber – Ja … dann ist es in irgendeinem Slack-Thread oder so untergegangen.

Aber du hast die Struktur geändert und den Namen von „Plattform-Team“ in „Plattform-Gruppe“ geändert. Warum denn das? Ja.

Warum handelt es sich jetzt um eine Plattformgruppe? Also, wenn ich kurz auf die zweite Ausgabe eingehen darf – Mm-hmm … für diejenigen, die sie noch nicht gesehen haben.

Die Idee war also, dass wir die erste Auflage sozusagen unangetastet gelassen haben, denn wie ich bereits sagte, gilt im Grunde alles, was in der ersten Auflage stand, nach wie vor. Vielleicht sprechen wir heute nicht mehr so viel über DevOps wie noch 2019, aber die Ideen sind nach wie vor gültig. Und dann haben wir ein neues Vorwort verfasst, das vor allem einen Rückblick auf die fünf sechs Jahre seit Erscheinen der ersten Auflage, und welche Dinge wir falsch verstanden hatten oder die im ersten Buch nicht klar genug waren, wie zum Beispiel die dahinterstehenden Prinzipien, und dann Dinge wie die unterschiedliche Umsetzung der Muster durch verschiedene Unternehmen wie Telenet, das ich zuvor erwähnt habe, wobei die Teamtypen auf Stammesebene angewendet wurden.

Also, und dann gibt es ein neues Nachwort, das sich eher darauf bezieht, wo wir heute stehen und wie es in den nächsten Jahren mit der KI weitergeht – und wie sich dadurch unsere Sichtweise auf die organisatorischen Dynamiken verändert oder auch nicht. Außerdem gibt es 10 neue Fallstudien und diesen Hinweis zur Plattformgruppierung. Bei der ersten Auflage wollten wir es einfach halten.

Also, die Idee des Plattformteams: Einerseits soll es einfach gehalten werden, andererseits ist das Plattformteam eine andere Art von Team, denn manche sagen, es sei ja quasi ein Produktteam, da es sich um ein internes Produkt handelt. Ja, aber wir hatten das Gefühl, dass es genügend Unterschiede gibt, da man interne Kunden hat, keine externen, und oft – häufig aus technischer Sicht – komplexe Dienstleistungen erbringt. Wir haben viel über diese Art von technischen Dienstleistungen gesprochen.

Was wir also irgendwie übersehen haben – und vielleicht ist mir das bei der ersten Auflage gar nicht bewusst gewesen –, ist, dass der Begriff „Plattform-Team“ manchmal so missverstanden wurde, als handele es sich um ein einziges Team, das für eine ganze Plattform verantwortlich ist. Und natürlich neigen interne Plattformen dazu, mit der Zeit zu wachsen. Wenn sie erfolgreich sind – was ja eine gute Sache ist –, werden sie in der Regel wachsen.

Und so war es zumindest für mich – ich glaube, es war eines dieser Dinge, die mir irgendwie selbstverständlich erschienen: dass man mehrere Teams brauchen würde und dass man diese größere Plattform brauchen würde. Wenn sie klein ist und man ein oder zwei Teams hat, ist das in Ordnung. Aber wenn man drei, vier, fünf oder im Grunde mehr als, ich würde sagen, 30 Leute hat, die an der Plattform arbeiten, muss man sich überlegen, welche verschiedenen Arbeitsströme es innerhalb der Plattform gibt, oder?

Welche verschiedenen Dienste gibt es, damit Sie die Plattformstruktur auch aus Teamperspektive organisieren können, ähnlich wie Sie es bei Ihren Produkten tun? Wir müssen verschiedene Ströme identifizieren, je nachdem, ob es sich nur um interne Kunden handelt. Und das ist der Punkt, an dem wir in manchen Organisationen mit ihnen sprechen und feststellen, dass sie einfach dieses riesige Plattformteam mit Dutzenden von Mitarbeitern hatten, und natürlich waren sie extrem beschäftigt, extrem überlastet, rannten herum und versuchten, Probleme zu beheben und neue Dinge zu liefern, aber das alles war sehr ad hoc.

Deshalb versuchen wir in der zweiten Auflage, viel deutlicher zu machen, dass es sich tatsächlich – und vielleicht ist das eine bessere Formulierung – immer um eine Plattformgruppe handelt. Man wird eine Reihe von Teams haben, und diese sollten klar definierte Zuständigkeiten und Grenzen untereinander haben. Das bedeutet nicht, dass sie die ganze Zeit völlig unabhängig sind, aber wir sollten nicht fünf Teams haben, die ihre Arbeit ständig koordinieren müssen.

Wenn man also zunächst davon ausgeht, dass es sich um eine Plattformgruppe handelt, aber manchmal nur ein Team in dieser Gruppe ist, ist das vielleicht eine bessere Sichtweise, die wir in der ersten Ausgabe übersehen haben. Andererseits war es, da es einfacher war, von Plattformteams zu sprechen, meiner Meinung nach auch für Organisationen hilfreich, den Unterschied zwischen Plattform und Streamline auf der Produktseite zu verstehen. Aber jetzt ist es hoffentlich klar.

Ja, klar.

Nein, aber ich stimme dir zu, und ich denke offensichtlich über ähnliche Dinge nach. Ich arbeite gerade an der zweiten Auflage meines ersten Buches, „The Enterprise Datenkatalog“, und es ist ein bisschen dasselbe, oder? In der ersten Auflage ging es nämlich um einen einzigen Datenkatalog einem Unternehmen – und Datenkatalog . In der Realität gibt es in den meisten Fällen jedoch eine ganze Reihe von Datenkatalogen. Ja.

Und sie werden in verschiedenen Bereichen des Unternehmens angesiedelt sein. Manche nutzen nur einen Cloud , andere nur eine bestimmte Datenplattform mit dem dazugehörigen Katalog. Das ist einfach ganz selbstverständlich.

Ja. Und ich schätze, das ist das Privileg, eine zweite Auflage zu schreiben. Da gibt es nicht viele Privilegien.

Das ist harte Arbeit. Aber einer der Vorteile ist doch, dass man auf dem Wissen aus der ersten Auflage aufbauen kann, oder? Ja.

Das wäre wohl schwierig gewesen, würde ich vermuten. Ja. Ich würde sagen, es ist eigentlich ein gutes Zeichen, wenn man in der zweiten Auflage feststellt, dass es in der ersten Auflage einige Dinge gab, die missverstanden wurden.

Das heißt, sie wurden angenommen, richtig, und die Organisationen haben die Ideen umgesetzt. Es ist nur so, dass manche Dinge vielleicht nicht so klar waren, wie sie hätten sein können. Aber das ist nun mal so: Wie bei der Entwicklung von Produkten und Dienstleistungen wird einem klar, dass wir dachten, genau das sei sinnvoll.

Eigentlich müssen wir uns anpassen und unseren Kurs korrigieren.

Ich sehe die zweite Auflage also gewissermaßen als eine Art Kurskorrektur oder als Ergänzung, bei der wir mehr Kontext und weitere Einblicke zu dem liefern, was bereits in der ersten Auflage enthalten war. Mm-hmm. Absolut.

Und ich möchte näher darauf eingehen: Wie Sie bereits erwähnt haben, enthält insbesondere die zweite Auflage zahlreiche Fallstudien. Ich denke, wir sollten uns diese Fallstudien genauer ansehen. Ich habe mich auf zwei konzentriert, aber Sie können gerne auch die dritte ansprechen.

Aber – klar … Ich glaube, EBSCO ist das … Ich bekomme viele Benachrichtigungen auf einer anderen Plattform und schalte sie einfach aus.

Tut mir nur leid. Keine Sorge. Es ist nur viel Lärm.

Zu viele Aufmerksamsanforderungen. Ja, genau. Genau so ist es.

So, da bist du ja. Super. Also, lass uns zunächst mal darüber sprechen, wie der erste use case heißt – EBSCO.

Meinst du das Unternehmen EBSCO? Ja, EBSCO. EBSCO.

Der Grund, warum ich über diesen Fall sprechen wollte, ist natürlich, dass es sich meiner Meinung nach um einen eher kleinen Fall handelt. Interessant ist jedoch, dass sie auch mit einem Framework den Aufbau von Teams gearbeitet haben, wie zum Beispiel „Team Topologies“. Sie haben darüber nachgedacht, eine Organisationsstruktur aufzubauen, die ihnen helfen könnte, mehr zu leisten, und das ist „SafeAgile“.

Aber in diesem Fall – ja … ist das Potenzial von SafeAgile irgendwie ausgeschöpft. Und kannst du näher erläutern, warum das so ist und was du getan hast – ja …

die ihre Konfiguration geändert haben? Ich habe also nicht direkt daran gearbeitet. Und tatsächlich waren wir – was interessant ist – an den meisten Fallstudien in der zweiten Auflage nicht direkt beteiligt.

Es war nicht so, dass wir den Wandel für sie vollzogen hätten. Die Unternehmen haben selbst darüber nachgedacht, wie sie die Ideen umsetzen und sich verändern können, und das ist wirklich toll. Und dann haben wir auf verschiedene Weise davon erfahren, oder sie sind auf uns zugekommen und haben uns erzählt, was sie getan haben.

In manchen Fällen hatten wir vielleicht ein paar Keynotes gehalten oder Training durchgeführt. Aber oft waren wir bei den Fallstudien in der zweiten Auflage nicht direkt beteiligt. Das finde ich auch ziemlich cool.

EBSCO ist also einer dieser interessanten Fälle, bei denen ich vermute, dass, wenn man irgendjemanden hier im Publikum fragen würde, wohl fast niemand schon einmal von EBSCO gehört hätte. Und dann wird einem klar: Oh, das ist eigentlich ein ziemlich großes Unternehmen. Sie stellen also Forschungsdatenbanken und Informationen für Bibliotheken, Universitäten und so weiter bereit.

Es handelt sich also um eines dieser Unternehmen, über die nicht oft gesprochen wird. Und was passiert ist: Sie hatten Safe eingesetzt, und zwar, würde ich sagen, recht erfolgreich. Natürlich ist Safe ein Framework – meiner Meinung nach – besonders dann sinnvoll ist, wenn man in einer sehr chaotischen Organisation anfängt, in der es ständig zu Verzögerungen kommt und alle hektisch hin und her rennen und versuchen, Dinge zu erledigen, aber es herrscht immer großes Chaos.

Natürlich glaube ich, dass Safe dabei helfen kann, eine gewisse Struktur zu schaffen und herauszufinden, wie man besser plant, und es verschafft einem, würde ich sagen, viel Klarheit über die Abhängigkeiten zwischen Teams, zwischen Domänen oder Wertströmen. Das Problem mit SAFe ist, dass es einem irgendwann – und das haben wir nicht nur bei EBSCO, sondern auch bei anderen Unternehmen beobachtet – dabei hilft, von dieser frühen, eher chaotischen Phase zu etwas Strukturierterem überzugehen, das ein bisschen oder sogar viel vorhersehbarer ist.Aber irgendwann hört es irgendwie auf zu helfen, in dem Sinne, dass es sehr stark darum geht, Abhängigkeiten zu verwalten, und nicht so sehr darum, sie zu beseitigen oder mit den Auswirkungen dieser Abhängigkeiten umzugehen. Mm-hmm.

Im Grunde gewöhnt man sich daran. Okay, wir kennen die Abhängigkeiten. Wir wissen, dass wir diese Planung durchführen müssen, damit wir in der Regel einen Quartalsplan haben, aus dem hervorgeht, welche Teams an welchen Initiativen oder Funktionen arbeiten müssen, und so weiter.

Also, wie gesagt, wenn man von einer Situation ausgeht, in der alles chaotisch war und alle Fristen verpasst wurden, dann ja, das hilft. Aber dann kommt man dort irgendwie nicht weiter. Und was sie bei EBSCO wirklich gut gemacht haben, war, dass sie sehr gute Kennzahlen hatten, etwa Slow Metrics, und dass sie sich angesehen haben, wo die Engpässe liegen, wo die Wartezeiten entstehen, um unseren Kunden einen Mehrwert zu bieten oder Änderungen umzusetzen, von denen wir hoffen, dass sie für unsere Kunden wertvoll sind.

Und so wurde ihnen allmählich klar: Okay, wir haben uns zwar stark verbessert, aber wir sind irgendwie auf der Stelle getreten, oder? Wir haben sozusagen den Höhepunkt dessen erreicht, was SAFe uns bieten kann. Also wandten sie sich den Teamtopologien zu, um das Problem anzugehen: Okay, wir wollen uns nicht einfach mit den Abhängigkeiten abfinden.

Wir müssen diese Muster also nutzen, um blockierende Abhängigkeiten zu beseitigen und interne Fähigkeiten zu schaffen, Fähigkeiten tatsächlich dazu beitragen, die Teams zu beschleunigen. Und da sie über eine sehr gute interne Organisations-Telemetrie verfügten – wenn man so will – also sehr gute Kennzahlen, war die Fallstudie für uns unter anderem deshalb interessant, weil sie erkennen konnten, wie der Einsatz von Teamtopologien zur Verbesserung dieser Kennzahlen beitrug.

Ja, genau. Und ich glaube, wenn man wie ich und viele andere SAFe-Agile-zertifiziert ist, spürt man irgendwie, dass es eine Obergrenze dafür gibt, wie viel damit erreicht werden kann, oder? Mm.

Ich habe gehört, dass manche es als Framework bezeichnen. Ich weiß nicht, ob du diesen Begriff übernehmen möchtest, da es sich um ein konkurrierendes Framework handelt. Aber wenn du dir die Webseite ansiehst, gibt es dort viele Komponenten, die du verstehen musst, und wie sie miteinander in Verbindung stehen, um...

Das ist keine einfache Angelegenheit. Einerseits ist es eine große Anfangsinvestition, und dann scheint es mir – abgesehen von diesem Investitionsaspekt – dazu zu führen, dass... Wir haben also vorhin darüber gesprochen, dass wir anpassungsfähig sein und uns gewissermaßen ständig weiterentwickeln müssen, und ich denke – ich bin zwar kein SAFe-Experte, aber nach dem, was ich gesehen habe – scheint es dazu zu führen, dass man an einen Punkt gelangt, an dem man diese Art von, ja, stabilem, monolithischem Framework erhält, was auch immer das in diesem Rahmen funktioniert, aber dann denkt man irgendwie nicht wirklich darüber nach, was der nächste Schritt ist.

Wie können wir uns weiter verbessern? Und natürlich gibt es da die Release-Trains und all das, was – ja, ich denke, wie du gesagt hast – das gut widerspiegelt. Es hilft bis zu einem gewissen Grad, aber dann gibt es eine Obergrenze, weil wir an diese Release-Trains gebunden sind, und trotzdem war es interessant.

Irgendwann hat SAFe einige Ideen aus den Teamtopologien übernommen, andere jedoch nicht, was mir… Hm. Ja, also haben sie im Wesentlichen die Teamtypen übernommen, was meiner Meinung nach ein Fortschritt war.

Aber ihr denkt immer noch nicht unbedingt daran, euren Arbeitsablauf zu verbessern, nur weil ihr die Teamtypen einführt. Und wenn ihr immer noch diese Release-Trains habt, koppelt ihr immer noch – zumindest zeitlich – einen Großteil der Arbeit aneinander, was sich dann in der Regel auch auf technischer Ebene in einer Kopplung niederschlägt, oder? Denn wenn wir ohnehin gemeinsam in, sagen wir, vier Wochen ein Release durchführen, warum sollte ich dann in eine modularere Struktur investieren, die sich unabhängiger weiterentwickeln kann, wenn wir am Ende doch alles zusammen integrieren müssen?

Ja. Also lass uns den Schluss dieses Gesprächs ein wenig abändern, indem wir einfach zugeben, dass ich SAFe Agile für ein Flickwerk aus verschiedenen Methoden halte. Ich wusste eigentlich gar nicht, dass sie Elemente aus den Team-Topologien übernommen haben, aber das ist ja typisch für sie, oder?

Sie haben auch Elemente aus Lean und anderen Prinzipien übernommen, und wenn man daran glaubt, kann das natürlich einen großen Mehrwert bieten. Ich denke, auf einer grundlegenden Ebene ist das möglich, aber es wird sehr kompliziert. Ich wollte Sie eigentlich nach case study anderen case study fragen, aber ich glaube, uns läuft die Zeit davon, und so kommt stattdessen die case study zur Sprache.

Ich finde ihre Plattform, also die Architektur der digitalen Plattform, wirklich interessant, aber wir haben keine Zeit. Das ist zu kompliziert – ja … um das in ein paar Minuten durchzugehen.

Also dachte ich mir stattdessen – wir haben uns vor der Live-Schaltung kurz unterhalten – und deshalb möchte ich lieber eine andere Frage stellen, eine etwas allgemeinere: Du hast diese Bücher bei IT Revolution veröffentlicht. Das ist einfach ein großartiger Verlag. Die Heimat von „The Phoenix Project“ und vielen anderen sehr einflussreichen Büchern, auch wenn sie nicht besonders viele Bücher herausbringen.

Wie haben Sie die Zusammenarbeit mit ihnen aufgebaut, und wie lässt sich die Ausrichtung dieses Verlags beschreiben? Ja. Sie konzentrieren sich im Wesentlichen darauf, Führungskräften in Unternehmen zu helfen.

Und die Bücher, die sie herausbringen, sind, wie du gesagt hast, nur eine Handvoll pro Jahr. Es ist ein kleiner Verlag, der sich wirklich darauf konzentriert, Bücher zu veröffentlichen, die für Führungskräfte in Unternehmen relevant und sinnvoll sind. Natürlich verfolgen verschiedene Verlage unterschiedliche Strategien.

Manche legen Wert auf Quantität. Ihr Fokus liegt auf der Qualität dessen, was sie veröffentlichen. Und wie du schon gesagt hast: Der Grund dafür ist, dass sie bereits einige wegweisende Bücher veröffentlicht hatten, darunter „Phoenix Project“, „Accelerate“ und „From Project to Product“ von Mik Kersten.

Wir waren also der Meinung, dass unser Buch, das wir mit der Absicht geschrieben hatten, … Wir dachten, unsere Zielgruppe würde zunächst aus Unternehmensleitern, Führungskräften aus der Wirtschaft sowie leitenden Ingenieuren und Architekten bestehen. Und so passte es sehr gut zum Publikum von „IT Revolution“.

Ich kannte Gene Kim bereits von früher, aus meiner Arbeit im Bereich DevOps, also ja, das passte einfach alles zusammen. Zumindest war ich damals noch nicht so vertraut mit der Verlagswelt und den verschiedenen Ansätzen beim Veröffentlichen und Lektorieren. Ich glaube also, wir hatten großes Glück, dass sie unser Angebot angenommen haben, den Wert unseres Vorschlags erkannt haben und zudem über einen sehr gründlichen redaktionellen Prozess verfügen.

Wenn man also den ersten Entwurf von „Team Topologies“ gelesen hätte, wäre das ziemlich schwer gewesen, denn er war – wie bei vielen, die noch nie ein Buch geschrieben haben – vom Aufbau her ziemlich akademisch, und die Lektoren bei IT Revolution – ein großes Dankeschön an sie – haben uns wirklich sehr geholfen. „Okay, lasst uns daraus eine richtige Erzählung machen, die die Leute konsumieren und später nachschlagen können“, wie du über die erste Auflage gesagt hast. Unser Ziel war es auch, ein Buch zu schaffen, das die Leute lesen und später wieder zur Hand nehmen können.

„Oh, ich erinnere mich an etwas aus Kapitel sechs, das für meine aktuelle Situation hilfreich sein könnte“, also als Anhaltspunkt. Sie haben also wirklich dazu beigetragen, diesen ersten Entwurf in eine viel bessere Version zu verwandeln. Und wir haben ihnen vertraut, denn am Anfang dachten wir: „Die wollen unser Werk zerstören.“ So fühlt es sich doch an, oder?

Wenn jemand sagt: „Du musst vieles von dem, worüber du in dem Buch schreibst, umformulieren.“ Ja, so war das ungefähr, und das hat meiner Meinung nach einen riesigen Unterschied gemacht, auch für den Erfolg des Buches – da bin ich mir sicher.

Ja. Und danke, dass du uns auch dieses Detail mitgeteilt hast. Die Zeit läuft uns davon.

Ich habe im Q&A eine Frage von Sabrina Sheila entdeckt. Wir haben keine Zeit, sie jetzt durchzugehen. Ich schicke sie dir, und vielleicht können wir sie dann privat beantworten.

Aber Manuel, ich möchte mir die Zeit nehmen, dir ganz herzlich dafür zu danken, dass du hier bei „Data Explored“ zu Gast warst. Ich hoffe, die Zuhörer konnten viel daraus mitnehmen. Ich jedenfalls schon.

Ich wünsche der zweiten Auflage viel Erfolg und – danke … dass ihr in Kontakt bleibt. Das werden wir.

Vielen Dank. Es war mir ein Vergnügen. Danke.