Evolution von Teamstrukturen – Teil 2

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Anja Kammer: Hallo und herzlich willkommen zum INNOQ Podcast. Mein Name ist Anja Kammer und heute habe ich mir Jakob Oswald eingeladen. Hallo Jakob.

Jakob Oswald: Hallo Anja.

Anja Kammer: Wir hatten schon einmal einen Podcast gehabt und über Teamstrukturen gesprochen, beziehungsweise über die Evolution von Teamstrukturen. Wir haben so Dinge geklärt, welche Rolle Team Topologies überhaupt in unserer Arbeit spielt. Es ist eine gemeinsame Sprache, wir haben über die Teamtypen gesprochen, aber viel wichtiger noch die Interaktionsmodi und vor allem, dass Team Topologies eine Methode ist, um die Kommunikation innerhalb einer Organisation zu verbessern.

Jakob Oswald: Ja, es ist ein Kommunikationswerkzeug in erster Linie, um zu zeigen, wie Organisationen aufgestellt sind oder wohin man Organisationen entwickeln möchte, wie sich Teams verändern können und wo sie stehen.

Anja Kammer: Genau, es ist ein Kommunikationswerkzeug, es visualisiert und es hilft vor allem, hattest du dann auch gesagt, den Ist-Zustand der aktuellen Organisation mit Team Topologies, also mit diesen Team Topologies Typen und Interaktionsmodi, aufzumalen und auch Zwischenschritte zu einem Zielbild zu visualisieren, um diese Meilensteine, die man auf dem Weg zu einer Transformation einer Organisation hat, darzustellen und anhand dessen diskutieren zu können.

Jakob Oswald: Ja, genau, ich glaube, es ist genau, was du gesagt hast, ist wichtig, dass man diese Ideen und diese Schritte explizit macht, weil dann kann man gut darüber reden. Wenn man eine Idee hat und die teilt, dann kann es sein, dass jeder im Kopf ein eigenes Bild hat. Wenn man es einmal für alle hinmalt, dann hat man zumindest eine ähnliche Idee, über die man spricht. Sonst ist es, glaube ich, immer sehr vage. Hier ist explizites Wissen, die Idee explizit zu machen oder das, was man vorhat, explizit zu machen, ist einer der Schlüsselfaktoren dabei.

Anja Kammer: Und dann haben wir noch kurz über typische Stolpersteine gesprochen. Da ging es vor allem um unklare Verantwortlichkeiten oder auch generell die Kommunikation, also wie Teams am besten miteinander kommunizieren, und das hat auch viel mit den Kommunikationsmodi zu tun. Das heißt, wenn ihr euch dafür interessiert, was wir im ersten Teil besprochen haben und diese Zusammenfassung nicht genug für euch war, dann hört da gerne mal rein. Heute werden wir weiter in die Stolpersteine gehen, in die Probleme gehen, auch bei der Implementierung einer Transformation mittels Team Topologies.

Jakob Oswald: Genau, ich glaube, es gibt viele Hindernisse aus verschiedenen Gründen, die eine solche Veränderung schwer machen, gerade vielleicht auch für uns, die wir eher aus einer Software-Ecke kommen. Wir machen ja alle kein Change Management in dem Sinne so explizit, oder viele von uns haben es ja nicht so explizit gelernt und kommen aber dann trotzdem immer wieder in die Verlegenheit zu sagen, wie wollen wir denn eigentlich miteinander kollaborieren oder eben miteinander interagieren und wie sieht das eigentlich aus und wie stellen wir Teams eigentlich sinnvoll auf?

Anja Kammer: Ja. Wir hatten uns überlegt, welche Themen wir in der zweiten Folge besprechen wollen, und dann hattest du gesagt, ja, da gibt es so einen Comic Strip, und das wollen wir gerne mal besprechen als Aufhänger dieser heutigen Folge, weil das im Grunde das trifft, was wir heute besprechen wollen. Es ist ein Comic Strip, das werden wir auch noch in den Shownotes verlinken. Es zeigt, wie Team Topologies eher nicht implementiert werden sollten. Du meintest auch, dass Team Topologies dem Cargo Culting zum Opfer fällt, das heißt, Team Topologies macht man heutzutage, wir benennen unsere Entwicklungsteams um in stream-aligned Teams und unsere Operation Teams nennen wir in Plattform Teams um, und dann sind wir schon auf dem halben Wege Team Topologies zu implementieren. Also so ist es nicht. Wollen wir kurz mal diesen Comic Strip erklären?

Jakob Oswald: Ja, sehr gerne. Also das ist von Comic Agilé. Ich habe wirklich gelacht, weil es den Nagel auf den Kopf trifft. Da sind die vier Teamtypen abgebildet, mit ihren Überschriften und dann noch mal, was sie eigentlich machen oder was sie im schlimmsten Falle machen. Das Stream-Aligned Team sagt: „We are so cross-functional and generalized that we are not really good at anything.” Also das Stream-Aligned Team ist so breit aufgestellt, dass es eigentlich gar nichts wirklich gut kann. Das Enabling Team sagt: „We are supposed to teach our competencies to the other teams, but we just do the work ourselves, it’s much faster.” Auch das, glaube ich, ist so ein typisches Ding. Eigentlich hat man den Auftrag oder möchte Wissen an andere Teams verteilen und sie enablen, und ja, es ist dann manchmal gar nicht so leicht, Wissen zu vermitteln. Auch das, wenn man jetzt den technischen oder den Informatiker-Hintergrund hat, dann lernt man ja vielleicht auch nicht unbedingt Didaktik oder so etwas mit, und dann kribbelt es einen manchmal vielleicht schon in den Fingern zu sagen, oh Mann, bevor ich jetzt hier viele Stunden und Tage sitze und das jemandem beibringe, hätte ich das auch schneller eigentlich selber umsetzen können. Dann ist das Projekt schneller vorbei, ja.

Anja Kammer: Ja, vor allem, weil Enabling Teams ja gerade aus Fachexpertinnen bestehen, die es wahrscheinlich dann wirklich besser können, nicht wahr?

Jakob Oswald: Ja, ich glaube, Enabling Teams ist tatsächlich auch eines der schwersten, weil sie eben nicht nur die Kompetenz, also das Inhaltliche zu verstehen und zu können, mitbringen müssen, sondern eben auch die Kompetenz, zu kommunizieren und enablen zu können, also Wissen vermitteln zu können und andere Leute mitnehmen zu können, so dass sie dieses Wissen dann eben selbst anwenden können. Das ist tatsächlich manchmal gar nicht so trivial, nicht wahr?

Anja Kammer:

Jakob Oswald: Dann gibt es das Complicated Subsystem Team, das sagt: „People think that our system requires very advanced competencies, but we just don’t want to share our knowledge.”

Anja Kammer: Ja, und man muss dazu sagen, es sind eher ältere Menschen darauf zu sehen. Also sehr alte, nicht wahr?

Jakob Oswald: Ja, ich kann mir schon vorstellen, dass das vielleicht auch so ein bisschen darauf abzielt, so, nicht wahr, irgendwo gibt es noch vielleicht einen Mainframe und so etwas, und es ist wesentlich einfacher, da drin hat man sich vielleicht irgendwie eingerichtet und kennt sich in seinem COBOL Code oder ähnlichem aus, und bevor man jetzt anfängt, mit irgendwelchen Leuten inhaltlich darüber zu sprechen, wie funktioniert das eigentlich, und sich jetzt auch noch die Mühe machen muss, vielleicht das irgendwie neu zu implementieren, bleibt man vielleicht lieber in seinem speziellen Rahmen und sagt, ja, ich mache das dann für dich, komm einfach zu mir, wenn du was brauchst. Aber das birgt natürlich auch die Gefahr, wenn das Team sich dann mal auflöst oder in Rente geht oder die Leute weggehen, dann bleibt Wissen vielleicht auch auf der Strecke, ja, also das sind natürlich auch so Gefahren, die da drin lauern.

Anja Kammer: Man muss aber dazu sagen, dass selbst im Team Topologies Buch, das Complicated Subsystem Team und auch in Interviews von den Autor:innen immer wieder gesagt wird, ja, es ist schon ein halbes Anti-Pattern, dass es ein Complicated Subsystem Team gibt, also lieber habt so etwas nicht. Man erstellt ein Complicated Subsystem Team nur, wenn es wirklich nicht anders geht und nicht bei jeder Gelegenheit, ach, das ist so kompliziert, da machen wir jetzt mal ein Complicated Subsystem Team draus. Das heißt, es gibt wirklich wenig Gründe, so ein Team zu bilden. Gut und das letzte Panel?

Jakob Oswald: Ja, das letzte Panel zeigt das Plattform Team und das sagt: „Without us, the Stream-Aligned Teams couldn’t deliver any value. Also, we hate talking to end users and all other people.” Also die sind irgendwie auf der einen Seite etwas elitär, sage ich mal, weil ohne sie wird da gar nichts laufen und eigentlich haben sie aber überhaupt keine Lust, mit irgendjemandem zu reden und würden am liebsten nur an ihrer Plattform schrauben. Das ist natürlich auch fatal, wenn man eigentlich daran denkt, dass das natürlich auch ein Produkt ist und auch die Stream-Aligned Teams irgendwie dann Kunden von dem Produkt sind und man eigentlich dieses Selbstverständnis Dienstleister haben sollte, nicht wahr? Also man bietet eine Dienstleistung an andere Teams an und nicht jetzt geh weg mit deinen Bedürfnissen, sondern eher zu verstehen, was brauchen die eigentlich und auch da quasi eigentlich Produktmanagement zu machen.

Anja Kammer: Ja.

Jakob Oswald: Ja, muss man halt auch erstmal verinnerlichen, dass man dann doch auch irgendwie wieder ein Produktteam ist, nicht wahr?

Anja Kammer: Ja. Dieser Comic Strip zeigt schon die häufigsten Kritikpunkte. Wenn Team Topologies implementiert wird, dann kommt es oftmals auch so, dass zum Beispiel das Plattform Team gar nicht wie ein eigentliches Plattform Team ihre Entwicklungsteams oder die Stream-Aligned Teams als Kund:innen versteht oder dass die Enabling Teams eher weiterhin eigentlich nur im Elfenbeinturm sitzen und eigentlich die typischen Architektinnen und Fachexpertinnen sind, die gar nicht wirklich ihre Teams schulen, sondern wieder von oben herab sagen, ihr müsst das tun, ihr müsst das implementieren und wir haben da was vorbereitet. Was ich bei Enabling Teams auch noch sagen möchte, ist mir ist auch aufgefallen, dass die Definition, was die Aufgabe von Enabling Teams ist und wie es in der Praxis eigentlich umgesetzt wird, sich sehr stark unterscheidet. Ich kann mich daran erinnern, im Buch wird beschrieben, ein Enabling Team ist dafür da, dass Fragen geklärt werden, dass das Team sozusagen Hilfe anfordert. So steht es im Buch. In der Praxis sind Enabling Teams meistens diejenigen, die Anforderungen an die Teams stellen und aber Hilfe bei der Umsetzung trotzdem noch bieten. Also im Grunde die typischen Architekturgilden oder die Architektur-Elfenbeintürme, die Anforderungen an die Teams stellen, ihr müsst jetzt folgendes implementieren und wir haben da mal was zusammengeschrieben, was ihr dafür verwenden könnt, um es zu implementieren. Also so ein richtiges Coaching sehe ich da eher selten.

Jakob Oswald: Ich glaube, ein wichtiger Unterschied ist natürlich zu sagen, kommen die Teams auf dich zu, weil sie sich Hilfe wünschen, oder wird ihnen die Hilfe aufgezwungen. Andererseits ist es, glaube ich, dass es manchmal nicht leicht ist, wenn du jetzt im Projektkontext unterwegs bist oder eine Organisation hast, wo du Linientätigkeiten hast und dein Tagesgeschäft, dann bestimmte technische Änderungen noch nebenbei durchzuführen. Das kriegst du manchmal nur im Projektkontext hin, wo du sagst: Okay, das ist jetzt ein explizites Ziel, was wir neben dem Tagesgeschäft umsetzen wollen, und das kriegen wir nur dann hin, wenn wir das mit externer Hilfe machen und in einem gewissen Zeitrahmen, der auch fix ist und bis dahin Dinge schaffen. Es ist immer eine Balance, sage ich, gerade in dem Moment, wo man irgendwo reinkommt und die Teams selber vielleicht keinen großen Mehrwert darin sehen. Das habe ich auch schon erlebt, dass man dann erstmal Überzeugungsarbeit leisten muss, warum sie dieses Projekt überhaupt tun sollen, und ihnen dann noch schmackhaft zu machen, zu sagen: Jetzt müsst ihr etwas lernen, sondern jetzt dürft ihr etwas lernen. Und das ist vielleicht aber auch eigentlich ganz cool, weil es in der Zukunft Dinge vielleicht einfacher macht oder das eben auch Wissen ist, was man an anderer Stelle wiederverwenden kann und einem Sachen vielleicht auch in der Zukunft erleichtert. Aber da muss man dann auch manchmal Überzeugungsarbeit leisten, damit die Leute sich überhaupt erstmal darauf einlassen zu sagen: Okay, gut, dann setzen wir uns zusammen hin. Obwohl ich andererseits oft Offenheit gesehen habe und die Leute sich gefreut haben, wenn man es wirklich mit ihnen macht und sagt: Hey, wir machen das jetzt nicht über euren Kopf oder machen jetzt Frontalunterricht, sondern man nimmt sie ein bisschen mit und macht Übungen zusammen und achtet darauf, dass das Tempo stimmt, dass sie nicht unter- oder überfordert sind, und man von vornherein vielleicht auch den Kontext darlegt, warum man die ganzen Sachen überhaupt macht. Man kann auch viel Spaß haben bei diesen Workshops. Das ist nicht so einseitig, sage ich mal.

Anja Kammer: Ja. Hast du da ein paar Beispiele, um welche Projekte es geht, die vom Enabling Team an die Teams herangetragen werden, und welche vielleicht Widerstände hervorrufen?

Jakob Oswald: Ja, das kann natürlich so etwas sein, wie Cloud Migration, oder was ich jetzt wieder liebe: Security-Sachen. Security ist auf der einen Seite ein unbeliebtes Thema, weil es gegebenenfalls gemacht werden muss, man aber vielleicht gar keinen Mehrwert sieht. Aber das ist andererseits auch ein Treiber, um zum Beispiel Modernisierung voranzutreiben, dass man sagt: Eigentlich ist es gut, wenn wir immer die aktuellsten Softwareversionen benutzen. Und wie kriegen wir das dann zum Beispiel automatisiert hin, dass wir durch den Einsatz von Renovate oder Ähnlichem immer neue Dependencies bekommen und das nicht von Hand machen müssen? Man muss sich vielleicht erstmal damit auseinandersetzen und lernen, wie man das eigentlich einsetzt, und am Anfang erschlägt einen das vielleicht auch ein bisschen, aber es ist natürlich auch für die Entwicklerinnen und Entwickler nachher angenehmer zu wissen: Erstens muss ich die Sachen nicht mehr manuell machen, und zweitens muss ich auch vielleicht keinen Stress haben, weil ich Angst habe, dass irgendjemand mal klingelt und sagt: Hey, du betreibst ja die ganze Zeit kritische Sicherheitslücken, weil du deine Bibliotheken nicht hochlevelst. Dass man da zumindest proaktiver wird. Man macht die Dinge ja nicht zum Selbstzweck, und ich glaube, das zu vermitteln, was eigentlich die Vorteile sind, wenn man das tut, und dass es einem hinterher auch Vorteile bringt, wenn man sich damit auseinandersetzt. Ich glaube, das ist der Einstieg. Was ist erstmal die Überschrift? Security-Bibliotheken hochziehen. Okay, klingt jetzt nicht so spannend, aber auf der anderen Seite: weniger manuelle Arbeit, vielleicht ein ruhigerer Schlaf, weil man sich doch ein bisschen sicherer ist, dass die Sachen ordentlich sind und man sie auf lange Sicht einfacher maintainen kann.

Anja Kammer: Ich bin gerade Teil eines Enabling Teams, und bei uns ist es so, dass die Teams uns sogar die Bude einrennen und Termine mit uns haben wollen, weil sie eine bestimmte Tätigkeit gerne machen wollen, und zwar führen wir gerade Data Contracts ein. Sie sind alle begeistert davon, was man alles damit machen kann und dann alles besser wird. Ich habe das Gefühl, sie sind begeisterter als manchmal wir und sind da sehr wissbegierig.

Jakob Oswald: Ja klar.

Anja Kammer: Genau, das ist.

Jakob Oswald: Ja, genau, es kann ja auch genauso sein, dass es Teams gibt, die sagen: Oh cool, endlich kann ich mich mal mit Docker und Containerisierung beschäftigen oder so etwas. Das habe ich schon so lange auf meinem Zettel, aber ich habe immer so viel an fachlichen Anforderungen zu tun, ich komme gar nie dazu. Jetzt kriege ich überhaupt die Luft, mich damit auseinanderzusetzen und vielleicht sogar noch mit jemandem, der einen gut mitnimmt und wo es dann Spaß macht zusammen. Das ist natürlich der Idealfall, und dann macht es auch richtig Spaß. Es ist ja nicht nur schwierig, mit Menschen zusammenzuarbeiten, sondern es ist ja auch total cool, wenn du am Ende merkst, die haben etwas mitgenommen und man hat Spaß gehabt, und am Ende sagen sie: Okay, super cool. Ich freue mich auf die nächsten Workshops.

Anja Kammer: So wie es Widerstände geben könnte, die Anforderungen der Enabling Teams zu erfüllen, gibt es oftmals auch Widerstände generell gegen diese Art von Transformation einer Organisation. Auch wenn man diese Transformation zu einer anderen Teamstruktur oder einer anderen Kommunikationsart kommuniziert, bekommt man manchmal schon Widerstände, aber oftmals sieht man sie vielleicht gar nicht. Sie sind ein bisschen versteckt. Es gibt vielleicht offensichtliche Widerstände, die mir auch in der Praxis begegnet sind, wie zum Beispiel: Wenn wir das machen, dann kündige ich. Weil es darum geht, dass bei einer Umstrukturierung oftmals auch passiert, dass ein Team umbenannt wird, Rollen neu definiert werden, Aufgaben neu definiert werden. Und da passiert es, dass Leute sagen: Nein, ich möchte aber das machen, was ich sonst immer gemacht habe, oder vielleicht sagen sie innerlich: Ich habe Angst, dass ich diesen Anforderungen nicht mehr gewachsen bin.

Jakob Oswald: Ja.

Anja Kammer: Hast du solche Widerstände auch gesehen?

Jakob Oswald: Ja, ich glaube schon, dass das oft der Widerstand gegen Unsicherheit ist. Ich bin der Überzeugung, es hilft nur, mit den Leuten zu sprechen und zu verstehen, was eigentlich die unterliegenden Gründe dafür sind, dass man das nicht möchte. Und die können ja vielfältig sein. Das kann genauso sein, paradoxerweise mit dem, was du gerade gesagt hast: ‘Ich kündige’, kann es ja genau die Angst vor Jobverlust sein. Wenn wir jetzt die Dinge alle anders machen und Teams anders aufstellen, werde ich dann überhaupt noch gebraucht? Sind meine Kompetenzen dann überhaupt noch relevant? Und bevor ich mich entlassen lasse, ermächtige ich mich vielleicht lieber selbst und kündige, komme dem zuvor und kündige dann selbst. Oder eben diese Dinge zu sagen: Wenn ich mich jetzt in andere Kompetenzbereiche begebe oder wir uns anders strukturieren, brauche ich vielleicht auch andere Kompetenzen und fühle mich unwohl dabei, weil ich nicht genau weiß, wie kompliziert es ist, die vielleicht zu erlernen. Oder ich stelle mir vor, andere Leute denken dann: Oh Gott, der kann ja nichts oder so etwas. Ich glaube, das muss man auch ernst nehmen und schauen, dass im Idealfall alle Leute mitgenommen werden, dass man sagt: Ja, es kann sein, dass vielleicht Dinge anders laufen und du vielleicht auch neue Kompetenzen aufbauen musst, aber auf dem Weg dahin begleiten wir das so, dass du die aufbauen kannst. Und dass das für dich vielleicht sogar ein Asset ist zu sagen: Hey, ich lerne neue Dinge und ich kann danach Sachen, und ich bin vielleicht in einer Arbeitswelt unterwegs, die sich eh schnell ändert, und habe dann eben diese neuen Kompetenzen, um darin bestehen zu können. Keine Ahnung, mal abgesehen von AI ist ja immer ein heißes Thema. Ich selber merke ja auch immer, dass es immer Dinge gibt, wo man am Ball bleiben muss und dass sich Sachen schnell verändern. Ist jetzt natürlich ein extremes Beispiel, aber vielleicht auch schon vorher. Das eine ist ja vielleicht entwickeln oder neue Programmiersprachen lernen, die auf den Markt kommen, sich mit neuen Konzepten auseinanderzusetzen, dann DevOps und Observability und CI/CD und im Betrieb. Es wird ja gefühlt immer mehr von einem verlangt.

Und da den Leuten auch zu sagen: Wir müssen sicherstellen, dass du nicht überfordert bist und dass du dich in deiner neuen, dir zugedachten Rolle dann auch wohlfühlst und gut ankommen kannst und die Unterstützung dafür bekommst. Das muss man, glaube ich, transparent machen und begleiten und einfach zeigen, was dann auch der Platz nach so einer Transformation in der Organisation für eine Person ist.

Anja Kammer: Ja. Und wie du schon sagtest, oftmals wird bei einer Transformation auch gleich von einem Entwicklungsteam erwartet, dass sie ihren eigenen Betrieb machen. Du hattest ja gesagt: You build it, you run it. Eigener Betrieb, das heißt, es gibt vielleicht auch On-Call. Das Entwicklungsteam ist die erste Instanz, die angerufen wird, wenn in der Produktion gerade etwas schiefläuft. Da haben die Leute Angst vor der Überforderung, ob sie das überhaupt können. Aber vor allem: Sie haben Angst vor der Überforderung, dass sie es nicht können, sie wollen es aber auch nicht. Und dann gibt es eine Sperre, die man manchmal nicht sieht. Manchmal gibt es eben diese offene Ablehnung: ‘Das wird alles nicht funktionieren, das ist so bescheuert, warum müssen wir uns neu strukturieren? Ich kündige!’ bis hin zu einer passiven Blockade, dass sie gar nicht mehr darüber reden wollen, sich das anschauen, aber eigentlich schon innerlich gekündigt haben. Und das ist sehr gefährlich, weil man diese passiven, diese verdeckten Widerstände und Blockaden gar nicht sieht. Am Ende funktioniert die Transformation nicht, wenn es sehr viele dieser verdeckten Blockaden gibt, wenn die Leute nicht mitmachen und einfach nach einer Transformation oder währenddessen ihren alten Job weitermachen. Dann funktioniert das Ganze ja gar nicht, was man vorher sich so schön ausgedacht und vermeintlich gut kommuniziert hat.

Jakob Oswald: Ich glaube, es ist keine leichte Aufgabe. Disclaimer: Ich bin weder Organisationspsychologe noch Change Manager. Wir haben eher einen technischen Hintergrund, und das sind Dinge, die uns zwar immer sehr direkt betreffen, die man aber vielleicht nicht in der Tiefe studiert hat. Ich glaube, da kann man eigentlich nur mit gesundem Menschenverstand und Empathie rangehen. Das sind die besten Mittel, die uns als Laien an der Stelle bleiben, um die Menschen als Menschen wahrzunehmen. Wertschätzung zeigen, zu sagen: ‘Hey, wir wollen ja gar nicht jemand anders haben.’ Eine Rolle ist nicht nur eine Hülse in einer Organisationsstruktur, sondern wir schätzen dich auch als Menschen und wollen dich gerne behalten. Wir wollen Teams, die Freude an der Arbeit haben und nicht nur Bausteine in einem Organigramm sind. Ich glaube, das sind einfach wichtige Komponenten. Es kann natürlich immer mal sein, dass jemand total dichtmacht, aber ich weiß auch nicht, ob es da ein Patentrezept gibt, das zu ändern. Das ist dann vielleicht auch einfach eine persönliche Sache, und da muss man dann schauen, wie man damit umgehen kann oder eben auch nicht.

Anja Kammer: Du hattest ja schon gesagt: Die frühe Einbindung ist wichtig. Früh kommunizieren, zu welchem Vorteil wir das Ganze machen, sehr transparent sein, die Leute vielleicht auch in die Entscheidungsprozesse einbeziehen, damit sie sich nicht übergangen fühlen. Wir beide hatten auch ein Projekt gemeinsam gemacht, wo es darum ging, Teams, die umstrukturiert werden und komplett neue Aufgaben bekommen, teilhaben zu lassen, damit sie selbst bestimmen können, wie ihre zukünftige Arbeit aussieht, welche Ziele sie sich setzen und wie sie diese Ziele erreichen wollen. Dann kann es schon dazu führen, dass sie sich eher bereit erklären mitzugehen und vielleicht Spaß an der Transformation haben, weil ihnen dann klar ist, wohin die Reise geht und sie auch teilhaben und Dinge steuern können, was super wertvoll ist. Sie sind ja die Fachexpertinnen für ihr Thema. Diejenigen, die Aufgaben erfüllen sollen, sind auch die besten Beraterinnen, wenn es darum geht, wie sie ihre Ziele erfüllen.

Jakob Oswald: Ich glaube, das ist natürlich eine Perspektive. Genau dieses: Wo bin ich am Ende? Wo ist der Platz für mich? Wo geht es weiter und dass man weiter gewertschätzt wird.

Anja Kammer: Ein anderer Punkt ist, positive Beispiele zu geben. Ich weiß nicht, ob ihr im ersten Teil schon über Pilot-Teams oder Pilotprojekte gesprochen hattet, wenn es um eine Transformation geht, wie beispielsweise Continuous Delivery. Es bietet sich sehr einfach an, solche neuen Konzepte schon mal mit Teams zu verproben, die bereits Erfahrung damit gesammelt haben oder gerade Luft haben, das zu tun. Diese Teams wenden dann als erstes die neue Methodik an und berichten aus der Praxis, wie es gelaufen ist. Sie können dann transparent an andere Teams kommunizieren: ‘Wir haben das jetzt eingeführt, diese Stolpersteine haben wir gesehen.’ So können sich die anderen Teams darauf ausruhen: ‘Okay, wir sind nicht die ersten, wir sind nicht alleine. Da hat schon mal jemand all diese Schmerzen durchgemacht und wir wissen, was auf uns zukommt.’

Jakob Oswald: Auf jeden Fall. Ich überlege gerade, ich glaube, oft sind diese Pioniere und Pilot-Teams auch dankbare Teams, mit denen man zusammenarbeiten kann, weil sie in meiner Erfahrung aus eigener Initiative dazustoßen und schon eine intrinsische Motivation mitbringen, neue Sachen auszuprobieren. Man braucht sie oft gar nicht lange überreden oder ihnen Befürchtungen nehmen, weil sie eigentlich Lust darauf haben und von alleine vorangehen, was ihnen Spaß macht. Es ist ein gutes Werkzeug, um neue Sachen auszuprobieren, und ich glaube, es kann auch super gut funktionieren, weil die Leute, die vorneweg gehen, oft eine eigene Motivation mitbringen und dann vielleicht auch die dicken Bretter bohren und so schon ein bisschen den Weg für andere Teams ebnen. So wird genau diese Hürde ein bisschen geringer.

Anja Kammer: Generell: Wie stelle ich meine Teams auf und wie spielt das eigentlich mit Softwarearchitektur zusammen?

Jakob Oswald: Ich finde es immer wieder interessant zu sehen, wie eng Organisationsdesign und Softwarearchitektur miteinander verwandt sind. Wenn man ein bisschen darüber nachdenkt, ist das auch überhaupt nicht verwunderlich, weil man Systeme hat, die miteinander kommunizieren. Man versucht, diese Systeme arbeitsteilig zu gestalten und hat am Ende die Herausforderung, diese Orchestrierung zu schaffen. Wenn man Teilsysteme hat, die teilautonom funktionieren sollen, wo Leute oder Maschinen arbeiten verrichten, dann passiert es meistens in einem größeren Kontext. Das wieder zusammenzuführen, ist, glaube ich, die Kunst, sowohl wenn ich eine Softwarearchitektur mache, als auch wenn ich meine Teams schneide. Ich muss identifizieren – und da kommen wir auch schon wieder in den Bereich von DDD oder Ähnlichem –, was sinnvolle Grenzen sind und wie ich die Kommunikationsschnittstellen zwischen diesen begrenzten, teilautonomen Teams oder Systemen gestalte. Das deckt sich sehr stark. Das sind genau diese Sachen: Wenn ich merke, dass meine Teams zu eng miteinander arbeiten, habe ich oft auch starke Schnittstellen zwischen Systemen. Da geht es wieder Richtung Conway’s Law. Ich glaube, das geht ein bisschen in beide Richtungen. Eigentlich muss ich immer gucken, dass meine Teamorganisation auf meinen Kontext abgestimmt ist. Wenn ich eine mehrere Teams umfassende Softwarearchitektur baue, ist meine Teamorganisation eigentlich schon der erste Architekturschnitt, der erste Softwareschnitt, meine Makroarchitektur. Das kann ich natürlich von beiden Seiten angehen. Normalerweise bilde ich Teams ja nicht auf dem Reißbrett, sondern um Fachlichkeiten herum.

Anja Kammer: Idealerweise.

Jakob Oswald: Aber das ist genau das.

Anja Kammer: Idealerweise.

Jakob Oswald: Klar. Das eine sind natürlich gewachsene Strukturen. Wenn ich etwas komplett neu aufsetze, auf der grünen Wiese, und dann gleich mit DDD anfange und versuche, einen sinnvollen Schnitt zu machen – sinnvoll bedeutet in dem Sinne, dass ich diese enge Kohäsion, auch witzig, genau aus diesem Softwarebereich, also ‘High Cohesion, Loose Coupling’, das Gleiche findet sich auch im Organisationsdesign wieder. Man möchte Arbeiten, die eng zueinander passen, in einer Organisationseinheit abbilden und die Kommunikationsschnittstellen zwischen diesen Organisationsteilen so dünn und effizient wie möglich machen. Das kann man auch in jeder Fachabteilung beobachten. Wenn du etwas hast, wo du sagst: ‘Okay, du kannst mehr oder weniger Dinge abarbeiten und danach steckst du das in einen Umschlag und legst es irgendwo hin.’ Egal, ob jetzt gleich oder morgen oder jemand anders aus einer anderen Abteilung sich diesen Umschlag nimmt und damit weiterarbeiten kann, dann hast du genau diese Schnittstelle geschaffen, wo deine API die Dokumente sind, zwischen den Systemen. An der Stelle sind das dann die Abteilungen.

Das kann man auch in jeder Fachabteilung beobachten. Wenn du etwas hast, wo du sagst: ‘Okay, du kannst mehr oder weniger Dinge abarbeiten und danach steckst du das in einen Umschlag und legst es irgendwo hin.’ Egal, ob jetzt gleich oder morgen oder jemand anders aus einer anderen Abteilung sich diesen Umschlag nimmt und damit weiterarbeiten kann, dann hast du genau diese Schnittstelle geschaffen, wo deine API die Dokumente sind, zwischen den Systemen. An der Stelle sind das dann die Abteilungen. Das finde ich immer wieder interessant und erstaunlich, wie eng Organisationsdesign und Softwarearchitektur beieinander liegen.

Anja Kammer: Ich finde es auch spannend, die Entwicklung von DevOps darin zu sehen. Das Problem des Betriebs gab es schon immer. Dann gab es DevOps Anfang der er, und man hatte gedacht: ‘Wow, jetzt können Entwicklungsteams ihren eigenen Betrieb machen und sie bekommen einfach die Verantwortung übergestülpt und dann machen sie das alles selbst.’ Die eigentliche Definition von DevOps, die missverstanden wurde, ist, dass Entwicklungs- und Operations-Teams sehr nah miteinander arbeiten und kollaborieren. Aber wir wissen ja bezüglich der Team-Interaktionsmodi: Eine Kollaboration ist ein Zustand, den man nur sehr kurzfristig haben möchte, um beispielsweise Schnittstellen zu besprechen, weil es ein sehr intensiver und hoher Zeitaufwand ist, diese Kollaboration zu haben. Das heißt, es ist eigentlich ein Anti-Pattern, die falsch verstandene Implementierung von DevOps zu implementieren. Und noch heute sehe ich Definitionen von DevOps, die genau das sagen: ‘DevOps bedeutet eine hohe Kollaboration zwischen Entwicklungsteam und Operations Team.’ Genau das wollen wir eigentlich vermeiden, weshalb wir mehr Betriebsverantwortung zu den Entwicklungsteams hinübergeben und hier wieder tatsächlich eher einen technischen Schnitt haben, sodass Plattformtätigkeiten und Betriebstätigkeiten der darunterliegenden Infrastruktur von einem anderen Team übernommen werden. Diesen Schnitt wollen wir. Die Fachlichkeit und auch den Betrieb der Fachlichkeit sollen in die Entwicklungsteams hineingehen. Viele sagen: ‘Okay, aber mit DevOps wollten wir doch eigentlich mehr Kollaboration, und jetzt schneiden wir wieder anhand von Technik.’

Jakob Oswald: Ja, das ist eine interessante Frage. Ich glaube, das ist genau der Punkt, wo man den Schnitt der Arbeitsteilung macht. Ist die Entwicklung meiner Software ein Arbeitsteil oder ist die Entwicklung und der Betrieb meiner Software ein Arbeitsteil? Der Betrieb hat, glaube ich, viele Dimensionen, denn wir bauen ja schon immer auf Plattformen auf, zumindest wenn wir über IT sprechen. Ich habe früher vielleicht noch an meinen PCs herumgeschraubt, aber das ist lange her. Ich glaube, die wenigsten Entwicklerinnen und Entwickler bauen sich ihre Hardware selbst zusammen, stecken Netzwerkkarten und legen Kabel, um darauf ihre Software zu installieren. Es fängt ja schon damit an, dass ich mir in einem Rechenzentrum ein Blech miete oder ein virtualisiertes Blech, oder einen EKS-Cluster. Da setze ich ja auch schon auf Plattformen auf. Und da ist dann, glaube ich, das ist auch ein Thema, das man sehr tief treiben kann: Was ist eine Plattform und was nicht? Und welchen Teil übernehme ich? Ich glaube, die Schwierigkeiten im operativen Bereich, die man früher hatte und die man versucht hat, mit DevOps zu beseitigen, ist diese Handlungsunfähigkeit. Ich habe gesagt, ich bin jetzt fertig mit der Entwicklung, aber fertig mit der Entwicklung ist man eigentlich erst, wenn es läuft. Wenn ich das selbst aber nicht mehr installieren und testen kann, ob das, was ich entwickelt habe, funktioniert, ist die Aufgabenteilung schlecht geschnitten. Das heißt, meine Aufgabe muss mindestens das Installieren und Ausprobieren umfassen oder sicherstellen, dass meine Anwendung funktioniert. Das heißt aber vielleicht nicht, dass ich in der Tiefe alles darunterliegende verstehen muss, also unter meinem Anwendungscode. Ich muss vielleicht nicht eine JVM verstehen oder das Betriebssystem oder die Elektrotechnik, die in so einem Server steckt. Irgendwo muss ich ja diesen Schnitt machen, weil eine starke Vertikalisierung immer mit sich bringt, dass ich ganz viel wissen und können muss. An dieser Stelle muss man oder ist es wahrscheinlich auch sinnvoll, wieder eine Arbeitsteilung oder eine Abstraktionsebene einzuführen, die mich da ein bisschen entlastet, weil ich am Ende vielleicht Fachanwendungen entwickeln möchte und dafür keine Elektrotechnik studieren muss.

Anja Kammer: Ja. Man muss dazu allerdings sagen, dass wir uns jetzt im Kontext von eher größeren Organisationen bewegen, nicht wahr? Wir beide arbeiten eher im Kontext größerer Organisationen, und INNOQ arbeitet auch eher in diesem Kontext. Es gibt natürlich kleinere Organisationen mit weniger Entwicklungsteams, wenn nicht sogar nur einem. Und da sieht es alles anders aus. Wir brauchen in kleinen Startups keine eigenen Plattform-Teams oder Enabling-Teams, sondern dann ist es eher so, wie du schon sagtest, dass man eben auf schon bestehende Abstraktionen aufbaut, wie Platform as a Service zum Beispiel.

Jakob Oswald: Ja, genau. Ein Plattform- oder Enabling-Team lohnt sich natürlich erst ab einer gewissen Größe. Die Herausforderung der Teamkoordination habe ich frühestens bei zwei Teams. Wenn ich nur ein Team habe, brauche ich mir keine Gedanken um Organisationsdesign zu machen. Das ist ja auch das Interessante, dass, solange es klein ist, dieses semiautonome Team immer gut funktioniert, weil ich mich direkt absprechen kann und nicht diese großen Kommunikationskomplexe habe. Obwohl selbst in einem Startup, das ist auch immer so ein Beispiel, du hast ja auch in jeder Firma irgendwo ein Plattformteam. Niemand macht seine Lohnabrechnung selbst in einem Entwicklungsteam. Selbst da hast du ja schon irgendwo einen Organisationsschnitt in den meisten Fällen. Das ist jetzt vielleicht nicht so auffällig, aber auch das ist ja, wenn du auf eine Organisationsstruktur guckst, kannst du das ja auch als Plattform für deinen Business Case sehen, weil das in den meisten Fällen nur eine Notwendigkeit, eine Rahmenbedingung ist, die du brauchst, damit Leute in deiner Organisation funktionieren. Aber es ist jetzt nicht Teil deines Geschäftsmodells, dass du Finanzbuchhaltung kannst, es sei denn, es ist dein Geschäftsmodell, aber das ist ja die Ausnahme in den meisten Fällen.

Anja Kammer: Ja. Ich finde es gut, dass wir da noch mal weiter anknüpfen, weil du hattest ja gesagt, ich mache ja Team Topologies aus dem Grund, weil Teams miteinander kommunizieren müssen. Das heißt, wenn ich nur ein Entwicklungsteam habe oder sehr wenige Teams, habe ich oftmals diese Probleme nicht. Welche Probleme will ich denn mit Team Topologies lösen? Woran erkenne ich, ob ein Teamschnitt nach Team Topologies und diesen Interaktionsmodi jetzt angedacht werden sollte?

Jakob Oswald: Ja, so einen Bedarf kann man erkennen. Es gibt eine Beschreibung von Dysfunktionalitäten, zum Beispiel. Typische Sachen sind, dass man lange braucht, um Entscheidungen zu treffen. Wenn du immer über alle Teams quasi drei, vier, fünf Abstimmungszyklen brauchst, um dann zu einer Entscheidung für irgendetwas zu kommen, kann das ein Indikator dafür sein, dass du sagst: Okay, vielleicht sind Organisationseinheiten, also unsere Teams, nicht optimal geschnitten, weil wir diese semiautonomen Entscheidungen nicht treffen können. Es gibt strategische Ziele, die werden im Idealfall von einer übergeordneten Organisationseinheit formuliert, und denen sollten alle Organisationseinheiten folgen. Das ist das übergeordnete Ziel, und davon lassen sich dann vielleicht Teamziele oder Abteilungsziele ableiten. Innerhalb dieses Rahmens meines Kontextes muss ich in der Lage sein, auch da Entscheidungen treffen zu können, ohne mich mit allen abstimmen zu müssen. Natürlich auch in gegebenen, vordefinierten Rahmenbedingungen, aber wenn ich das gut gemacht habe, dann kann ich das. Das ist ja auch die Idee, dass ich sage, ich habe in so einem crossfunktionalen Team mein eigenes Produkt. Das heißt nicht, dass ich mich gar nicht abstimmen muss, sondern ich muss mich natürlich an der Stelle, wo ich Schnittstellen mit anderen Teams habe, abstimmen. Aber idealerweise sind die Schnittstellen, wie auch in der Softwarearchitektur, dünn geschnitten, und ich kann einen Großteil meiner Entscheidungen selbst treffen. Dadurch bin ich schnell. Wenn ich Entscheidungen lokal treffen kann, dann kann ich auch schnell agieren. Die Umsetzung ist manchmal oder oft, würde ich fast sagen, gar nicht das, was Organisationen langsam macht, sondern das Warten auf Entscheidungen oder das Abhängigsein von Entscheidungen anderer Organisationseinheiten zum Beispiel. Das wäre so eine Dysfunktionalität: langsame oder schlechte Entscheidungen.

Anja Kammer: Was ich häufig auch sehe, ist, dass Arbeit mehrfach gemacht wird in einer großen Organisation, dass es mehrere Teams gibt, die irgendwann dazu übergegangen sind, dieselben Probleme zu lösen. Es gibt multiple Teams, die plattformähnliche Produkte anbieten, die dann aber irgendwann so ähnlich sind, dass sie miteinander konkurrieren, oder im schlimmsten Fall, dass gar nicht offengelegt ist, dass es diese konkurrierenden Produkte gibt oder dass es da sehr große Ähnlichkeiten gibt. Da verpufft auch ganz schön viel Geld.

Jakob Oswald: Ja, ich glaube, das sind auch wieder Softwarearchitektur-Analogien. Ich kann natürlich schauen, ob ich einen gemeinsamen Nenner finde, der muss aber, glaube ich, immer wohldefiniert sein. Worauf will ich hinaus? Wenn wir vertikalisieren, kann es natürlich sein, dass wir bestimmte Kompetenzen duplizieren, das ist einfach so.

Es ist immer die Frage, lohnt sich das oder lohnt sich das nicht? Das hängt davon ab, wie klar die Anforderungen sind. Wenn ich jetzt zwei Entwicklungsteams habe und sage, okay, wir bauen etwas, das gleich zu sein scheint, wollen wir das nicht an ein drittes Team auslagern oder eine Plattform oder so etwas? Dann kann das sehr gut funktionieren, wenn der Zweck sehr klar ist und wir uns relativ sicher sind, dass sich das auch immer für beide Teams mindestens gleich oder ähnlich entwickeln wird. Ich gebe damit die Entscheidungskompetenz wieder an eine andere Entität ab und habe damit wieder eine Abhängigkeit. Das heißt, wenn…

Anja Kammer: Ja, das stimmt.

Jakob Oswald: Unsere beiden Teams jetzt unterschiedliche Dinge machen, weil, keine Ahnung, mein Team im Privatkundenbereich unterwegs ist und deins im Geschäftskundenbereich, und wir uns entschlossen haben, etwas auf einer gemeinsamen Plattform oder an ein drittes Team abzugeben, weil wir ja quasi immer das Gleiche gemacht haben und das jetzt irgendwie zentralisieren, dann sind wir natürlich auch wieder Anforderungsstelle an dieses dritte Team. Und das kann vielleicht auch nicht mehr beide gleichzeitig bedienen oder muss halt auch wieder Prioritäten setzen. Das heißt, eigentlich tausche ich potenzielle Effizienz gegen Abhängigkeiten. Und da muss man halt, glaube ich, aufpassen. Die Vertikalisierung erlaubt einem lokale Entscheidungen, aber es ist halt natürlich immer eine Duplizierung, also man dupliziert immer die Notwendigkeit von Fähigkeiten. Ich glaube, das ist sehr kontextspezifisch, ob sich das lohnt oder nicht, und man muss halt sehr aufpassen, dass man nicht aus der Idee heraus, etwas effizienter zu machen, indem man es durch Indirektion löst, zum Beispiel eine gemeinsame Bibliothek oder ein Service oder ein drittes Team, das sich dann um den Service kümmert, halt wieder zunichtemacht durch die Wartezeiten, die man generiert, weil zwei Teams von einem dritten Team abhängig sind, das halt auch erstmal Entscheidungen treffen muss und je nach Arbeitslast oder eben den eigenen Zielen halt Dinge anders macht, als es sich das andere Team gerade wünscht. Die können dann nicht mehr entscheiden, oh, ich mache was anderes, sondern müssen halt in die Kommunikation gehen und sagen, wie ist denn eure Planung, und ist es wichtiger, dass ihr erst mein Feature bearbeitet oder das von dem anderen Team, und dort muss ich dann halt auch leben können.

Anja Kammer: Du meinst, es gibt da kein Patentrezept, wann ich weiß, ob sich das lohnt und wann nicht, sondern man muss es halt in dieser Organisation, in diesem bestimmten Fall, entscheiden.

Jakob Oswald: Ein Patentrezept gibt es natürlich sowieso nicht. Ich glaube, es gibt ein paar Kriterien, die man abklopfen kann. Ein paar Kriterien sind zum Beispiel, es muss eine minimale Komplexität gegeben sein. Ich denke jetzt gerade eher an Code und so etwas, aber auch da: Es lohnt sich in den meisten Fällen nicht, ein Team zu gründen oder auszugründen, wenn es nicht beschäftigt werden kann. Wenn du jetzt jemanden hast und sagst, okay, dann machen wir jetzt ein Team mit einer Person, dann hast du wieder andere Faktoren, so wie machst du eigentlich Redundanzen? Wenn derjenige vielleicht auch mal in Urlaub gehen möchte, brauchst du eigentlich schon zwei Personen. Jetzt musst du schauen, wie du die beschäftigt bekommst. Wenn das jetzt viel sein kann, musst du auch wieder schauen, dass jemand das managt. Eigentlich brauchst du dann wieder jemanden, der Produktmanagement in diesem Team macht. Dann hast du schon drei Personen. Jetzt musst du die irgendwie Vollzeit auslasten. Wenn du das nicht schaffst, dann kann es sein, dass das Thema, das du mit Effizienzgedanken zu zentralisieren versucht hast, dazu führt, dass jemand auf die Idee kommt und sagt: „Ihr habt ja Kapazitäten, dann macht doch noch das und macht noch das.“ Dann sind wir schon wieder in eine andere Falle getreten, nämlich unklare Verantwortlichkeiten, weil ein Team dann vielleicht nicht mehr eine Sache macht, sondern plötzlich zwei oder drei. Wenn jetzt gerade diese Sache, die man ihnen noch nebenbei gegeben hat, plötzlich Relevanz hat und die anderen bekommen und sagen: „Oh, jetzt brauchen wir aber auch dringend etwas“, dann stehen die nämlich auch wieder in dem Konflikt, Dienstleister für zwei Teams zu sein und noch ein drittes eigenes Ziel zu haben. Das ist tatsächlich in dem Sinne nicht trivial. Du brauchst eine kritische Masse, damit sich das überhaupt lohnt. Das ist, glaube ich, ein Aspekt. Ein anderer ist: Kann ich voraussehen, in welche Richtung sich die Anforderungen entwickeln? Wenn ich jetzt ein Team gegründet habe, von dem andere wieder abhängig sind, bin ich mir denn sicher, dass die Anforderungen an das Team stabil sind?

Jakob Oswald: Was ist denn jetzt das, was wir zwar immer gleich gemacht haben, und jetzt kann es aber sein, dass plötzlich morgen das eine Team etwas ganz anderes braucht? Jetzt ist die Frage: Was bedeutet das dann? Betrifft das dann eigentlich die Entscheidung, wie sich das weiterentwickelt? Löst man das Team wieder auf und vertikalisiert sozusagen wieder und integriert die Leute aus dem dritten Team in Team und ? Das wäre vielleicht sogar möglich, ist aber auch wieder Organisations- und Change-Aufwand. Da muss man natürlich auch mit gucken. Das heißt, wenn ich einen sehr klaren Auftrag habe, eine sehr klare Idee, wohin sich das entwickelt, und sich der Bedarf bei den Konsumenten nicht eklatant ändert, dann ist es gut. Wenn ich das überhaupt nicht sagen kann, weil ich nicht weiß, ob das eine Team morgen vielleicht ganz andere Anforderungen hat, an was auch immer man versucht hat zu zentralisieren, dann ist es natürlich schwierig, weil es dann so sein kann, dass wir heute ein drittes Team ausgründen und morgen ist das schon wieder obsolet, weil die Anforderungen, die von zwei verschiedenen Seiten kommen, total unterschiedlich sind.

Anja Kammer: Welche Dysfunktionalitäten gibt es denn noch?

Jakob Oswald: Eine andere Dysfunktionalität, die wir schon angesprochen haben, sind unklare Verantwortlichkeiten. Man sagt, hier gibt es irgendeine Aufgabe, man hat sich irgendwie geeinigt, dass sie gemacht werden sollte, und jetzt musst du jemanden finden, der es macht. Du gehst in das eine Team und sagst: „Hey, das muss weiterentwickelt werden.“ Alle finden es gut und nicken und sagen: „Ja, das sehen wir ganz genauso, aber das liegt nicht bei uns, das liegt bei dem anderen Team.“ Dann gehst du dahin, dann sagen die: „Ja, ja, das ist alles richtig, aber wir sind dafür nicht verantwortlich.“ Dann muss man sich irgendwann überlegen: „Okay, vielleicht müssen wir dann mal mit allen Teams darüber reden oder mal überlegen, warum ist das denn eigentlich so?“ Ist das bloß durch nicht ideale Kommunikation irgendwo durch die Lappen gegangen und ist es vielleicht tatsächlich irgendwo in der Theorie klar verortet, oder ist es tatsächlich so, dass man gesagt hat: „Ja, die Verantwortlichkeit ist einfach nicht klar geschnitten, weil sie über mehrere Teams verteilt ist.“ Dann ist es eine potenzielle Lösung zu sagen, wir schneiden die Teams möglicherweise anders. Natürlich auch da wieder vorausgesetzt, dass dieser Themenbereich sich lohnt, aber das kann ein Indikator dafür sein, wenn man es beobachtet. Sonst fehlende Zusammenarbeit, Konflikte, das ist eine extreme Form von Dysfunktionalität, dass es immer Reibereien gibt. Das kann auch einfach daran liegen, dass zum Beispiel Ressourcen nicht klar abgegrenzt sind. Eine Organisationseinheit funktioniert eigentlich nur, wenn sie auch die Ressourcen hat, ihren Auftrag zu erfüllen. Wenn man jetzt merkt, dass zwei Teams immer um Ressourcen konkurrieren müssen, müsste man sich überlegen, ob man die Ressourcen teilen oder die Teams zusammenlegen müsste, damit man klare Grenzen hat.

Anja Kammer: Hast du dann ein Beispiel, also was für Ressourcen können das sein?

Jakob Oswald: Was für Ressourcen? Na ja, es könnte ja so etwas sein: Du hast irgendwo gelesen, Team Topologies sagt, wir brauchen ein Plattformteam, und dann machst du ein Plattformteam. Dann merkst du aber, dass die einen immer das von dem Team wollen und die anderen immer das, und das eine Team verhungert am langen Arm, weil das eine immer Priorität hat. Dann ist das vielleicht genau ein Indikator dafür zu sagen, vielleicht macht ein Plattformteam an der Stelle keinen Sinn, wenn die Teams so stark davon abhängig sind und das eine Team überhaupt gar nichts machen kann, weil es nie Zeit und Ressourcen von diesem Plattformteam bekommt, weil die Plattform eigentlich nicht dafür ausgelegt ist, so wie sie ist, eben beide zu bedienen, sondern man sagt: „Ja, man hat zwar gesagt, das ist eine Plattform, aber eigentlich sind die Anforderungen nicht klar genug.“ Da ist es vielleicht tatsächlich sinnvoller zu sagen, dieses Plattformteam aufzulösen und dann eben eine Person in das eine Team zu stecken und zwei Personen in das andere Team zu stecken, damit beide Teams handlungsfähig sind. Sonst hast du da quasi das eine Team abgesägt. Dann hast du da zwar ein Team und ein Streamline-Team, aber wenn das nicht arbeiten kann, weil es auf einer Plattform oder auf einer vermeintlichen Plattform aufsetzt, die aber für das Team nicht funktioniert, dann hast du an der Stelle ein Problem geschaffen.

Anja Kammer: Auf der anderen Seite heißt es also, wenn die Anforderungen an die Plattform viel zu unterschiedlich sind von unterschiedlichen Teams, dann lohnt es sich gar nicht, eine Plattform aufzubauen, weil man diese diversen Anforderungen gar nicht wirklich erfüllen kann.

Jakob Oswald: Das würde ich so unterschreiben, ja. Eine andere typische Dysfunktionalität ist viele Termine, viele Komitees oder Task Forces. Man sagt: „Okay, wir müssen ständig unsere Idee ist eigentlich, dass wir permanent Leute aus unseren Teams entsenden müssen, um eine Task Force zu gründen, die dann wieder irgendwelche Dinge tut.“ Das kann ein Indikator dafür sein, dass man sagt: „Okay, eigentlich haben wir hier einen Bedarf, den wir immer wieder haben. Vielleicht ist es tatsächlich sinnvoll, zum Beispiel an der Stelle ein Plattformteam daraus zu machen.“ Das kann tatsächlich sein, oder ein Enabling Team, das dann tatsächlich zentral agiert, statt Leute immer wieder aus ihrem eigentlichen Teamkontext herauszureißen und in eine Task Force zu stecken. Oder vielleicht stimmen die Entscheidungsprozesse nicht, dass du merkst: „Okay, wenn ich für Entscheidungen immer wieder versuche, neue Arbeitsgruppen bilden muss oder so etwas, dann fehlt vielleicht eigentlich ein organisatorischer Rahmen, um diese Entscheidungen zu treffen.“ Das kann eben auch einfach ein Indikator dafür sein, dass der Organisationsschnitt nicht gut ist, weil die Prozesse, also die Idee des Teams oder der Organisationseinheit, ja eigentlich ist, semi-autonom zu funktionieren. Das heißt, wenn ich aber Entscheidungen nicht treffen kann oder keinen Zugriff auf Ressourcen habe oder Wissen nicht habe oder eben der Informationsfluss fehlt, was wir eigentlich tun sollen, dann ist das Team eben nicht semi-autonom und wird in seiner Handlungsfähigkeit eingeschränkt. Dann ist es eigentlich auch kein Team, oder es ist ein dysfunktionales Team. Da muss man sich überlegen, ist es dann sinnvoll, dass es so aufgestellt ist, wie es ist, oder sollte man vielleicht gucken, ob man die Teams anders schneidet.

Anja Kammer: Ja. Ja, da sehe ich auf jeden Fall Parallelen aus meiner praktischen Arbeit. All das habe ich mal so oder so ähnlich gesehen, auf jeden Fall. Dann bedanke ich mich, Jakob, für diesen zweiten Teil von Evolution von Teamstrukturen.

Jakob Oswald: Ja, ich danke. Es hat sehr viel Spaß gemacht wieder und ich freue mich auf den nächsten Podcast.

Anja Kammer: Dann bis dann, tschüss.

Jakob Oswald: Bis bald, ciao.