Evolution von Teamstrukturen

Anja Kammer: Hallo und herzlich willkommen beim INNOQ Podcast. Mein Name ist Anja Kammer und heute spreche ich mit Jakob Oswald zur Evolution von Team-Strukturen. Hallo Jakob. Jakob, erzähl doch bitte kurz von dir vor allem, was machst du aktuell bei INNOQ und weshalb treibt dich die Evolution von Teams denn um?

Jakob Oswald: Ja, hi, ich bin Senior Consultant und bin aktuell in verschiedenen Projekten tätig im regulierten Umfeld, komme aber eigentlich so aus dem Start-up-Umfeld und habe da auch schon Start-ups mit aufgebaut und das war eigentlich damals schon der Anstoß oder im Start-up möchte man wachsen und man fängt halt klein an. Man hat ein paar Leute und dann sagt man, okay, jetzt kommen Investitionen rein und wir stellen ein und am Ende des Jahres wollen wir irgendwie ganz groß sein und irgendwie ganz viel machen und das wird alles ganz, ganz klasse sein und in dem Moment schaut man sich halt um und überlegt, okay, jetzt sind wir halt irgendwie ein Team und jetzt sitzen wir zusammen in einem Raum, wenn wir jetzt am Ende des Jahres irgendwie ganz, ganz viele Leute sein wollen. Was machen wir dann eigentlich? Sitzen wir alle immer noch in dem Raum und wie arbeiten wir dann eigentlich zusammen und brauchen wir irgendwie neue Rollen oder eben neue Teams in dem Moment. Also die natürliche Evolution ist, glaube ich, in dem Moment, dass man sagt, man stellt Leute ein und stellt Leute ein und dann plötzlich sind es irgendwie mehr Leute. Und irgendwann merkt man, das passt halt nicht mehr. Da macht man irgendwie zwei Teams draus. Und ob man das jetzt geplant oder ungeplant macht, weil man merkt, das wird halt irgendwie zu schwierig, als ein Team zusammenzuarbeiten. Das ist halt, glaube ich, so ein bisschen der Punkt. Es ist ein Treiber für Veränderungen, eine Organisation wächst oder schrumpft vielleicht auch. Deswegen bildet man neue Organisationsstrukturen, neue Teams. Ich glaube, es gibt noch andere Treiber, gerade wenn es darum geht, zu sagen, wie strukturiert man sich, wie arbeitet man zusammen. Vielleicht ist es einfach clever, sich anders aufzustellen, weil man, sagt man, entwickelt neue Produktpartner oder hat eine neue Strategie oder irgendwas in die Richtung.

Anja Kammer: Und du bist ja Senior Consultant und berätst Unternehmen, also unsere Kunden, auch in diesen Fragen.

Jakob Oswald: Ja, also es ist meistens eher implizit. Ich mache jetzt in dem Sinne kein Organisations-Design, aber es ist natürlich immer was, wo man mit drauf guckt beim Kunden. Also wenn man das Gefühl hat, irgendwie dort gibt es vielleicht auch Dysfunktionalitäten, weil die Verantwortlichkeiten noch unklar sind oder Teams vielleicht sehr groß oder halt irgendwie nicht klar ist, wie Teams eigentlich miteinander kommunizieren oder interagieren sollten. Dann versucht man da schon so ein bisschen immer mit drauf zu gucken. Es ist auch einfach interessant, wenn man als Consultant zu einem Kunden kommt, sich da erstmal zu orientieren, wie sind die Leute eigentlich organisiert. Also das ergibt sich von außen erstmal so, in den meisten Fällen nicht. Und was man vielleicht bekommt, ist halt so ein Org Chart, was dann irgendwie die Personalführung abbildet, aber das ist dann vielleicht im Detailgrad irgendwie etwas anders oder klärt eigentlich im seltensten Fall, wie eigentlich die Teams miteinander zusammenarbeiten und interagieren, sondern das ist ja erstmal so eine formale Hierarchie in den meisten Fällen.

Anja Kammer: Und welche Methoden verwendest du da, um diese Umstrukturierung zu treiben? Wie gehst du da vor?

Jakob Oswald: Ich glaube, wichtig ist, dass man sich da erstmal einen Plan macht oder ein Bild, wo man eigentlich hinmöchte. Und wenn man dieses Bild hat, das eigentlich das zu externalisieren. Also die Sache ist die, dass man glaube ich oft über Dinge spricht, gerade was Teamstrukturen angeht oder Ziele angeht. Und das sehr schwierig ist, für alle Stakeholder zu greifen, was man damit meint oder wo man da eigentlich hinmöchte. Das heißt, das erstmal zu formalisieren, indem man das aufmalt oder aufschreibt, hilft extrem dabei, eigentlich allen Beteiligten sichtbar zu machen oder ist auch eine Diskussionsgrundlage dafür, wie man diese Sachen erreicht oder was man darüber eigentlich gemeinsam spricht. Also erstmal das zu externalisieren und ein gemeinsames Bild, eine gemeinsame Grundlage zu haben, ist sehr wertvoll.

Also eine Möglichkeit ist jetzt, ich male erstmal einfach Kreise vielleicht, um meine Teams abzubilden oder meine Organisationsstrukturen. Interessanterweise ist es so, wenn man zum Beispiel in ein Projekt kommt und sich erstmal einen Überblick verschaffen möchte, weil man die Firma, in die man reinkommt, ja erstmal originär nicht kennt, dann zu sagen, wie seid ihr eigentlich aufgebaut, wie seid ihr strukturiert, wie arbeitet ihr zusammen, welche Teams gibt es eigentlich, welche Organisationseinheiten und wie interagieren die miteinander. Und bestenfalls kriegt man oftmals einen Org-Chart vorgelegt. Das ist erstmal nicht schlecht, um eine Idee zu bekommen, ist aber in den meisten Fällen wie so ein typisches Org-Chart so eine Pyramide, die eigentlich die Personalführung abbildet. Das sagt aber oft nicht etwas darüber aus, wie die Teams zusammenarbeiten oder wie die eigentlich organisatorisch, sag ich mal, inhaltlich auf ihren täglichen Prozessen miteinander interagieren. Und das ist halt ein Bild, was in den meisten Fällen fehlt. Also diese Dinge rauszufinden und erst mal zu visualisieren, indem man halt einfach mal sich einen Miro oder ähnliches nimmt und da erst mal die Teams darauf aufzeichnet. Und was für Beziehungen, die zueinander haben, das ist so ein erster Schritt, um mal das ist zu haben, um dann zu sehen, wo kann man eigentlich hin oder passt das eigentlich.

Anja Kammer: Und Team Topologies hilft dir dabei?

Jakob Oswald: Also Team Topologies, also das Buch, hat ein sehr weites Feld. Und womit ich mich da in erster Linie beschäftige, oder was ich interessant finde, ist, dass sie halt, sie gehen erstmal einen Schritt weiter. Es ist nicht nur sozusagen ein Abbilden von welchen Teams gibt es eigentlich, sondern es werden gleich Teamtypen charakterisiert, vier Stück. Das sind die Platform Teams, die Stream-Aligned Teams, Complicated Subsystem Teams und Enabling Teams. Und denen werden schon bestimmte Charakteristiken zugeschrieben. Das heißt, da ist man schon aus dem Feld raus, zu sagen, was für Strukturen gibt es eigentlich, sondern die werden schon spezifiziert. Also diese Teams, das Buch bezieht sich, glaube ich, in erster Linie, kann man sagen, auf Softwareentwicklung. Das heißt, wenn man sich dort diese Teamtypen anschaut, dann bezeichnen die bestimmte Softwareentwicklungsteams mit bestimmten Charakteristika. Und das ist dann schon, sage ich mal, der zweite Schritt. Ich glaube, der erste Schritt ist, sich überhaupt eine Visualisierung davon zu machen, welche Teams gibt es und welche Organisationseinheiten gibt es und wie interagieren die, ohne dass man auf die Personalführungsebene schaut. Und ein zweiter Schritt kann dann eben sein, sich Team Topologies zu nehmen und diese Teams in diese Typen zu kategorisieren. Und der zweite Teil, der noch drinsteckt, ist neben den Teamtypen gibt es noch die Interaktionsmodi. Die Interaktionsmodi sind auch wieder charakteristische Kommunikationsmuster zwischen verschiedenen Teamtypen. Und das sind einfach beides, glaube ich, Muster oder Werkzeuge, die einem erlauben, über gemeinsame Dinge wieder zu sprechen. Also, so wie ich eine Organisationsstruktur erstmal externalisiert habe, indem ich das Bild visualisiert habe, habe ich, wenn ich denen eben diese Teamtypen zuordne oder explizite Kommunikationsmuster zwischen den Teams identifiziere, das externalisiert. Und wir können darüber sprechen, ob das dann so gewünscht ist, wie es ist und ob wir überhaupt die gleiche Einschätzung davon haben, ob diese Charakteristiken auf dieses Team passen oder nicht.

Anja Kammer: Hattest du jemals Schwierigkeiten, eine bestehende Teamstruktur oder eine bestimmte IT-Organisation mit Team Topologies abzubilden?

Jakob Oswald: Ja, es gibt, glaube ich, verschiedene Herausforderungen. Vielleicht gehen wir mal darauf ein, was diese vier Teamtypen, die dort vorgestellt werden, erstmal was für Charakteristiken, die so haben. Ich fange mal an, das Stream-Aligned-Team ist halt von seinen Charakteristiken her ein Team, was Produktentwicklung macht. Das heißt, das ist eigentlich sehr nah am eigentlichen Geschäftsfeld der Firma, die sind domänenorientiert. Heutzutage kann man sich oft darüber streiten, wenn man jetzt bei einer Bank ist, die sagen, wir sind kein Softwareentwicklungsunternehmen. Ich glaube, heutzutage kann man da oft widersprechen und sagen, wenn ihr das nicht seid, dann habt ihr ein Problem, aber im Kern der Sache machen sie natürlich Finanzprodukte. Und ein Streamline-Team, das beschäftigt sich halt mit dieser Bankfachdomäne im Kontext einer Bank und muss halt ein Domänenverständnis davon haben und hat halt den Anspruch, sage ich mal, den Markt zu verstehen und die Fachlichkeit zu verstehen und schnell eben diese Dinge, also Domänenfachlichkeit in Software zu gießen. Damit Sie das tun können, hilft Ihnen oft, wenn Sie gewisse Rahmenbedingungen haben. Also da kommt dann so was wie die Plattform- Teams ins Spiel, die dann halt sagen, okay, unser primärer Fokus ist es, eigentlich Plattformen zu bauen, auf denen diese Stream-Aligned-Teams arbeiten können. Also man versucht ein bisschen viele Dinge, mit denen ich mich beschäftigen muss, die vielleicht nicht domain- spezifisch sind. Das kann eben Betrieb sein oder das kann aber eben auch so was sein, wie kriege ich eigentlich meinen Bildprozess dann nachher in den Betrieb rein. Oder wie kann ich bestimmte Regularien abbilden, ohne dass sich jedes Team, was eigentlich, sage ich mal, Domänenfachlichkeit entwickeln soll, wieder neu damit auseinandersetzen muss. Sondern dass man sagt, es ist sinnvoll, Plattformen zu schaffen, auf denen diese Teams dann eben schnell arbeiten können. Und Plattformteams haben halt genau diese Charakteristika, dass sie sagen, sie beschäftigen sich jetzt vielleicht nicht mit der Fachdomäne der Firma, sondern vielleicht, sage ich mal, mit der Fachdomäne eigentlich Softwareentwicklung und Softwarebetrieb, wenn man so möchte und sind dann Dienstleister auch für diese Stream-aligned-Teams.

Anja Kammer: Ich habe da mal eine Frage an dich. Mir ist gerade eingefallen, ok, du hattest gerade gesagt, es kann viele Arten von Plattformteams geben. Also nicht unbedingt immer diese typischen Betriebs- und Infrastrukturteams, sondern kann es auch sein, dass beispielsweise es ein Plattformteam gibt, welches ein Redaktionssystem pflegt? Für eine Redaktion und die eigentliche Cash Cow, die eigentliche Fachlichkeit, der eigentliche Value Stream ist dann das Frontend, welches diese Artikel, die durch die Redaktion eingepflegt wurden, dann ausliefert. Wäre dann das Redaktionssystem eine Plattform?

Jakob Oswald: Ich glaube, die Grenzen verschwimmen da. Man kann genauso gut sagen, das Plattformteam ist ein Stream-aligned-Product-Team, weil eine Plattform am Ende auch ein Produkt ist, nämlich ein Produkt für die anderen Entwicklungsteams oder die Stream- aligned-Teams, die darauf aufsetzen. Von daher glaube ich, die eigentliche Charakteristik, die differenziert ist, ist sozusagen, dass Fachdomänen Wissen eins, was das Entwicklungsteam innehaben muss. Wenn das der Fall ist, dann würde das, glaube ich, unter Stream-aligned- Team quasi fallen. Also die Schnittstelle ist eigentlich eher, wer ist Endbenutzer deines Software-Produkts? Sind das wieder Entwickler und Entwicklerinnen? Dann ist mein Produkt halt eine Plattform für Software-Entwicklung. Also ich glaube, Plattform ist in diesem Kontext schon auf Softwareentwicklungs- und Softwarebetriebsplattformen spezifiziert. Ich kann wieder eine Plattform für andere Plattformteams bauen, wer dann sozusagen am Ende der Endkonsument ist und ob nicht alles Produkte sind. Ich glaube, das ist das, wo die Grenzen sich vermischen. Ich glaube, wirklich die stärkste Differenzierung liegt darin, habe ich Domainwissen in meinem Team, was halt oft vielleicht auch in Abstimmungen mit Fachbereichen, die keine Softwareentwicklung machen, quasi organisiert sein muss oder verstanden werden muss, dann würde ich sagen, es ist halt ein Stream-aligned-Team, zumindest in dieser Team Topologies-Klassifizierung. Wenn ich ein Produkt baue für Softwareentwicklerinnen und Entwickler, die halt in erster Linie Software bauen und betreiben, dann würde ich das als Plattform-Team nach Team Topologies klassifizieren.

Anja Kammer: Okay, also in dem Beispiel, was ich gebracht habe, wäre auch das Redaktionssystem eigentlich betreut von mindestens einem Stream-aligned-Team, nur dass die EndnutzerInnen eben nicht Endkundinnen sind, sondern eben die Redaktion. Weil es ist ja Fachdomänenwissen dabei.

Jakob Oswald: Genau, es ist Fachdomain-Wissen dabei. Es ist dann halt ein anderer Stakeholder-User-Type, sage ich mal. Aber es ist ein fachlicher. Ich muss Redaktion verstehen und ich muss verstehen, wie dort sozusagen die Domain-Zusammenhänge sind. Und ich beschäftige mich nicht damit, wie ich die Software per se oder Software per se quasi regulatorisch konform betreibe oder schnell in Produktion bringe.

Anja Kammer: Okay, also wir hatten jetzt zwei Teamstrukturen besprochen, bzw. zwei Teamarten besprochen, Stream-aligned-Team und Plattform Team. Was gibt es noch?

Jakob Oswald: Es gibt noch das Complicated Subsystem Team, die vielleicht ein Charakteristikum von diesen Stream-aligned Teams muss man oder sollte man da vielleicht noch ergänzen. Die Idee ist von so einem Stream-aligned Team, dass das diesen typischen Anspruch an Cross Funktionalität hat. Das heißt, dass ich alles im Team habe, alle Fähigkeiten im Team habe, um halt ein Produkt zu bauen. Also ich habe Frontendentwicklung, ich kann wie meine Datenbank weiterentwickeln, ich kann Backends entwickeln. Ich habe jemanden, der Produktmanagement da drin macht. Dazu zur Abgrenzung in diesem Complicated Subsystem Team. Das ist wieder die Idee, dass man sagt, es gibt bestimmte, im weitesten Sinne zur Fachdomäne zugehörige Komponenten. Also was kann sein wie irgendein Algorithmus für Autodespatching, also Fahrtendespatching oder irgendeine Berechnung für eine besonders komplizierte Rate oder ähnliches, wo ich sage, okay, es ist, ich habe Domain- spezifische Anforderungen, die sind aber so kompliziert oder komplex. Kompliziert ist das Complicated Subsystem Team. Ich sage, es ist sinnvoll, dieses sehr komplizierte Wissen wieder in eine eigene Komponente auszulagern und ein eigenes Team zu haben, was sich nur um diese Komponente kümmert. In vielen Fällen wird diese Komponente dann wieder von Stream-aligned Teams konsumiert, die sich dann halt eben eine gewisse komplizierte Thematik nur als Dienstleistung oder Konsument dieser Komponente dann wiederfinden, die aber vielleicht diese eben komplizierte Komponente nicht in der Tiefe durchdringen müssen. kann halt sein, eben wirklich sehr, sehr spezialisierte Dinge, wie ich schreibe irgendwelche Videocodecs oder sowas, und am Ende baue ich vielleicht eine Streaming-Plattform oder so, und wahrscheinlich sind davon 99% irgendwie, ich will jetzt nicht sagen, Standardanwendungsentwicklung, aber vielleicht Web-Anwendungsentwicklung. Aber sowas wie Videoencoding oder sowas ist sehr kompliziert. Ich habe in meinem Produkt damit eigentlich keine wirklichen Berührungspunkte, aber irgendjemand muss das tun. Und es macht vielleicht keinen Sinn, dass jetzt das Mobile Team und das Web-Team und das Setup- Box Team, jeweils unterschiedliche Konsumenten, sind alle ihr Videoencoding ein bisschen in die Tiefe verstehen müssen, sondern dann ist es vielleicht sinnvoll, ein Team zu haben, was eben dieses komplizierte Untersystem betreut und halt genau davon Ahnung hat und weiß, wie es das zu tun hat und optimiert und vielleicht aber vielleicht nicht so vertikal aufgestellt ist. Die werden wahrscheinlich eben keine Frontend-Entwickler oder so was haben oder keine Datenbankentwickler, weil die sich wirklich nur um genau diese Videoencoding oder ähnliches kümmern.

Anja Kammer: Okay, dann was ist mit dem vierten Team-Typ? Was ist das?

Jakob Oswald: Das vierte Team ist das Enabling-Team. Das sind Teams, die eigentlich dafür da sind, in andere Teams reinzugehen und dort Enabling zu betreiben. Also ein Charakteristikum ist dort in jedem Fall ein Wissensvorsprung, vielleicht für eine bestimmte Technologie oder ähnliches. Und sie haben auch noch im Vergleich zu anderen Teams ein abgrenzendes Charakteristikum ist, dass die meistens temporär aufgestellt sind. Also nicht temporär im Sinne von wegen des Teams gibt es nur kurz, sondern in meinem Verständnis temporär im Sinne von es ist so lange in der Interaktion mit anderen Teams, bis diese Aufgabe erledigt ist. Also so typische sag ich mal, Muster, die ich sehe, auch im Zusammenspiel dieser Teams. Es wird was Neues herausgefunden und ausprobiert. Es gibt so eine Discovery-Phase, da gibt es dann auch bestimmte Interaktionsmodi, die prävalent sind. Und innerhalb dieser Discovery-Phase eignen sich Leute Expertise an. Und man versucht dann halt irgendwie, man muss ausprobieren, was ist eigentlich das Richtige. Da tauscht man sich dort eng aus und irgendwann hat man irgendwie eine Idee und sagt, oh ja, das scheint sehr gut zu funktionieren. Und das hat man im Kleinen irgendwo ausprobiert und dann möchte man das in die Breite tragen und eigentlich sagen so, okay, wir haben jetzt rausgefunden, wie wir das richtig machen und machen wollen und auch in der Breite machen wollen. Und damit wir das dann eben in der Breite verfügbar machen, gibt es dann vielleicht aus dieser Discovery-Phase heraus irgendwie Experten, die sich als so ein Enabling-Team zusammentun und dann eben in andere Teams zum Beispiel reingehen und ihnen helfen dabei.Also sie enablen, diese neu gewonnen Erkenntnisse eigentlich selbst umzusetzen. Also ich bringe eigentlich den Leuten bei, eigenständig diese neuen Sachen zu tun. Ich kann das tun, also ich im Sinne von wegen jetzt als Teil des Enabling-Teams, weil ich dort Expertise aufgebaut habe und sobald diese Expertise dann in dem Team verankert ist, das ist diese temporäre Komponente, wechsle ich in das nächste Team oder das kann man natürlich auch parallel betreiben und geht dorthin und macht dort das Enabling.

Und wenn wir vielleicht dann auch an den Punkt kommen und sagen, okay, alle haben jetzt verstanden, wie Spring Boot eigentlich funktioniert, was wir jetzt gerade irgendwie neu eingeführt haben, weil vorher alle in JBoss oder in irgendeinem Enterprise Application Server gearbeitet haben, dann hat das Team vielleicht an der Stelle auch, sag ich mal, für die Thematik zumindest seine Berechtigung verloren.

Ich glaube, in den meisten Fällen ist es aber sinnvoll, solche Teams auch länger zu behalten, denn das nächste Thema kommt bestimmt. Es ist meistens so, dass diese Teams dann wieder eine Berechtigung finden und eigentlich das Ganze wieder von vorne losgeht. Die haben halt eher so einen Projektcharakter.

Anja Kammer: In der Praxis habe ich Enabling Teams eher so als Einzelkämpfer:innen kennengelernt, also so einzelne Personen, vielleicht zwei, zum Beispiel in Form von Security Expert:innen, die dann in Teams gehen und dort Threat Modeling machen zum Beispiel oder zur Autorisierung und Authentifizierung Schulungen geben oder coachen, bei der Implementierung sozusagen punktuell unterstützen. Und ich glaube schon in diesem Fall wäre es schon gut, wenn das langfristige mehr Ansprechpartner:innen sind. Weil es gibt immer irgendetwas Sicherheitsmäßiges zu tun.

Jakob Oswald: Definitiv. Es kommt wahrscheinlich auch ein bisschen darauf an, wie groß die Firmen sind. Ich vermute aber, dass es in den meisten Fällen genug Weiterentwicklung gibt. Software ist was, was lebt und sich manchmal auch zum Leitwesen schnell weiterentwickelt und man sich ja nie ausruhen darf und immer neue Dinge dazukommen. Ob das jetzt Security ist oder Regularien, die neu reinkommen oder eine neue Version eines Frameworks oder ähnliches. Also eigentlich bewegt sich das immer sehr schnell. Und gerade dafür ist es, glaube ich, sehr sinnvoll, Leute zu haben, die halt so ein bisschen diesen Enabling-Team-Charakter mitbringen, die da auch Lust zu haben. Da gehören halt zwei Sachen dazu, meiner Meinung nach, um das gut zu leben. Das eine ist die technische Expertise. Und das andere ist halt, glaube ich, auch der Spaß und vielleicht auch ein bisschen Didaktik, mit anderen Leuten zusammenzuarbeiten und zu sagen, komm, wir machen das jetzt mal. Das ist auch cool. Und wenn ihr das mal gemacht habt, dann seht ihr auch, dass das klasse ist, sich mit neuen Themen auseinanderzusetzen. Und es ist auch alles nicht so schlimm. Und lasst uns das mal zusammen anpacken. Also, ich glaube, das ist schon was, was man da mitbringen muss.

Anja Kammer: Und im Grunde gibt es jetzt diese verschiedenen Teamtypen, um das Stream-aligned Team zu unterstützen. Also das Enabling Team unterstützt das Stream-aligned Team mit Spezialwissen. Sozusagen, dass das Enabling Team sich selbst weiterbildet und dann sozusagen das Wissen in die Teams trägt. Das Plattform-Team unterstützt bei Betriebsaufgaben zum Beispiel. Eben alle Aufgaben, die nicht unbedingt zur Fachlichkeit gehören. Und das Complicated Subsystem-Team nimmt sozusagen auch die schwierigen Aufgaben weg, also diese starken, krassen Algorithmen, wo man wirklich, ja was man halt nicht immer so nebenbei machen kann. Habe ich das richtig zusammengefasst?

Jakob Oswald: Ja, ich glaube, das hast du genau richtig zusammengefasst. Ich glaube, wenn man das noch mal so zehn Schritte zurückgeht und fragt, warum macht man das Ganze eigentlich, ist es ja schon so, dass man eigentlich Softwareentwicklung ja nicht zum Selbstzweck macht, sondern es hat ja irgendwo einen Geschäftstreiber, der möchte irgendeinen Mehrwert stiften und dafür ist es halt in der Regel wichtig und sinnvoll, dass man halt diese Domain-Dinge, die Software, die Domäne abbildet, eben schnell weiterentwickeln kann, dort eben flexibel ist, autonom ist und deswegen braucht man halt genau diese Unterstützung. Der Mehrwert liegt eigentlich da drin, dass die Leute in den Stream-aligned-Teams schnell und agil entwickeln können und schnell liefern können und der Rest ist eigentlich Support dafür.

Anja Kammer: Gut, wir haben jetzt schon ein Stück weit Team Topologies erklärt. Und wie du schon sagtest, lass uns mal zum Anfang zurückkommen. Was ist jetzt eigentlich das Ziel? Wir hatten, also unser Thema ist ja Evolution von Teamstrukturen. Das heißt, wir haben einen bestimmten Zustand. Wir wollen den beschreiben. Und du hast gesagt, dazu nutzt du Team Topologies. Und dann haben wir vielleicht Zwischenschritte, bis wir zu einem Ziel kommen. Und auch das Zielbild kann man mit Team Topologies beschreiben. Sehe ich das so richtig? Ja.

Jakob Oswald: Das siehst du richtig. Ja, genau. Also es gibt noch eine Sache. Wir haben jetzt diese vier Teamtypen angerissen, worüber wir noch nicht gesprochen haben, ist die vier Interaktionsmodi oder zumindest die Interaktionsmodi, die dort noch mit drin sind. Ich weiß gar nicht, sind das vier? Also ich kann nur kurz sagen, welche mir einfallen. Das sind Collaboration, Facilitation, X-as-a-Service. Ich glaube, das sind nur drei. Oder habe ich jetzt einen vergessen? Also Kollaboration. Ich komme jetzt nochmal zurück auf diese typischen Muster, die ich sehe, im Sinne von wie etwas aus, so Proof of Concept. Und dann stabilisiert sich das Ganze und dann möchte man das ausrollen. Kollaboration ist halt oft in Phasen notwendig, wo man halt noch nicht so genau weiß, was man eigentlich machen möchte. Eine Kollaboration zeichnet sich dadurch aus, dass wir viel miteinander sprechen, dass oder dass man halt eben, sag ich mal, eine Interaktion hat, wo es keine klare Schnittstelle gibt. Es ist nicht so, ich möchte das, du gibst mir das, das ist beendet, sondern wir wissen vielleicht beide noch nicht so ganz genau, was eigentlich das Ziel ist. Also, so was wie eine ADR vielleicht zusammen verfassen und zu einer Entscheidung kommen, also zu sagen, okay, was sind denn eigentlich die Rahmenbedingungen und welche Optionen haben wir denn eigentlich und welche Vor- und Nachteile haben die denn in dem Moment, bis wir eine Entscheidung getroffen haben, müssen wir irgendwie kollaborieren. Und wenn ich kollaboriere, hat das auch ein paar Seiteneffekte, nämlich, dass ich Kommunikationskanäle verwenden sollte, die halt eben schnell einen Austausch zulassen. Das heißt, an der Stelle macht es eben vielleicht auch Sinn, zusammen in einem Raum zu sitzen. Das kann auch ein virtueller Raum sein. Und vielleicht aber auch tatsächlich in einem echten Raum. Wenn ich was Neues entdecken, entwickeln will, dann ist es irgendwie total hilfreich, wenn man gemeinsam einen Flip Chart malen kann oder sowas. Oder wenn ich irgendwas erzähle oder eine Meinung von mir gebe und man dann Rückfrage hat. Gerade diese Rückfragen sind Dinge, die sich erst im Gespräch und in der Kollaboration entwickeln. Das sind keine Dinge, die ich vorab weiß. Deswegen ist es, glaube ich, wichtig, dass man an der Stelle miteinander spricht, weil das halt eine Möglichkeit ist, genau, oder sag ich mal, eine Kommunikationsart, wie man diese Sachen gut adressieren kann. Wenn wir uns jetzt E-Mails schreiben in der Kollaboration, dann ist das meistens sehr schwierig, weil es plötzlich anfängt Seitenstränge aufzumachen. Ich weiß nicht, wann der andere antwortet. Ich kann mit meinem Gedanken gar nicht weitermachen, vielleicht ohne, dass ich einen Input von jemand anders bekommen habe. Das ist bei diesen anderen Interaktionsmodi vielleicht nicht unbedingt der Fall. Gerade dieses X-as-a-Service, also so dieses, ich biete eine Dienstleistung an. Wir haben was ausprobiert und entdeckt und jetzt haben wir eigentlich eine Idee, wie wir das umsetzen wollen und haben dann vielleicht auch ein Plattformteam, das sagt, okay, dieses Plattformteam hat jetzt rausgefunden, was es anbieten muss als Dienstleistung. Und wenn wir das einmal eingespielt haben, dann ist vielleicht die Anfrage, ich hätte gerne das, die Antwort darauf nur noch ein, das ist fertig oder das ist da für dich. Also so typischerweise sowas wie, ich brauche eine neue Datenbank, ich mache hier irgendwie meinen, wir haben uns darauf geeinigt, wir machen das mit Merge Requests. Terraform Module, ich schicke das in den Channel rein oder in die E-Mail oder sowas und dann drückt ihr mit auf Merge und ihr braucht eigentlich, wir brauchen nicht groß darüber reden, sondern dass es da ist, ist eigentlich schon quasi die Antwort und alle sind damit zufrieden. Das ist halt diese Dienstleistung. Da brauche ich vielleicht nicht diese schnelle Kommunikation und diesen direkten Austausch, sondern dort sind alle Kommunikationsmedien vielleicht auch legitim. Das liegt einfach in der Natur der Sache. Dann das dritte, was wir noch hatten, das Facilitation, das ist eigentlich genau das, was dass das Enabling-Team macht. Also ich facilitiere das in anderen Teams Wissen, umsonst, ich bin eigentlich dort, sie zu enablen, dass sie selbst dieses Wissen aufbauen. Ich helfe ihnen, dieses Wissen zu erlangen und das selbst anzuwenden. Das heißt, das ist auch das, was ich vorhin meinte, vielleicht braucht man oder es hilft halt ungemein, wenn man dort vielleicht auch ein bisschen eine didaktische Ader hat, oder zumindest gerne mit Leuten zusammenarbeitet und sagt so, hier, lass uns das mal zusammen ausprobieren und guck mal und fragst, was müsstest du jetzt eigentlich tun, damit das hinkommt? Erinnerst du dich noch am letzten Mal oder wo kannst du denn nachgucken oder so? Ist halt was anderes als, okay, hier kommt ein E-Mail, macht das mal und schickt zurück, ja, fertig. Also da brauche ich eine andere Form, vielleicht auch ein anderes Fingerspitzengefühl, um in diese Interaktion zu gehen.

Anja Kammer: Und wie hilft mir jetzt Team Topologies mit diesen Teamtypen und mit diesen Interaktionsmodi, also die Evolution meiner Teamstrukturen voranzutreiben? Also ich habe, wie gesagt, einen Ausgangspunkt und irgendein Zielbild. Also wie kann es mich dabei unterstützen?

Jakob Oswald: es ist unterstützt erstmal dabei halt genau diese Dinge explizit zu machen, dass ich halt erstmal überhaupt meine Teams verorte mit diesen Charakteristiken und die Kommunikationsmodi zwischen diesen Teams verorte und sage sind eigentlich die Charakteristiken sind die so klar? Also kann ich die Teams so einteilen oder sind vielleicht auch die Verantwortung? Ist die viel zu diffus? Das kann zum Beispiel schon ein Indikator dafür sein, dass der Teamschnitt nicht gut ist. Wenn ein Team, sage ich mal, zu viele Aufgaben hat und Facilitation macht oder Enabling macht und irgendwie eine Plattform baut und noch ein Produkt, dann ist das vielleicht schon ein Indikator dafür, dass ich hier keine klare, kein klares Ziel, keine klare Verantwortlichkeit in einem Team habe und vielleicht das Team anders organisieren sollte oder eigentlich in mehrere Teams organisieren sollte oder eigentlich mal klären sollte, was ist denn der Fokus oder was wollen wir als Team denn machen? Und überhaupt das halt erst mal zu visualisieren und allen Leuten ein gleiches Bild hinzulegen, über das man dann sprechen kann, das ist schon ein Riesenmehrwert.

Anja Kammer: Was mir da einfällt, ich habe diese Visualisierung mit Team Topologies auch mal verwendet bei einem Software-Review, wo es auch um soziotechnische Betrachtungen ging. Und genau dann haben wir auch Team Topologies verwendet und haben den aktuellen Ist-Zustand aufgezeichnet. Und es war sehr schwierig, dann genau wie du gesagt hast, so ein Team abzubilden, welches als Stream-aligned-Team sozusagen gesehen werden kann, aber auch als Plattform-Team. Und es war wirklich sehr schwer, dass wirklich dann in diese Nomenklatur zu pressen, denn man konnte dieses Team nicht wirklich klassifizieren, weil es so viele verschiedene Dinge gemacht hat. Und da hätte ich mir gewünscht, dass man dann doch von Team Topologies irgendwie weggeht. Also nur, wenn es um den aktuellen Zustand geht, weil es ebenso schwer da rein zu pressen ist, weil die Realität dann auch mal nicht ideal aussieht. Also diese Team Topologies-Team-Typen und die Interaktionsmodi, das habe ich so verstanden, dass es eher so ein Zielbild ist, aber in der Realität gibt es halt keine klare Abgrenzung von Verantwortlichkeiten so häufig.

Jakob Oswald: Ja. Das ist so, also ich sag mal so, die Stärke einerseits, das so klar zu codieren, ist natürlich auch eine Schwäche, irgendwie der Grauzonen. Aber es ist halt eben vielleicht auch schon Indikator, wenn man sagt, ich kann mich gar nicht entscheiden. Was das jetzt eigentlich ist, dass man dort einen Zettel dran macht oder halt irgendwie beide Farben verwendet oder halt irgendwie kenntlich macht, dass man eigentlich mehrere farbliche Kodierungen hier nutzen wollen würde, weil es eben nicht so klar ist. Ist aber, glaube ich, ein echt guter Ansatzpunkt, um mal das Team zu fragen, was macht ihr eigentlich? Und was ist euer Zweck? Was ist euer Hauptzweck als Team? Weil das, ich glaube, Verantwortungsdiffusion eine der größten organisatorischen Probleme ist. Sowohl im Sinne von einem Team hat zu viel oder unklare Verantwortlichkeiten und auch Verantwortlichkeiten werden hin und her geschoben. Also es ist, wenn Verantwortlichkeiten nicht klar verankert sind oder der Zweck eines Teams vielleicht nicht so klar ist, denn es ist auch sehr, sehr schwierig, auf ein Ziel hinzuarbeiten, weil das Ziel eben nicht ein Ziel ist, sondern vielleicht drei Ziele. Und genauso schwierig ist es halt irgendwie mit Leuten zu arbeiten, wenn sie sagen, ja, das ist gar nicht meins, geh doch mal zu dem Team. Die sind dafür verantwortlich und die sagen, ja, das sehen wir aber ganz anders. Wir sind auch nicht dafür verantwortlich. Also genau dieser Zweck eines Teams und die Verantwortlichkeiten eigentlich mal nachzuschärfen. Ich glaube, dafür ist es ein guter Impuls. Am Ende sind das meistens Impulse, die sich aus einer Landkarte ergeben, wo man sagt, ich habe da noch nie so drüber nachgedacht, weil mir das jetzt erst auffällt, wo ich es mal explizit sehe, dass wir hier vielleicht eigentlich zwei Teams haben oder es eigentlich irgendwie ziemlich ungünstig ist, dass wir hier ein Team haben aus drei Leuten, was eigentlich fünf Ziele bedient, weil die nie wirklich als Team irgendwo dran arbeiten werden können, weil wenn du so viele Ziele hast, dann kannst du dich nicht fokussieren.

Anja Kammer: Ja, und das ist schwer zu priorisieren. Okay, ich nutze es also als Kommunikationsmittel und zur Möglichkeit der Diskussion. Das heißt, ich brauche auch als Beteiligte in so einem Art Workshop wirklich alle, die ich da gerade aufzeichnen will. Das heißt, alle Teams, die ich gerade mit Team Typologies beschreiben möchte, die müssen auch da sein oder zumindest Vertreter:innen, damit ein klares Bild und damit eben die aktuelle Situation realistisch dargestellt wird, also auch realistisch. Wenn das Team nicht da ist, während es aufgezeichnet wird, dann wird es als Stream-aligned-Team klassifiziert. Dabei versteht es sich selbst eher als Plattform-Team zum Beispiel. Das würde nur rauskommen, wenn das Team oder Vertreter:innen dabei sind, wenn dieser Ist-Zustand aufgeschrieben wird.

Jakob Oswald: Also was ich auf jeden Fall nochmal aufgreifen möchte, ist, dass du gesagt hast, das ist ein Kommunikationsmittel und genau das ist es. Also für mich ist es in allererster Linie genau das, nämlich ein Kommunikationsmittel, was sehr einfach bestimmte Dinge zugänglich macht. Nämlich die Art von Team, also was soll mein Team eigentlich tun und wie interagiert das mit anderen Teams. Und das zweite, mit dem es sollten alle Stakeholder da sein, ja, also da gibt es glaube ich zwei Punkte. Ich glaube, es ist ein supergutes Kommunikationstool für viele Arten von Stakeholdern. Das kann nämlich einmal sein, so das Management, also ist es hier überhaupt, wie sehen eigentlich unsere Teamstrukturen aus? Sind wir uns einig darüber, dass das Ziel sein soll oder, dass das vielleicht gerade nicht gut ist, so wie es strukturiert ist? Da hängen ja dann vielleicht am Ende doch auch Personalführungsthemen drin oder andere Organisationsstrukturthemen, wo vielleicht jemand auch empfindlich ist, wenn man sagt, wir shiften jetzt Leute von dem Team in das Team oder so, weil er sagt ja am Ende, Ja, vielleicht aus nicht gutem Grunde brauche ich ganz viele Leute unter mir oder so, aber es ist halt wichtig, sozusagen das einmal auf dieser Management-Ebene sichtbar zu machen, denn es ist total wichtig für die Leute, die direkt daran beteiligt sind, also die in den Teams selber die das Team eigentlich ausmachen, die das Team konstituieren, dass die das eben auch so sehen und bestätigen und sagen, ja, das kann ja auch total spannend sein, dass die sagen, ah ja, okay, ihr habt uns jetzt so einsortiert, wir haben gar nicht das Selbstverständnis, dass wir irgendwie Dienstleister und as-a-service-Dinge tun. Auch da das Selbstverständnis irgendwie einen Impuls zu liefern, darüber zu reden. Und es gibt noch eine, vielleicht eine Schwäche, finde ich, ein bisschen von Team Topologies, nämlich dass tatsächlich die konkrete Art wie Verbindungen zwischen Teams visualisiert werden in Team Topologies, das eigentlich sehr schwierig macht, so große Landkarten zu malen. Also wenn man plötzlich mehr als drei oder vier Teams hat, dann wird es eigentlich schwierig, diese einfach grafisch-rechtwinkligen Kommunikationsbeziehungen, wie sie halt vorgegeben werden. Damit kann man halt keine großen Netze machen, wenn man jetzt plötzlich Teams hat, von denen mehrere abhängig sind. Gerade so, wenn ich ein Plattformteam habe, dann ist es ja bei größeren Organisationen so, dass die Plattform dann am Ende ja viele Entwicklungsteams bedient. Und das mal zu visualisieren, das ist mit den eigentlich vorgeschlagenen Visualisierungsmethoden schwierig. Ich wollte aber eigentlich darauf hinaus, dass es vielleicht auch gar nicht möglich ist, immer alle Leute in einem Raum zu haben. Wenn ich jetzt sage, ich habe ein Plattformteam und ich habe jetzt irgendwie fünf Stream-aligned Teams und alle bestehen aus fünf Leuten, dann packt die mal alle in einen Raum plus dann noch vielleicht Fach und Management. Das wird viel zu groß. Also ich glaube, oft muss man sich gezwungenermaßen darauf beschränken, dass man die Teams und die Schnittstellen zwischen den Teams über die man gerade konkret redet, versucht irgendwie ranzuholen oder prototypisch, wenn ich sage, ich habe ein Plattformteam, dass man dann halt, sag ich mal, als Vertretung von anderen Stream-aligned- Teams vielleicht Leute reinholt, aber du wirst wahrscheinlich nicht immer alle Stakeholder in einen Raum bekommen, je nachdem, wie du organisiert oder strukturiert bist. Das ist aber auch das Spannende an diesen ganzen Organisationsthemen, dass wir überhaupt Organisationseinheits- und Teambildung deshalb machen, dass wir am Ende ab einer gewissen Größe halt nicht mehr die ganze Organisation in einen Raum bringen und uns überlegen müssen eigentlich, wie machen wir Arbeitsteilung und wie organisieren wir die Leute, die die Arbeiten machen drum rum, weil das eigentlich so der Überbau des Ganzen ist. Wie organisiere ich Arbeitsteilung und ist das ein guter Schnitt für meine Arbeitsteilung, weil am Ende, wenn ich Arbeit teile, muss ich sie auch wieder zusammensetzen und da liegt dann eigentlich Kunst oder Schwierigkeit drin, den Schnitt in der Arbeit so zu machen, dass er gut auf meinen Organisationskontext passt und dass ich gute Prozesse und Kommunikationswege finde, um diese Puzzleteile wieder zusammenzufügen.

Anja Kammer: Jetzt wo du Arbeitsteilung sagst, ist es nicht ein Widerspruch zu den heutigen Trends der autonomen Teams oder dass Teams eigentlich von der Idee bis zur Auslieferung autonom alles entscheiden sollen, dürfen und alles können, sollen, können, dürfen, müssen?

Jakob Oswald: Ich glaube, darin liegt oft viel Missverständnis, weil ich glaube, man kann nicht alles können wollen. Es gibt ganz banale Sachen. Welches Software-Entwicklungsteam macht seine Lohnabrechnung selbst? Allein da macht man ja schon einen ganz bewussten Schnitt und sagt, ich habe hier mein Complicated Subsystem-Team auf organisatorischer Ebene, was Lohnbuchhaltung macht, und die kennen sich damit aus und das ist denen eigentlich vielleicht auch egal, was die anderen inhaltlich machen. Die wissen halt, wie ich die Lohnbuchhaltung zu tun habe. Das heißt, allein da baue ich ja schon organisatorisch, mache ich schon eine Arbeitsteilung, die sinnvoll erscheint in den meisten Kontexten. Und ich glaube, in der Softwareentwicklung ist es ähnlich und neulich auch was gelesen, also selbst bei cross-funktionalen Teams ist es ja nicht so, zumindest mein Verständnis ist nach, dass man sagt, alle im Team machen alles. Also es ist vielleicht ein interessanter Gedanke, aber die Idee dahinter ist ja eigentlich, dass ich sage, auch in dem Kontext mache ich vielleicht eine Arbeitsteilung, weil Leute halt irgendwie mehr Ahnung von Frontend haben oder manche vielleicht mehr Ahnung von CI/CD und andere vom Backend und andere von Produktmanagement oder ähnlichen oder UI, UX. Und dass ich es aber schaffe, die Leute halt so eng in eine, ich sag jetzt mal in semi-autonomem Kontext zu stecken, dass sie eben zusammen ein Produkt bauen können, was halt, dass sie viele Entscheidungen, die dieses Produkt anbelangt, mehr oder weniger autonom treffen können. Aber auch das funktioniert nur dann, wenn du dein Team und deine Software so geschnitten hast, dass sie eben diesen Produktprozess sinnvoll umspannt. Da kommen jetzt so Bereiche wie DDD rein. Und es ist ja trotzdem auch nicht autonom in den meisten Fällen, sondern man hat ja Abstimmungspunkte. Das Schlimmste habe ich leider auch schon bei Kunden gesehen, wenn man gesagt hat, jetzt kriegt hier jedes Team seine Ziele und alle verfolgen die ganz fröhlich und dann am Ende sagen zwei Teams, ja, okay, super, wir haben unsere Ziele erreicht und dann fragt man, okay. Und was macht man jetzt damit? Ja, das sind halt Bestandteile von irgendeinem Prozess. Und wie funktioniert der Prozess jetzt? Ja, der funktioniert noch nicht, weil die anderen Teams müssen das erst einbinden. Dann gibt es halt auch keinen Mehrwert. Der Mehrwert ist nur da, wenn der Gesamtprozess irgendwo funktioniert. Worauf will ich hinaus, dass man auch da natürlich am Ende eine Koordination hat und braucht. Und ich glaube, dass das eigentlich interessant ist. Wenn man weiter darüber nachdenkt, ist es überhaupt nicht verwunderlich, weil sowohl Software als auch Organisationsschnitt ja eigentlich Kommunikationsbeziehungen abbildet, dass man halt in diesen Kommunikationsbeziehungen nur sinnvolle, sage ich mal, Schnittstellen finden kann, wo man sagt, ich kann dünne Schnittstelle finden oder ich kann Prozessschnittstellen identifizieren, wo der Koordinationsaufwand gering ist, aber in den meisten Fällen nicht Null. Also die zu sagen, ich bin autonom ist utopisch, ich weiß auch nicht, ob es erstrebenswert ist an der Stelle, sondern meistens ist man ja irgendwie eingebettet in Kontext und kann halt nur versuchen, irgendwie seine Schnitte so zu machen und seine Team-Schnitte so zu machen, dass der Koordinationsbedarf möglichst gering ist. Weil dieser Koordinationsbedarf, das ist, was am Ende auch in der Softwareentwicklung, das ist, was bremst und wehtut. Es ist in den seltensten Fällen etwas, wo ich sage, okay, ich muss jetzt ganz viel programmieren, sondern die Todzeiten in so einem Prozess liegen ja in den meisten Fällen da drin, dass ich sage, ich muss mich mit irgendjemandem abstimmen und koordinieren. Und das ist das, wo halt lange ja, man vielleicht auch mal keine Antwort bekommt oder gerade, wenn ich abhängig davon bin, wenn ich abhängig davon bin, dass jemand in der Prozesskette was vor mir tut oder dass jemand mir eine Datenbank hinstellt oder irgendwelche anderen Dinge, da bin ich im Moment handlungsunfähig, dann kann ich noch so tolle Ideen haben, aber ich komme halt einfach nicht weiter, weil ich eben diese Abhängigkeiten habe. Das heißt, ich kann nur versuchen, diese Abhängigkeiten möglichst dünn zu machen und an sinnvollen Stellen zu platzieren.

Anja Kammer: Und genau dabei hilft Team Topologies sehr gut. Und deswegen verwenden wir und du auch Team Topologies, wenn wir über die Evolution von Teams nachdenken oder sagen wir so wie es ist, wenn wir darüber nachdenken, Teams umzustrukturieren, weil es eben überall durch diese Abhängigkeiten ein bisschen schmerzt und es da Wartezeiten gibt.

Lass uns mal dazu kommen. Ja, lass uns mal zu diesem Transformationsprozess kommen. Wie kann die Visualisierung oder wie kann die Kommunikation dieser Teamstrukturen dabei helfen, Schritt für Schritt eine Evolution von den Teamstrukturen zu implementieren, dass wir irgendwann einmal zu einem speziellen Zielbild kommen?

Jakob Oswald: Ich finde es interessant. Es gibt mehrere Herangehensweisen. Das eine ist, man malt auf was, wo man hinmöchte. Der nächste gedankliche Schritt ist natürlich, eigentlich muss man erstmal identifizieren, wo man steht, und dann gibt es da irgendwie ein Delta. Und dann muss man halt irgendwie schauen, wie komme ich eigentlich vom Ist- Zustand zum Soll-Zustand. Und je nachdem, wie stark die divergieren oder was da eigentlich drin liegt, gibt es, glaube ich, Punkte, die man auch wieder explizit machen kann oder sollte eigentlich. Denn es wird halt selten so sein, dass man sagt, okay, heute stehen wir hier und da wollen wir hin. Und jetzt in sechs Monaten sind wir in dem Ziel. Und dann ist halt die Frage, okay, was müssen wir eigentlich tun, um da hinzukommen? Wann müssen wir vielleicht Kommunikationskanäle ändern? Oder gibt es andere Dinge, die wir ändern müssen? Es hilft ungemein, sich mal verschiedene Zwischenschritte zwischen dem Ist und dem Soll zu skizzieren und auch dann wieder darüber zu diskutieren, was bedeuten diese Zwischenschritte eigentlich. Also wenn ich jetzt, wenn ich aus einem Team zwei mache, dann ist ja die Frage, wenn vorher dieses eine Team irgendwie ansprechbar war über einen Kommunikationskanal, sei das jetzt ein Slack-Channel oder ein E-Mail-Verteiler oder was auch immer, dann brauche ich ja plötzlich, muss ich überlegen, wie gehe ich denn damit um, wenn es jetzt plötzlich zwei Teams sind? Also wie ist das zweite Team von außen kontaktierbar? Wie mache ich das publik? Wie gehe ich damit um, wenn Anfragen wieder an das erste Team geleitet werden und so weiter? Es können auch banale Sachen sein, wenn ich Wachstum habe oder wenn ich aus dem ein Team zwei mache, sollen die weiter am gemeinsamen Tisch sitzen oder stört das die Arbeitsatmosphäre, weil die Leute über plötzlich unterschiedliche Sachen reden, aber immer quasi quer gegenseitig reinreden oder so, ist es sinnvoll, sich vor Ort oder strukturell anders zu positionieren. Und auch dieses, ab wann werden Verantwortung von einem Team in ein anderes geschoben oder ähnliches. Oder auch diese Dinge. Und wenn man das wieder explizit gemacht hat und gesagt hat, das ist unser Zielbild, da wollen wir vielleicht in zwölf Monaten sein. Was passiert denn in drei Monaten? Was passiert in sechs? Und was passiert in neun? Und es hilft halt auch zum Beispiel nach außen zu kommunizieren. Hier gibt es eine Veränderung. Da kann sein, dass jemand sagt, hey, das ist super toll, was ihr da macht. Aber wollt ihr das nicht vielleicht lieber statt auf den 15. September, auf den 3. Oktober, 3. Oktober ist Feiertag. Ein paar Tage später legen, denn wir haben da irgendwie gerade ein großes Release und das wäre echt irgendwie mega blöd, wenn wir da auf die Nase fallen und plötzlich gar nicht wissen, mit wem wir sprechen sollen oder die Zuständigkeiten noch nicht so klar sind, weil es gerade in dem Moment irgendwie eine Umstrukturierung gab. Auch da sag ich mal, im organisatorischen Kontext mal explizit zu machen, dass es diese Umstrukturierung gibt und zu welchen Zeitpunkten man sich überlegt, was man eigentlich verändern möchte, dass, wie gesagt, Kommunikationskanäle, Personentausch, Rollentausch oder ähnliches oder Rollenveränderung, das hilft halt ungemein, dahin zu kommen. Da ist auch diese typische So Discovery und dann irgendwie aufbauen vielleicht vom Plattformteam und Rollout-Phase, das halt mal zu zeigen, wann wird aus einem Team vielleicht zwei oder wann wird das neue Team etabliert, ab wann wechseln die Verantwortlichkeiten und wie ist dann der Prozess, diese Leute zu adressieren, wenn halt irgendwie ich Fragen hab oder was schiefläuft. Das sind halt Dinge, über die man sich dann vielleicht expliziter Gedanken macht in dem Moment, wo man halt mal sagt, okay, in drei Monaten passiert genau das.

Anja Kammer: Ich kann mir auch vorstellen, dass es gut ist in der Entscheidungsphase, wenn man überhaupt sich Gedanken darüber macht, welche Schritte sind, eigentlich denkbar, die wir gehen können. Es gibt mit Sicherheit auch Alternativen, wie man zum Ziel kommt. Und diese zu visualisieren und gegenüberzustellen, das kann ich mir auch sehr hilfreich vorstellen.

Jakob Oswald: Ja, auf jeden Fall. Also Optionen zu zeigen und die zu diskutieren. Auch das macht es, also wenn man die explizit hat, also geht ja auch ein bisschen in die Richtung von ADR, wo ich mal explizit die Option aufschreibe und mir mal Gedanken darüber mache, was sind denn die Vor- und Nachteile der Option und mich dann explizit für eine entscheide, das ist da genauso. Wenn ich das mal hingemalt habe, eine vorherige, ich sag mal, Sprache ist vielleicht nicht immer schwammig, aber das Bild, was in den Köpfen entsteht, ist halt unter Umständen anderes. Und das kann man halt schwer validieren. Wenn ich dir jetzt was erzähle und vielleicht noch fünf anderen Leuten oder zehn anderen Leuten und wir gucken uns alle in die Augen und sagen, ja, wir meinen alle das Gleiche und nicken. Und dann schickst du jeden in einen eigenen Raum und er soll das mal aufmalen und kommt wieder zurück. Dann ist man, glaube ich, erstaunt, wie unterschiedlich die Bilder dann vielleicht sind. Weil man zwar meint, ein gemeinsames Bild zu haben, also sprichwörtlich ein gemeinsames Bild zu haben, aber es ist, glaube ich, oft nicht so. Und dieses Aufmalen und Visualisieren, ist halt super dafür, um zu validieren, dass wir wirklich über die gleichen Sachen sprechen. Und das macht es dann eben auch einfacher, Optionen explizit zu machen oder halt mal Optionen aufzuzeigen und vielleicht auch die Abgrenzung zwischen verschiedenen Optionen explizit zu machen.

Anja Kammer: Lass uns mal konkreter werden. Du hast so eine Transformation mitgemacht und begleitet. Magst du oder kannst du erzählen, was das genau für Teams waren, die du da umstrukturieren musstest und was es da für Schwierigkeiten gab und welche Meilensteine es gab?

Jakob Oswald: Ja, es war tatsächlich weniger eine Umstrukturierung der Teams. Also, kann man auch so nennen. Wir sind als Projekt zu einem Kunden gekommen. Und eigentlich ging es darum, dass man gesagt hat, man möchte Verantwortlichkeiten verschieben. Beziehungsweise die Verantwortlichkeiten waren doppelt vergeben. Man hat gesagt, man hat das halt getrennt nach Betriebsumgebung und gesagt, es gibt halt irgendwie Dinge hier in der Cloud und es gibt hier Dinge on-premises. Aber eigentlich haben beide in ihrer Software bestimmte Anforderungen, also was Sicherheit, Softwarequalität, Lizenzmanagement oder ähnliches angeht. Und man hat gesagt, ja, eigentlich macht diese Trennung keinen Sinn. Nein, eigentlich möchte man das zentralisieren. Eben auch als Dienstleistung für die Entwicklungsteams, dass sie sagen, sie müssen sich selbst, vielleicht im Großteil dieser Dinge, also die selber zu implementieren, keine Gedanken machen. Müssen aber jetzt auch nicht immer überlegen, okay, bin ich jetzt in der Cloud oder bin ich jetzt on-premise oder gibt es eben, divergieren die Prozesse und das Tooling dort und man hat gesagt, okay, wir wollen das konsolidieren. Aber es gibt trotzdem Unterschiede, gerade auf der Betriebsseite. Das heißt, wir haben die Verantwortlichkeiten des Build-Prozesses in einem Team konsolidiert und haben das Cloud Deployment aber im Cloud Team belassen und dann quasi eine Schnittstelle in den CI/CD Pipelines geschaffen. Das heißt, am Anfang hatten wir die Herausforderung zu sagen, wie trennen wir eigentlich das Softwareprodukt auf?

Wer ist für welchen Teil davon verantwortlich, also Softwareprodukten in diesem Kontext, die CI/CD-Pipeline? Wer ist für welchen Teil der Pipeline am Ende verantwortlich, welches Team? Und wie interagieren diese Teams dann, wenn die Pipeline, die ja am Ende wieder für die Entwicklerinnen und Entwickler aus einem Guss sein soll, die wollen nicht wissen, dass quasi das eine Team den Build betreut und das andere Team das Deployment, sondern für die soll das halt quasi eins sein. Wie gehen wir damit um? Und wann kündigen wir eben zum Beispiel auch die alten Pipelines ab? Das sind halt genau diese Dinge, über die man sich vielleicht keine Gedanken macht. Wenn man so darüber redet, wie gehen wir eigentlich damit um, dass wir so etwas wie Discontinuation machen? Wann kündigen wir alte Produkte ab und wann sind Teams nicht mehr dafür verantwortlich. Und da haben wir halt am Anfang so eine typische Kollaboration gehabt und gesagt, okay, wir sind uns noch gar nicht so sicher, wie wir das eigentlich machen wollen. Und haben halt einmal, also das Zielbild war relativ klar irgendwann und gesagt haben, Der Deployment-Teil liegt in dem einen Team und der Build-Teil, inklusive Scanning und so weiter, liegt halt irgendwie in einem anderen Team. Und jetzt ist halt die Frage, wie kommen wir denn jetzt dahin? Es gibt unterschiedliche Build-Pipelines und was machen wir jetzt eigentlich? Und wer ist wann für welchen Teil verantwortlich? Oder wie ziehen wir das auseinander und bauen es eigentlich wieder zusammen? Nachdem auseinanderziehen und wir zusammenstecken, müssen wir irgendwie eine Schnittstelle definieren auf Software- Ebene und wie verständigen wir uns darauf, wie die eigentlich aussehen sollte. Und am Anfang war klar, wir machen dort Collaboration, wir sind da sehr eng getaktet, wir haben einen hohen Abstimmungsbedarf, wir haben Regeltermine, reden darüber und machen das eigentlich im Verbund. Ab einer Phase X wird dann die Verantwortlichkeit komplett in das eine Team geschoben, mehr oder weniger. Oder zumindest sollen die Fragen dazu erst mal dort landen und dort wird dann quasi evaluiert, ob die Anfrage dahin passt oder nicht und einen eigenen Teams-Channel etabliert und gesagt, ab hier soll jetzt bitte dieser neue Pipeline verwendet werden und wir sind jetzt hier die neuen Ansprechpartner und dann sind wir halt irgendwann dahin gekommen, dass wir gesehen haben, okay, jetzt funktionieren die Sachen grundlegend, wir haben die vertestet und das war dann halt irgendwie genauso eine Discovery-Phase, haben die mit irgendwie einem Pioneer Team quasi verprobt. Das ist dann die zweite Schnittstelle gewesen, wo wir Kollaborationen hatten am Anfang. Und dann wurde das ein bisschen stabiler. Dann haben wir gemerkt, wir brauchen diese Regeltermine nicht mehr. Das hatten wir tatsächlich auch so aufgemalt und vorher so skizziert, dass wir gesagt haben, irgendwann sind auch die beiden Teamschnittstellen, die die Pipeline in ihren Einzelteilen verantworten. Das ist dann am Ende nur noch eine Dienstleistung, weil die Schnittstelle ist definiert. Klar gibt es hier unter Abstimmung, wenn man was am Deployment-Prozess ändern möchte, obwohl wir es tatsächlich sehr wenig hatten am Ende, also der Schnitt hat sehr gut funktioniert. Aber halt genau dieses ab wann ist man dafür verantwortlich oder wann stellt auch zum Beispiel das Cloud Team Support für die alten Pipelines an, dass man genau diese Sachen explizit gemacht hat, wie gesagt haben, das ist der erste Schritt, wir verproben das, wenn wir das verprobt haben, dann gibt es auch ein explizites Projekt, wo es quasi ein Enabling Team gibt, was halt die neue, die neue Pipeline in die Teams trägt, also in die Stream-aligned-Teams trägt und dort eben zeigt, wie wird das verwendet, was habt ihr zu tun, was müsst ihr machen bei der Umstellung, wie funktioniert das eigentlich grundlegend. Und dann eben auch sozusagen diese explizite Trennung an Kommunikationskanäle zu hier ist Pipeline und hier ist Cloud und alles was Pipeline ist. Also wo man sagen muss, dass das intuitiv passiert ist, dass man gesagt hat, irgendwann die Fragen zur Pipeline landen dann halt irgendwie in dem einen Channel. Und ja, wenn es dann halt in die Kubernetes relevante Dinge sind, dann landen die automatisch wieder im Cloud- Team und war jetzt auch nicht so wild, wenn also die Teams waren da sehr eng oder sind da sehr eng und wenn man dann halt irgendwie identifiziert, ja, das sieht vielleicht erstmal so aus, als ob das bei uns liegen könnte, weil der Deployment-Step in der Pipeline ausgeführt wird, aber eigentlich können wir da gar nichts dran machen, weil das halt irgendwie am Deployment, im Kubernetes-Cluster liegt, dass man dann sagt, hey, es sieht jetzt so aus, aber frag doch mal bitte in dem anderen Channel nach, weil das ist halt was, wo wir gerade gar keine Kontrolle drüber haben. Aber es ist trotzdem richtig, dass du hier gefragt hast und es ist genau in Ordnung so. Wir haben jetzt das Assessment gemacht und es ist dann halt vereinzelt mal so. Aber zu 99% werden die Sachen auch in den richtigen Channeln adressiert.

Anja Kammer: Das bedeutet, das Projektziel wurde erreicht. Das heißt, der Plan wurde schrittweise geplant oder durchgeführt und am Ende lief alles so wie geplant.

Jakob Oswald: Es läuft noch, wie geplant, mehr oder weniger. Es ist tatsächlich ein bisschen größeres Unterfangen, weil ich glaube, das müssten so um die tausend paar zerquetschte Projekte sein. Es sind halt mehrere Stream-aligned Teams daran beteiligt und dadurch, dass wir im Projekt halt auch nur eine gewisse Kapazität. Also das Enabling-Team hat auch nur eine bestimmte Kapazität, kann man halt nicht bei allen auf einmal machen. Und wie es halt auch oft so ist mit, sag ich mal, Abkündigungen alter Software, dann sagt man, ja, ihr könnt das noch benutzen, das ist nicht mehr supported. Und dann sagt man, aber dann schalten wir es ab. Und dann sieht man halt, also wir haben, ein Kollege von uns hat irgendwie ein Danke, Daniel, an der Stelle ein super automatisiertes Reporting gebaut, wo man immer quasi sieht, wer benutzt eigentlich noch welche Pipeline-Artefakte. Und dann sieht man halt ja, okay, es tut sich nichts, die Deadline nähert sich und dann will man ja auch irgendwie nicht den Leuten ihre Software von heute auf morgen, also von heute auf morgen war es ja nicht, aber man möchte ja dann auch nicht den Leuten vor das Schienbein treten und sagen, jetzt funktioniert alles nicht mehr. Aber wenn man dann zweimal oder dreimal schon gesagt hat, jetzt ist aber wirklich aller, allerletzte Warnung, immer in dem Wissen, dass wenn man das jetzt abschaltet, höchstwahrscheinlich es sein kann, dass man nochmal zurückdrehen muss, aber irgendwann ist es auch mal gut. Wir haben dann auch die alten Cloud Pipelines dann abgeschaltet und tatsächlich hat sich keiner beschwert, erstaunlicherweise. Wir mussten aber dazu sagen, wir haben das auch immer mal wieder verlängert. Aber das sind halt Prozesse, die ziehen sich so ein bisschen. Das ist halt einfach manchmal nicht so leicht, je nachdem, wie groß der Kontext ist, indem man sich bewegt. Gerade so eine Veränderung auszurollen, dauert halt manchmal eine Weile. Aber es hat erstaunlich gut funktioniert und ich fand auch, diese Methodik, das eben aufzumalen, wo sind wir, wo wollen wir hin. Also es gab gerade in diesen Zwischenphasen, ab wann ist wer denn eigentlich für welchen Teil verantwortlich, das aufzumalen und das zu diskutieren, hat unglaublich dabei geholfen, glaube ich, auch die Teams abzuholen und dann quasi ein gemeinsames Verständnis zu haben, okay, ab wann können wir das oder müssen wir dann bestimmte Dinge auch leisten? Und ab wann können wir dann auch sagen, ja, das ist nicht mehr unsere Baustelle, geht bitte zu dem anderen, ohne dass die dann eben sagen, ja, ne, aber wir sind noch gar nicht bereit, geht doch wieder zu denen. Also, dass es eben genau diese Verantwortungsdiskussionen nicht gibt. Das hat eigentlich sehr, sehr gut funktioniert.

Anja Kammer: Sehr gut. Lag vielleicht an der guten Kommunikation und Vorbereitung und Planung.

Jakob Oswald: Eigenlob und so, aber deswegen möchte ich mich dazu nicht weiter äußern.

Anja Kammer: Okay. Haben wir denn alles besprochen für diesen Podcast?

Jakob Oswald: Ich glaube, es gibt noch ganz, ganz viel, über das man reden könnte. Ich nehme aber an, für heute ist es genug, wenn du jetzt keine weiteren Fragen vorbereitet hast.

Anja Kammer: Okay. Ich habe so viele Fragen, aber wie du sagst, ich glaube, für heute ist genug und für die anderen Fragen haben wir noch später genug Zeit. Dann bedanke ich mich auf jeden Fall für das Gespräch. Ich habe sehr viel gelernt. Vielen Dank, Jakob.

Jakob Oswald: Ja, sehr gerne. Es hat mir sehr viel Spaß gemacht. Ciao.

Anja Kammer: Bis dann, ciao.