Transcript
Anja:: Hallo und herzlich Willkommen zum INNOQ-Podcast. Heute sind wir zu dritt und zwar sind hier Sven Johann hallo.
Sven: Hallo!
Anja:: Und Michael Plöd.
Michael: Hallo!
Anja: Und mein Name ist Anja Kammer und heute sprechen wir über Enabling Teams. Kennt ihr bestimmt, Enabling Teams sind eine Art von Teamstruktur und das kommt aus Team Topologies. Michael du hast ja das Buch Team Topologies übersetzt und dich halt schon auch vorher intensiv mit dem Material beschäftigt. Also du bist eigentlich die erste Person, die mir in den Sinn kommt, wenn ich Fragen habe. Und wir haben einige Fragen zu Enabling Teams.
Michael: Dann lasst uns mal die Fragen besprechen. Bin mal gespannt, was ihr mich fragen wollt.
Anja: Ich würde sagen, dann fangen wir an. Was sind eigentlich Enabling Teams? Welche Personen arbeiten in den Enabling Teams? Was sind ihre Aufgaben? Wozu brauche ich eigentlich ein Enabling Team in meiner Organisation?
Michael: Ich werde da gleich mal ein bisschen weiter ausholen. Bevor ich jetzt auf die Frage gehe, was sind Enabling Teams, würde ich das Ganze erst noch mal ein bisschen in den ganzen Kosmos von Team Topologies einordnen. Also wie schon gesagt, Enabling Teams kommen aus dem Umfeld der Idee von Team Topologies. Das ist ein Buch von Matthew Skelton und Manuel Pais. Und die haben dort vier fundamentale Teamarten oder Team Topologien, wie sie es nennen vorgestellt, neben drei Teaminteraktionsformen, aber da werden wir später mal drauf zu sprechen kommen. Viele Leute haben so die Wahrnehmung, dass eine dieser Teamarten, die Stream-aligned Teams, von einer extrem zentralen Bedeutung in Team Topologies sind. Das ist zum gewissen Grad absolut richtig. So ein Stream-aligned Teams soll Value stiften für Kunden, für Nutzer und Nutzerinnen von einem System. Und sehr viel in der Team Topologies Welt zielt darauf ab, die schnell zu machen, also dass die schnell lieferfähig sind, dass die eine hohe Lieferkadenz hinbekommen, dass die in kurzen Iterationszyklen Software ausliefern können etc. Und da spielt natürlich auch das Thema kognitive Belastung für diese Teams eine entscheidende Rolle. Man will sicherstellen, dass die Mitglieder des Teams, ich sag mal für einfach gesagt, nicht überfordert sind. Und da kommen jetzt so die anderen Teamarten oder Topologien ins Spiel, also beispielsweise Plattform Teams, die eben die kognitive Belastung der Stream-aligned Teams dahingehend reduzieren sollen, indem sie denen eine Plattform anbieten für bestimmte Sachen, worum sich das Stream-aligned Team nicht mehr kümmern soll. Das können jetzt technische Plattformen sein, irgendwelche Cloud-Plattformen, CICD-Plattformen, können aber auch fachliche Plattformen sein. Also beispielsweise Briefversand und Empfang zum Beispiel, dass die sich da nicht drum selber kümmern müssen oder sich mit der Fachlichkeit auseinandersetzen müssen, sondern dass sie das als Service im Idealfall nutzen können. Dann gibt es noch die Complicated Subsystem Teams, wo schwer am Markt zu bekommen, das Spezialwissen gebündelt wird. Und es gibt halt da auch noch die Enabling Teams und deren Aufgabe ist es, insbesondere die Stream-aligned Teams, aber auch potenziell die anderen Teamarten in bestimmten Themenbereichen zu befähigen. Und dieses Befähigen kann auf unterschiedliche Art und Weise stattfinden. Erstens ist das Enabling Team auf einem bestimmten Themenbereich spezialisiert, kann man sagen.
Anja:: Was sind das so für Themenbereiche?
Michael: Ich könnte mir jetzt beispielsweise vorstellen, dass man Agile-Coaches in einem Enabling Team bündelt. Dass man eben sagt, so Agile-Enabling. Das kann ein technologisches Enabling sein. Zum Beispiel für Machine Learning, AI-Sachen könnte man das machen, für bestimmte Cloud-Plattformen, für bestimmte Methodiken. Zum Beispiel kollaborative Modellierung aus dem Domain-Domain-Design-Umfeld. Software-Architektur wäre eine Möglichkeit. Die Bandbreite ist an der Stelle ehrlich gesagt beliebig groß. Ich nehme immer gerne zum Beispiel IT-Security als Beispiel. Wenn ich mich so umschaue, was ich so erlebe an Teams, zum Beispiel im IT-Security Umfeld, sehe ich relativ viele Teams mit einer Disabling-Mentalität.
Anja: Was bedeutet das?
Michael:: Ich will jetzt an niemanden zu nahe treten, aber ich sage, diese Teams sagen sehr häufig nein zu anderen. Also wie? Das willst du machen? Ne, aus Gründen von IT-Security darfst du das nicht. Wie? So wollt ihr das lösen? Seid ihr wahnsinnig? Das geht ja überhaupt nicht. Ne, und da haben wir unsere Policy und deshalb dürft ihr das nicht etc. Also ich überspitze jetzt natürlich ein bisschen.
Sven: Also ich kenne Security Consultants, die haben so als Einstiegsgag, Hi, ich bin von Security, ich bin hier um zu helfen. Und dann ist das immer der totale Gag, weil noch nie irgendjemand von IT Security irgendwie hilfreich war. Und er meinte halt auch, ja, das muss man einfach, das muss man wirklich ändern.
Michael: Also wir sollten jetzt da auch nicht pauschalisieren. Das ist natürlich auch ganz wichtig. Ist jetzt so ein kleiner Lacher zwischendrin. Aber ich sag mal so eine Enabling-Mentalität in dem Umfeld wäre eine Arbeitsweise, dass ich sage, hey, lasst uns mal euer Problem bitte verstehen. Und wir helfen euch dabei, wie ihr dieses Problem auf sichere Art und Weise lösen könnt. Und wir helfen euch auch dabei im Hinblick auf Wissensvermittlung, dass ihr das in Zukunft auch selber machen könnt, dass ihr Security von Haus aus direkt einbauen könnt. Und das ist so die Idee des Enabling Teams. Die kognitive Belastung der anderen Teams wird auch zusätzlich dadurch gesenkt, dass das Enabling Team Zeit und Ressourcen hat, finanzieller Natur beispielsweise oder infrastruktureller Natur, dass die auch ganz viel Forschung und Entwicklung machen können, also dass die sich in ihrem Themenbereich weiterbilden, dass die am Puls der Zeit sind sozusagen und hier destillieren, was ist jetzt von den neuen Trends für die Organisation, in der ich tätig bin, relevant, was können wir adaptieren oder was sagen wir, hey, das ist nett, aber das ist irgendwie nichts für uns als Organisation beispielsweise.
Anja: Aber das heißt nicht, dass sich Entwicklungsteams nicht mehr weiterbilden müssen, oder?
Michael: Ne, also natürlich sollten die sich weiterbilden, aber so ein Stream-aligned Team sollte jetzt nicht, ich sage mal, 40–50% seiner Zeit damit verbringen, um rauszufinden, was sind jetzt die neuen Trends bei einer Cloud-Plattform im Umfeld von Softwarearchitektur oder was weiß da gar ja was. Natürlich ist eine gewisse Weiterbildung immer eine gute Sache, aber das Enabling Team kann da natürlich Impulse setzen, dass sie sagen, hey, schaut mal her, wir glauben ehrlich gesagt, das und das und das können für euch relevant sein und schaut mal her, wir haben euch da schon mal ein paar Quellen zusammen gesucht oder ein paar Blogposts, kuratiert oder hier ist ein cooles YouTube Video, da schaut mal her. Das wäre eigentlich eine coole Konferenz, wo man hingehen könnte beispielsweise. Das ist halt das, was das Enabling Team an der Stelle eben einbringt sozusagen.
Sven: Also ich war ja auch schon ein paar Mal in so einem Enabling Team und wenn man so ein Stream-aligned Team, wenn man mit einem Feature-Team oder cross-funktionalen Team arbeitet, das große Problem, was ich halt immer sehe, ist, du kannst dich gar nicht in allem weiterbilden. Also du musst die Fachlichkeit kennen, du musst deine Technologie kennen, keine Ahnung, du musst Spring kennen, du musst Angular kennen, du musst Datenbanktechnologie kennen, du musst Prozesse kennen. Und dann noch zusätzlich Experte zu werden in Security, in betrieblichen Themen, in Infrastruktur, das ist einfach alles zu viel.
Sven: Wir haben so das Motto, dass wir sagen, wir wollen per Osmose dieses Wissen verteilen, weil wir einfach nicht verlangen können, dass die Leute sich überall einarbeiten. Also weil die haben einfach keine Zeit. Also selbst wenn jemand Interesse hat an Infrastruktur oder so. Ja, also es gibt halt noch 27 andere Themen und also um effektiver zu sein, denke ich, ist schon wichtig, dass so ein Stream-aligned Team, also ich will jetzt niemanden aufhalten, sich für irgendwas zu interessieren, aber wir wollen es schon irgendwie auf dem Silbertablett präsentieren, wie man es machen kann.
Anja: Du hattest gesagt, Wissen wird verteilt über Osmose. Kannst du das noch ein bisschen beschreiben, was du damit meinst?
Sven: Also Osmose in der Biologie ist ja, also jetzt, jetzt bin ich auf dünnem Eis, ne? Aber Osmose bedeutet ja, dass ich, ah, jetzt, ich, warte, jetzt muss ich nochmal, also Alistair Cockburn, der hat es mal, der hat mal praktisch diesen Begriff, oder diesen Satz gesagt, wir wollen Wissen über Osmose verteilen und was er damit meint, wir sitzen als Team zusammen und jeder weiß was in dem Team. Und dadurch, dass wir uns ständig unterhalten und unser Wissen teilen, wirst du nach einem Jahr, also auch zum Beispiel, wenn du Pairing machst, du bist kein Experte in, ich sag mal, Datenbanken. Und jetzt pairst du relativ lange mit irgendeinem Datenbank-Experten. Und du musst dich praktisch nicht anstrengen, um nach einem Jahr Datenbank-Experte zu sein. Das wird dir sozusagen geschenkt, indem du einfach mit, das passiert halt einfach so. Also da ist, also er nennt es osmotische Kommunikation. Wir reden, wir unterhalten, wir machen Sachen zusammen. Und wenn ein Experte mit einem Novizen arbeitet, pairt oder einfach nur hinten im Raum sitzt und die Unterhaltung mitbekommt, wird man nach einer gewissen Weise automatisch schlauer. Im Grunde genommen so ähnlich bei INNOQ ist es ja auch, wenn man bei INNOQ arbeitet, es ist unmöglich, kein Architekturexperte zu sein, weil das ist so eine Dauerberieselung und man muss nichts dafür tun. Ja, irgendwann, genau.
Anja: Ja, zumindest irgendwann. Genau. Das bedeutet, in Enabling-Teams coachen allerdings auch, sodass diese Osmose eintreten kann. Das heißt, man kann mit diesen Pairen oder sich coachen lassen, sodass man über Osmose dann Wissen aufnehmen kann.
Michael: Ja, unbedingt. Das sieht ja Team Topologies auch eine dedizierte Interaktionsform vor. Team Topologies sieht drei verschiedene Interaktionsformen vor für Teams. Die Collaboration, also das heißt, es ist eine sehr, sehr enge Form der Zusammenarbeit mit einer sehr hohen Kommunikationsbandbreite, wo ich sage mal, wo man eigentlich auch sagen kann, da haben beide Teams eine gewisse Lieferverantwortung. Dann XaaS, wo die Kommunikationsbandbreite zwischen den Teams sehr niedrig bis nicht existent ist. Also wenn ihr jetzt beispielsweise die Google Maps API verwendet, dann nutzt ihr die as-a-service. Das ist komplett Self-Service-fähig. Ihr müsst jetzt nicht irgendwelche Besprechungen mit dem Maps Team von Google ansetzen, um das Ding nutzen zu können. Ihr nutzt einfach die Dokumentation. Beispielcode der da ist, vielleicht irgendwelche Libraries, seid einsatzfähig an der Stelle. Und dann gibt es halt noch als dritten Interaktionsmodus den der Facilitation und der ist natürlich schon sehr sehr stark auf die Tätigkeit von den Enabling Teams gemünzt. Also das heißt, die moderieren, die coachen, die befähigen, aber was wichtig ist: Sie haben oder sie sollten in dem Umfeld keine fachliche Lieferverantwortung besitzen. Sondern halt erstmal nur befähigen. Soweit die Theorie. In der Praxis gibt es da natürlich bestimmte Grauzonen. Die Welt ist natürlich nicht immer schwarz-weiß, sondern man kann da natürlich auch über andere Facetten nachdenken. Ich muss allerdings gestehen, je mehr ich mich mit dem Thema befasse und je mehr ich da sehe, desto wichtiger halte ich eigentlich diesen Punkt, weil die…
Anja: …keine Lieferartefakte verantworten.
Michael: Richtig, genau. Ja, weil ich will ja eigentlich, dass die Teams, die enabled werden, irgendwann selber lauffähig sind. Ja, und ich finde Verantwortung zu tragen für was, ist immer ein sehr, sehr gutes Zielbild für sowas. Ihr sollt es selber verantworten. Ihr habt es in der Hand, aber ihr bekommt hier eine helfende Hand. Aber die Arbeit müsst ihr machen. Also ihr müsst das tun oder ihr solltet das tun. Das muss natürlich alles wohl dosiert sein. Wir wollen niemanden überfordern. Gerade jetzt in so Transformationsvorhaben ist das manchmal auch nicht ganz einfach, richtig auszubalancieren. Also ich sehe Enabling Teams eigentlich sehr, sehr ungern in der Lieferverantwortung, muss ich gestehen.
Sven: Was sollten die auch liefern?
Anja: Also ich denke da an shared libraries zum Beispiel.
Michael: Oder was man da ganz häufig sieht in größeren Transvormationsvorhaben wo jetzt bei ähnlich bleibender Technologie ein Legacy-System abgelöst wird, sondern wo im Rahmen einer Legacy-Transformation ganz stark an Methodikwandel gearbeitet wird. Wo vielleicht ein Wandel von Wasserfall in Richtung mehr Agilität stattfindet, samt eines Technologiewechsels, also jetzt beispielsweise von Mainframe-Programmierung in Richtung Java auf Kubernetes und was weiß ich was. Das ist natürlich ein riesengroßer Block. Und ein riesengroßer Brocken, den es da in der Organisation zu stemmen gibt. Und dort sehe ich es durchaus regelmäßig, dass solche Enabler embedded in den Teams mit drin setzen. Also, dass die da jetzt sehr, sehr aktiv mitarbeiten. Und da rutscht man natürlich ganz, ganz schnell in diese Lieferverantwortung rein. Selbstredend ist das nicht die Form, die Team Topologies vor sich an der Stelle.
Sven: Ja, aber ist das eigentlich ein Punkt, wo man abweichen könnte? Also, weil, wenn ich jetzt als, ich sag mal, in Anführungszeichen früher, da hat man sich ja auch Know-how eingekauft und hat gesagt, okay, der kann jetzt irgendwie, also, um nochmal auf mein Datenbankbeispiel zurückzukommen, wir haben jetzt einen Experten für irgendeine Technologie oder für irgendeinen Security-Experten, der ist aber rein zufällig auch Software-Entwickler, der kann viele Dinge. Und er arbeitet einfach mit und macht so ein Upskilling von dem Team in diesen Fähigkeiten. Der hat zwar auch Lieferverantwortung, aber hat auch noch eine zweite Verantwortung.
Michael: Also, ich sag mal so, abweichen kann man natürlich immer. Also niemand stoppt daran, davon abzuweichen. Man sollte sich halt, wenn man das tut, der Vor- und Nachteile und der Gefahren sehr, sehr bewusst sein. Ich sag mal, auch das ist wieder sehr kulturell abhängig von Unternehmen. Also wie ist es beispielsweise um die Lernkultur eines Unternehmens bestimmt? Also es gibt Organisationen, wo ein sehr hoher Grad einer Lernkultur ist, wo sehr viele Mitarbeiter und Mitarbeiterinnen sind, die eine hohe intrinsische Motivation haben, sich auch selber weiterzubilden, die so einen Wandel total spannend finden. Es gibt allerdings auch Organisationen, wo diese Lernkultur nur sehr eingeschränkt da ist. Also die Leute gehen halt in eine Schulung, aber die würden sich jetzt in ihrer Freizeit oder nach dem Tagesgeschäft jetzt nicht mit solchen neuen Sachen befassen. Und gerade jetzt im letzteren Fall besteht halt die Gefahr, dass man sich halt die ganze Zeit auf die Enabler verlässt. Das machen die schon, da muss ich mich jetzt nicht damit befassen. Die liefern das, die liefern das. Und dann wird das halt so ein Spielchen bis zum Sankt-Nimmer-Lines-Tag. Und das geht halt nur in meinen Augen über sehr deutlich formulierte Erwartungshaltungen.
Sven: Also so habe ich es auch nicht gemeint. Also für mich war es eher so, ich bin Experte in Performance Testing, aber ich bin auch normaler Softwareentwickler und ich sehe die Gefahr, dass man halt sagt, du bist der Experte in Performance Testing, also machst du immer die Performance Tests. Nee, das kann nicht meine Aufgabe sein. Ich muss, ich muss mal zwei Leute aus dem Team dazu befähigen, dass sie das auch machen können, weil ich bin nämlich über nächste Woche nicht mehr da oder so. Also ich bin nur temporär in dem Team. Aber die Gefahr besteht natürlich schon, das sehe ich ein.
Michael: Die besteht auch noch von anderer Seite. Die Expertin oder der Experte macht es immer am schnellsten. Und der Zeitdruck ist ja meistens enorm. Also ich kenne ehrlich gesagt kaum ein Umfeld, wo es keinen Zeitdruck gibt für irgendwas. Und das ist natürlich super bequem. Wenn man sagt, mach das jetzt mal schnell, du kannst das doch am schnellsten. Bevor irgendjemand, der da neu reinwächst, dreimal so lang braucht. Das ist natürlich eine sehr, sehr kurzfristige Betrachtungsweise, aber diese Verlockung ist natürlich schon sehr süß.
Anja: Ja, das passiert sehr häufig.
Michael:: Das ist auch ganz wichtig für die Enablers selber, dass die sich da nicht breit schlagen lassen und halt dann, ja ich mache es jetzt mal schnell oder ja ich sehe ja die rödeln wie die wilden und Komm, ich mach das jetzt mal eben schnell. Sondern da ist schon natürlich auch die nötige, also einerseits die nötige Sensibilität gefragt, aber auch dann eine gewisse Härte. Nein, ich mach’s jetzt nicht, sondern wir machen das im Pairing oder wir machen das im Mob beispielsweise zusammen. Und das nächste Mal macht ihr es selber und ich pass auf, dass er keinen Blödsinn baut, beispielsweise.
Anja: Ich weiß, Sven, du hattest noch eine Frage, wie Enabling Teams man vergleichen kann zu Center of Excellence. Möchtest du diese Frage stellen? Weil ich denke, die passt dir sehr gut.
Sven: Also Team Topologies macht ja eine große eine Unterscheidung, sagen wir, ein Enabling Team ist kein Center of Excellence. Jetzt könnte man natürlich, wenn wir jetzt sagen, wir haben einen, wir haben Security-Spezialisten, wir haben QA-Spezialisten, wir haben Performance-Test-Spezialisten, wir haben You-Name-It-Spezialisten, da würde doch jetzt so eine normale Organisation sagen, ja, das haben wir ja schon alles. Wir haben schon Enabling Teams, wir haben ja unsere Security-Abteilung und wir haben unsere QA-Abteilung. Wir müssen ja gar nichts ändern. Wir haben ja dieses Center of Excellence. Und da denke ich halt, der Service, also der Gedanke, wie man an das Problem rangeht, ist natürlich der große Unterschied. Michael, wie würdest du diesen Unterschied beschreiben, also von der Herangehensweise?
Michael: Ich glaube, es dreht sich ganz viel um das Thema Vorgaben machen. Auf der einen Seite ist es natürlich so, dass ein Enabling Team sehr stark aus Spezialistinnen und Spezialisten besteht, die sich in einem bestimmten Themengebiet sehr gut auskennen, die da vielleicht auch in den entsprechenden Communities vernetzt sind, die am Puls der Zeit sind und so weiter. Das wären natürlich alles spannende Kandidaten auch für ein Center of Excellence, wie der Name schon besagt. Ich glaube, der Kernunterschied ist halt das Thema inhaltliche Verantwortung und Vorgaben. Also ein Enabling Team sollte in der, ich sage jetzt mal so, reinen, puren Theorie keine Vorgaben machen. Während das Center of Excellence natürlich sehr stark geprägt ist durch das Machen von Vorgaben, aber auch durch das Tragen der Verantwortung für diese Vorgaben. Das ist jetzt mal die reine Theorie. Ich glaube aber in der Praxis verschwimmen die Sachen auch ein bisschen und ich glaube das ist sehr sehr stark davon abhängig von der Ausgangslage, auf die ein Enabling Team trifft. Also wie ist denn in dem Bereich der Zuständigkeit des Enabling Teams beispielsweise die Erfahrung in den Stream-Aligend Teams. Gerade wenn jetzt zum Beispiel so ein technologischer Wechsel ansteht und man macht so ein technologisches, architekturelles Enabling in bestimmten Sachen erlebe ich es regelmäßig, dass die Leute in den Stream-aligned-Teams beispielsweise vollkommen überfordert sind mit den Sachen. Also da prasselt eine Vielzahl an Themen, Frameworks, Begrifflichkeiten, Technologien auf die Leute rein. Und die sehen den Wald vor lauter Bäumen nicht mehr. Und ich glaube, das ist da so ein Punkt, wo man durchaus als Enabling Team mal hergehen kann und sagt, wir hauen jetzt mal folgende Pflöcke in den Boden, und sagen, ihr macht es jetzt einfach mal so. Wir wissen, warum wir es tun und wir setzen jetzt erstmal etwas mehr, wir machen Vorgaben am Anfang. Wir setzen einen Rahmen, in dem ihr euch bewegt, aber mit dem klaren Ziel, diese Vorgaben graduell im Laufe der Zeit mit wachsender Erfahrung, mit wachsendem Wissen wieder zu reduzieren. Das muss natürlich ein klares Ziel sein. Also es muss daran gearbeitet werden, dass diese Menge an Vorgaben durch das Enabling Team wegschmilzt. Wird die irgendwann bei Null ankommen? It depends. Aber ich denke mal, in so einem Umfeld kann es sinnstiftend sein, als Enabling Team auch mal ein bisschen zu agieren wie so ein Center of Excellence.
Sven: Also ich kann mich noch an einen früheren Kunden erinnern, da war es ganz interessant. Die Leute haben tatsächlich gesagt, als wir da aufgetaucht sind, und wir haben jetzt keine Vorgaben gemacht, aber wir haben halt gesagt, wir rammen jetzt mal so einen Pflock hier in, ihr habt ja eine Orientierung, da war die Antwort eher so - total super. Endlich gibt mir jemand Orientierung. Wir können aber auch von der Orientierung abweichen. Wir sind eigentlich, also wir wissen glaube ich schon, was wir tun. Aber wir haben wirklich keine Lust, uns alles von Pontius zu Pilatus selbst zu überlegen. Wäre vielleicht nicht schlecht, wenn jemand mal sagt, was Sache ist.
Anja: Ja. Genau, das ist der Unterschied zwischen Regeln und Prinzipien. Also Regeln sind irgendwie richtig diese Vorgaben, über die du gesprochen hast, Michael, und das, was du gesagt hast, Sven, das sind Prinzipien, von denen man abweichen kann aus guten Gründen, wenn man es besser weiß oder es in diesem Fall für das eigene Team nicht passt.
Michael: Ja, wobei es auch hier wieder ein paar schwierige Bereiche gibt. Ich rede gerne von Leitplanken. Lass uns mal ein ganz konkretes Beispiel durchdiskutieren. Wir haben eine Organisation, die bisher sehr monolithische Systeme beispielsweise am Mainframe gebaut, ganz viel Cobol-Entwicklung, mit sehr, sehr viel wasserfalllastigen Prozessen, sehr, sehr deutlichen Hierarchien, die ausgeprägt sind in der Organisation. Und man möchte jetzt das Delivery-Modell im Rahmen eines Modernisierungsvorhabens abändern. Also man will in Richtung von einer Cloud-Native-Architektur gehen, um mal ein Buzzword zu bemühen in Richtung eines agileren Liefermodells und natürlich auch mit dem Zielbild vielleicht irgendwann, dass man cross-funktionale Teams etabliert. Da ist natürlich sehr, sehr, sehr, sehr viel Enabling vonnöten auf diesem Weg, durch Enabling Teams. Und ich glaube, dass man in so einem Umfeld sehr häufig stark festgefahrene Meinungsbilder sieht, wie Sachen sein müssen. Die aber mit diesem Zielbild kollidieren. Und an der Stelle ist, glaube ich, das mit den Prinzipien noch ein Ticken zu weich. Also ich würde dort Leitplanken setzen. Also erst mal enger getaktete Leitplanken als Enabling Team. Wir gehen jetzt mal in diese Richtung, in diese Richtung. Und da ist natürlich Vertrauen fassen in den Teams eine ganz, ganz wichtige Sache, dass die Teams erkennen, okay, das hilft uns, auch wenn wir vielleicht ein bisschen Bauchgrummeln haben, weil sich das ganz, ganz anders anfühlt. Und dann graduell erweitert man diese Leitplanken. Aber die Leitplanken im Hinblick des Zielbilds bleiben jetzt erstmal bestehen. Also eine Möglichkeit wäre beispielsweise, wenn wir mal ganz konkret reden, zum Beispiel solche Themen wie Mikro- und Makroarchitektur. Makroarchitektur sind architektonische Vorgaben, die für alle Teams verpflichtend sind. Mikroarchitektur ist für die Teams der architektonische Entscheidungsrahmen, wo die selber Entscheidungen fallen können. Da kann man sagen, dass so ein Enabling Team am Anfang durchaus gewisse makroarchitektonische Vorgaben macht, die potenziell umfangreicher sind, um halt dann graduell die Leute zu befähigen, eigene Architekturentscheidungen, zum Beispiel für verteilte Systeme, treffen zu können. Man reduziert dann diesen Raum und das Enabling Team wechselt dann graduell rüber, weg vom Vorgabenmachen zur Moderation. Dass die Teams eben diese Makroarchitektur selber vorantreiben und das Enabling Team moderiert dann. Und am Ende ist diese Moderation auch vielleicht nicht mehr nötig. Ja.
Anja: Wichtig ist, dass wir hier nochmal uns in den Sinn bringen, dass es mehrere Enabling Teams geben kann. Also du hast, wir haben jetzt öfter über nur einem Enabling Team gesprochen, aber es sind ja mehrere. Security enabling Team, QA, Architektur, du hattest noch gesagt IT Security und so weiter. Also sozusagen ein Zusammenspiel von mehreren Enabling Teams am Ende.
Michael: Auf jeden Fall. Und man muss jetzt auch eines sagen, nicht dass sich da manche Hörerinnen und Hörer denken, also irgendwie das, was der Plöd erzählt, das hat ja jetzt recht wenig mit der Literatur zu tun. Wir reden da gerade von Abweichungen, von der originären Idee, die vielleicht initial sinnvoll sind, aber natürlich in Richtung der originären Idee hinarbeiten sollen. Mir geht es immer um einen praxisorientierten pragmatischen Einsatz dieser Ideen.
Anja: Gut, eine Frage, die wir uns noch aufgeschrieben haben und die mir auch ein paar Mal gestellt wurde, ist, rechnet sich so ein Enabling Team eigentlich? Ist das nicht totaler purer Luxus? Also, ist so ein Enabling Team oder sind mehrere Enabling Teams in einer Organisation überhaupt wirtschaftlich?
Michael: Das ist eine spannende Frage. Ich glaube, die werden wir erst im Laufe der Zeit beurteilen können. Ich glaube, da jetzt aus dem Brusthorn der Überzeugung zu sagen, je mehr Enabling Teams, desto besser und das ist wirtschaftlich auf jeden Fall ein Use Case, ich glaube, das wäre vermessen. Ich glaube, wir können die Frage momentan noch nicht wirklich beantworten. Und ich glaube, das wird auch keine Ja-Nein-Antwort sein. Ich glaube, die Antwort wird so eine Windelweiche, Wachsweiche, es kommt drauf an Aussage sein. Also ich denke, wenn man ein ambitioniertes Transformationsvorhaben startet in einer Organisation, sind diese Enabling Teams auf jeden Fall sinnstiftend. Werde ich im Laufe dieser Transformation diese Menge an Enabling Teams dann noch brauchen, das würde ich sehr stark in Zweifel ziehen. Ich würde mich halt da drauf konzentrieren für die Bereiche, die dann wirklich nötig sind, dauerhaft nötig sind. Also für mich kann ein Enabling Team auch potenziell eine temporäre Sache sein, dass das für drei, vier Jahre existiert und dann dieses Know-how in den anderen Teams aufgeht und die Team-Mitglieder aus den Enabling Teams dann in die einzelnen Stream-aligned oder Plattform-Teams eben beispielsweise reingehen. Das ist auch etwas, was ganz wichtig ist. Also Team Topologies propagiert ja von Haus aus einen evolutionären Organisationsentwurf. Also kein, wir machen jetzt einmal eine Organisation und wir bleiben bis zum St. Nimmerleinstag so stehen, wie sie ist, sondern die Sachen sollen im Fluss sein natürlich will jetzt niemand eine teilweise Reorganisation an der stelle empfehlen ja es ist blödsinn sowas natürlich ganz klar. Aber Organisation sollte im Fluss sein und das betrifft natürlich auch die Enabling Teams oder auch Complicated Subsystem Teams. Also ich kann mir sehr sehr gut vorstellen, dass so ein Complicated Subsystem Team irgendwann mal aufgeht, zum Beispiel in Form einer Plattform und einem Enabling Team.
Michael: Dass man eben dieses Spezialwissen bündelt, als Plattform den anderen anbietet und dort dann entsprechendes Enabling anbietet. Ein ganz, ganz spannendes Buch an der Stelle ist beispielsweise Dynamic Reteaming von der Da Heidi Helfand. Also die da eben diesen Fluss, diese Evolution sehr, sehr schön in ihrem Buch beschreibt. Das kann ich absolut empfehlen dazu.
Anja: Packen wir die Shownotes.
Sven: Also ich kann mich halt noch erinnern, wir hatten, wir waren ja beim Kunden, also hier besagte Performance Testing. Da gab es tatsächlich auch so ein, da haben wir so eine Art Lebenszyklus gehabt, wie du es beschrieben hast. Also am Anfang war ganz wichtig, dass alles musste Performance getestet werden. Und da war das Enabling Team Performance Test war super busy. Aber irgendwann haben die Leute das halt einfach drauf gehabt. Also es war ein erledigtes Problem. Dann sind wir die Frage, was machen wir jetzt mit dem Team? Naja, wir reduzieren es halt. Die Leute gehen halt woanders rein. Das Team ist nicht ganz tot, weil es gibt ja auch neue Teams. Da gibt es ein neues Team, die müssen auch irgendwie das lernen, aber es ist halt ein deutlich geringerer Aufwand. Also dann lohnt sich so ein großes Team nicht mehr. Wir waren anderswo verteilt und haben uns halt noch mal so zusammengesetzt, wenn es gerade was gab. Lustigerweise noch zusätzlicher Kommentar. Also wir wurden immer bezahlt. Also wir waren halt einfach da. Also eh-da-Kosten sozusagen. Und irgendwann hat die Organisation gesagt, das fand ich ganz interessanten Gedanken gegangen. Die Kosten für diese Teams, die werden euch, die werden den Stream-aligned Teams, also die müssen dafür bezahlen. Und dann entscheiden die, ob denen das Ganze, ob das denen das Ganze wert ist. Also dann kannst du, das ist halt ein Service, den kannst du einkaufen. Und dann kannst du, kannst du gucken.
Michael: Ich finde die Idee total super. Ich bin totaler Freund von solchen Ideen. Also ich gehöre potenziell zu denjenigen, die so Unternehmertum im Unternehmen immer sehr sehr spannend und sehr interessant finden. Und da kann man natürlich auch sagen, dass so ein EnablingTeam wie so eine interne Consulting-Bude tickt. Und das Enabling Team kann ein eigenes Pricing-Modell etablieren. Kann bestimmte Workshops zu bestimmten Fixpreisen anbieten, also jetzt zum Beispiel so, hey, kauft euch mal eine Event Storming Facilitation mit einem Facilitator von uns für, was weiß ich was, 1500 Euro am Tag oder was weiß der Geier was, ja, oder 2000 Euro am Tag und wir bieten da noch Vor- und Nachbereitung und Befähigung von Teammitgliedern etc. Das kann natürlich, also mir gefällt sowas total gut. Aber, jetzt auch wieder die andere Seite, die Organisation muss kulturell dafür aufgestellt sein. Es gibt Organisationen, wo viele Mitarbeiterinnen und Mitarbeiter auf sowas überhaupt keinen Bock haben. Und dann hebt sowas nicht ab. Also wenn du den Leuten sagst, hey, euer Team kann halt so lange existieren, wie es in dem Business Case hat. Wenn ihr kein Angebot mehr habt für die anderen, müsst ihr überlegen, wo ihr hinwechselt. Das ist natürlich eine extrem, ich sage mal, liberal geprägte Unternehmenskultur. Ich sage mal so, ich kann sämtliche kritische Stimmen daran komplett nachvollziehen und ich möchte sowas nie als den goldenen Weg in den Raum werfen, den man immer geben muss. Ich persönlich finde es interessant, ich finde es spannend, aber ich habe vollstes Verständnis dafür, dass es zahlreiche Arbeitnehmer und Arbeitnehmerinnen gibt, die auf sowas keinen Bock haben. Und an der Stelle, das ist ein Thema, das ich auch gerne hier in dem Podcast auch noch mit reinbringen möchte, ist es natürlich ganz, ganz wichtig, dass man beim Etablieren von solchen Teams die Personalabteilung, Betriebsräte, Arbeitnehmervertretungen ganz, ganz frühzeitig mit reinholt. Weil das hat so viele Implikationen, auch arbeitsrechtlicher Natur, die muss man unbedingt auf dem Schirm haben. Also ihr könnt jetzt nicht hergehen, das machen wir einfach so, weil das in einem Buch steht mit bunten Seiten und einem weißen Cover, das einen super Ruf hat. Holt diese Stakeholder da frühzeitigst mit rein.
Anja: Welche Themen müssen denn dann besprochen werden mit der Personalabteilung?
Michael: Also ich sage mal so, beispielsweise wenn du ein Team hast, das bisher Vorgaben gemacht hat. Das ist zum Beispiel etwas, was ich schon bei mehreren Kunden erlebt habe. In sehr vielen, ich sage mal größeren Organisationen, das fängt eigentlich schon bei größeren Mittelständlern an, gibt es Gehaltsbänder im Gehaltssystem beispielsweise. Was ist ein Gehaltsband? Das sind bestimmte Stufen, Tätigkeiten gelistet, also jetzt weiß ich was, Software-Engineer, Software-Architektin, Fach-Expertin oder was weiß der Geier was? Und da gibt es verschiedene Stufen, Stufe 1, 2, 3, 4 und die Gehaltsbänder sagen, wenn du jetzt beispielsweise Fach-Experte auf der Stufe 2 bist, kannst du von X bis Y in etwa verdienen, das ist so die Gehalts-Range, das Gehaltsband, aber du musst dafür folgende Sachen machen. Und da kann es jetzt beispielsweise sein, das habe ich sowohl auf einer Fachseite gesehen, als auch schon auf einer Architekturseite, das in diesem Gehaltsmodell ist, zum Beispiel Softwarearchitektin Ebene 3 macht anderen Teams Vorgaben und trägt die Verantwortung für diese Vorgaben. Jetzt wenn ihr hergeht und das gleiche geht auf der Fachseite genauso, habe ich da genauso gesehen, macht Entwicklungsteams technische fachliche Vorgaben, schreibt an Spezifikationen mit etc. Das ist ja eigentlich etwas, was wir zum Beispiel im Rahmen einer agilen Transformation verändern wollen. Wir wollen ja eigentlich eher eine cross-funktionale Kollaboration etablieren, wo niemand mehr jemand anderen sagt, du machst das jetzt, friss oder stirb, sondern eher, wir erarbeiten uns die Vorgaben zusammen, wir verantworten die als Team zusammen, Ende zu Ende. So, und wenn ihr jetzt sowas etabliert, beispielsweise über Enabling Teams, im Bereich Architektur. Da hat einmal der Betriebsrat angeklopft und gesagt, hey, ist euch klar, dass ihr die Leute daran hindert, dass sie Gehaltserhöhungen kriegen? Weil sie plötzlich diese Stufe 3 nicht mehr erfüllen. Die sollen ja keine Vorgaben mehr machen. Und das ist natürlich ein harter Grund und kann natürlich ein schwerwiegendes Problem beim Etablieren von solchen Teams sein. Also da kann es durchaus sein, dass man plötzlich über Veränderungen an diesen Gehaltsklassen spricht. Also zum Beispiel, ich hab’s einmal erlebt, da wurde halt dann das Modell angepasst, macht anderen Vorgaben oder befähigt andere. Also quasi so erstmal ein Oder reingebaut, aber eigentlich mit dem Ziel dieses macht Vorgaben weitestgehend zu reduzieren. Und sowas steht halt nicht im Buch. Da sind natürlich auch andere Länder, andere Sitten. Da ist natürlich der deutschsprachige Bereich anders aufgestellt wie beispielsweise der angelsächsische Bereich, was Arbeitnehmervertretungen und so weiter und so fort angeht. Eure Personalabteilungen. Die sollten sowas eigentlich am Schirm haben. Also geht frühzeitig hin. In vielen Organisationen gibt es beispielsweise auch Teams für Personalentwicklung, mit denen man sowas auch diskutieren kann. Weil manchmal müssen ja auch vielleicht die Enabler erst mal für’s Enabling enabelt werden, um mal ein Wortspiel zu bemühen jetzt an der Stelle. Wenn die Leute das noch nie gemacht haben, wenn die bisher immer Vorgaben gemacht haben und jetzt dann plötzlich andere befähigen sollen, coachen sollen, das sind ja ganz andere Fähigkeiten, die da gefordert sind und das fällt ja nicht einfach vom Himmel oder das sind ja auch Sachen, die es zu erlernen gilt. Da kann natürlich auch so eine Personalentwicklung durchaus unterstützend bei sowas.
Sven: Wie würdest du das sehen? Jetzt so Staffing von so einem Team, also klar, wenn ich auf der grünen Wiese anfange, ja, also ich hab noch nix, ja, und ich sag, ich will ein enabling Team haben, dann kann ich, also wenn ich da bin, wie stuffe ich so ein Team? Also auf welche Eigenschaften, Fähigkeiten muss ich da acht geben? Was muss so ein Teammitglied können?
Michael: Also erstmal natürlich fachliches Know-how. Also das ist so die absolute Basis. Die Person sollte fachlich tief in dem Thema drin stecken und auch eine Leidenschaft für das Thema haben. Also das ist glaube ich ganz ganz wichtig. Das ist die Basis. Darüber hinaus halte ich beispielsweise Kommunikationsfähigkeit in Richtung verschiedenster Stakeholder für eine wichtige Eigenschaft, also Kommunikationsskills in verbaler, visueller und schriftlicher Form. Also ich sag mal so, da kann sich auch so ein Team gegenseitig ergänzen. Also jetzt beispielsweise, wenn ich jetzt mal über mich reflektiere, ich selber, ich glaube ich bin in verbaler und visueller Kommunikation deutlich stärker als in schriftlicher Kommunikation. Das ist vielleicht irgendwie so eine Ironie des Schicksals, aber ich schreibe nicht gern, obwohl ich jetzt das Buch übersetzt habe. Aber ich halte lieber Konferenzvorträge und kommuniziere mit Leuten zusammen, sowohl persönlich wie remote. Es gibt andere, die haben exzellente technische Schreibskills. Da kann sich dann natürlich so ein Team gegenseitig auch ergänzen, aber man sollte halt schauen, dass das Team in Summe in diesen Kommunikationsformen gut ist von der Zusammensetzung. Also wenn man jetzt nur Leute hat, die total gut schreiben können, aber in der verbalen visuellen Kommunikation jetzt vielleicht nicht so gut sind, ist das Team weniger schlagkräftig. Wie ein Team, das eben all diese Bereiche komplett abdeckt.
Anja: weil sie eben viel kommunizieren müssen, Dinge aufschreiben müssen und so weiter. Deswegen ist das wichtig.
Michael: Das ist die Haupttätigkeit eines solchen Teams, Kommunikation. Das nächste, was ich für wichtig halte, ist Empathie. Das heißt, die müssen eine Fähigkeit haben, sich in die Perspektive der zu befähigenden Personen reinzuversetzen. Also, wo kann ich die jetzt mal ein bisschen aus der Komfortzone ziehen? Oder wo lasse ich die jetzt lieber erst einmal noch drinnen? Da eine nötige Sensibilität walten zu lassen. Das ist irre schwer, vor allem wenn viel Politik und viele Erwartungshaltungen darum schwirren. Ich glaube Empathie ist wichtiger als Durchsetzungsfähigkeit. Also ich will als Enabling Team jetzt nicht mit dem Vorschlaghammer kann man Sachen durchhauen, sondern ich möchte die Leute befähigen und auch vielleicht begeistern für die Sachen. Deshalb halte ich Empathie auch für eine ganz ganz wichtige Eigenschaft. Und das nächste ist natürlich, ich sage mal so, Moderations-Coaching-Skills. Also, dass die Leute in der Lage sind, so einen Workshop zu organisieren, dass die verschiedensten Methodendes Coachings, wie beispielsweise Pair-Programming, Arbeiten im Mob, irgendwelche kollaborativen Modellierungstechniken wie Event Storming, User Story Mapping, je nach Aufgabe des Enabling Teams natürlich beherrschen. Auch hier muss nicht jede Person im Team alles perfekt können. Kann natürlich sein, dass die Leute sich ergänzen. Hey, da steht ein Mob Programming an Sven, da bist doch du total gut drin und die Anja ist beispielsweise im Pair Programming super stark, während derMichael so kollaborative Workshops ganz gut etablieren kann. Das ist völlig okay, aber das wäre etwas, was ich in so einem Team gerne drin hätte an Skills, die mir persönlich wichtig wären.
Sven: Wenn ich jetzt, also ich meine, das ist schon relativ anspruchsvoll, würde ich mal sagen. Und vielleicht kriegt man so ein Team nicht direkt genauso zusammen. Ist das, also ich frage mich gerade, weil wir sind halt auch, sagen wir mal, blauäugig gestartet. Aber wir hatten also einen Vorteil, wo ich gesagt habe, wir hatten diesen, also die Kosten für uns wurden auf die Teams übertragen. Das war nicht direkt so. Das war erst mal so eine Weile wird bezahlt. Aber hier ist ein bisschen Druck. Also ihr müsst diesen Service Gedanken, also ihr müsst die anderen zum Erfolg führen. Dafür habt ihr Zeit, aber nicht zu viel Zeit. Also nicht unendlich viel Zeit. Also das fand ich ganz wichtig, aber auch zu kommunizieren, also das haben wir jetzt irgendwie nicht gemacht, aber das höre ich jetzt so raus, dass man halt einfach sagt, das ist so, so sieht unser Enabling Team der Zukunft idealerweise aus. Diese Skills müssen die Leute haben, aber seid noch ein bisschen, liebe Stream-aligned Team, seid noch ein bisschen nachsichtig, wenn das noch nicht zu 100 Prozent funktioniert. Also gerade als du jetzt über Empathie gesprochen hast, da fallen mir jetzt direkt so ein paar sehr unempathische Situationen ein, wo ich halt denke, ja, da muss man vielleicht dieser Person oder mir, je nachdem, noch ein bisschen Zeit geben. Man kann das alles von Anfang an gut können. Vielleicht zum, zum Abschluss hätte ich noch mal gerne über Cannibalisierung gesprochen, weil wir hatten jetzt keine besonders gute Lösung gefunden. Das Problem war, wir hatten unterschiedliche Enabling Teams. Security Enabling Team, Site Reliability Engineering Enabling, also Operations, Production Readiness Team, you name it. Es gab ganz viele. Und alle gehen halt zu den Stream-aligned Teams und sagen, wir sind hier, um euch zu helfen. Und dann sagen die halt, ja danke, aber wenn jetzt irgendwie fünf oder sechs von diesen Stream-aligned Teams hier aufschlagen und uns helfen wollen, dann kommen wir wieder zu nichts. Also eine Frage, wie geht man daran, dass man mit zu viel kommt? Wie priorisiert man?
Michael: Ich war bis jetzt noch nicht in so einer Situation, wo das der Fall war, muss ich gestehen. Das heißt, ich habe jetzt keine konkrete Praxiserfahrung in dem Umfeld. Aber ein Vorschlag, der mir aus dem Bauch heraus einfällt ist, dass jedes Enabling Team einfach mal auf einer Wikiseite oder in der Präsentation oder im Intranet sein Leistungsportfolio darstellt. Vielleicht auch im Rahmen von einem kurzen Pitch den Teams vorstellt. Und die Teams sollen dann für sich entscheiden, wo sie jetzt erstmal prioritär das Enabling benötigen. Ich glaube, damit würde ich mal starten. Es kann natürlich sein, die Gefahr ist, dass die Teams vielleicht noch nicht erkennen, dass sie eigentlich ein bestimmtes Enabling dringender bräuchten. Das ist so die Lücke an der Stelle. Ich glaube, da sollten die einzelnen Enabling Teams untereinander vielleicht sich absprechen und sagen, hey du, schau mal her. Ihr solltet mit denen doch vielleicht noch mal reden. Da und da sind vielleicht ein paar Sachen im Argen, die man unbedingt vermitteln sollten und so weiter. Aber ich würde mal sagen, Bauchgefühl, ich glaube, das ist ein Ausnahmefall. Das ist nicht die Regel. Ich glaube, meistens wissen die Leute in so einem Team schon ganz genau, wo sie Unterstützung brauchen und wo nicht. Aber die müssen halt auch wissen, erst einmal, was gibt es denn überhaupt für Unterstützungsangebote? Was ist denn da? Ich glaube, das Angebot würde ich halt einfach mal sehr transparent machen. Und es muss einfach sein, die Unterstützung zu bekommen. Nicht erst fünf Sachen etc., sondern vielleicht auch im XaaS-Fähigkeit. Hey, ich brauch das mal und zwei Tage später ist jemand da.
Sven: Ja, also habe ich auch schon, genau die umgekehrte Erfahrung habe ich schon gemacht. Wir brauchen hier jemand für, also es war jetzt, jemand wollte dabei sein beim Event Storming Workshop, also er musste dabei sein. Und es hat Wochen und Monate gedauert, bis wir gesagt haben, wir können nicht mehr, also sorry. Okay, ja, vielen Dank.
Anja: Vielen Dank, Michael, für die Beantwortung unserer dringenden Fragen und danke, Sven, für deine Einsichten als Teil eines Enabling Teams. Dann bis zum nächsten Mal. Tschüss.
Michael: Ja. Genau. Vielen Dank, dass ich bei euch sein durfte. Hat Spaß gemacht.
Sven: Bis dann, ciao ciao!
Michael:: Bis denn. Ciao.
Anja:: Dann bis zum nächsten Mal.