#21 Team Topologies mit Robert Ruzitschka

00:00:05: Es hatte keinen Sinn. Man kann ja nicht von Agilität sprechen, wenn ich zwei Wochen brauche, bis ich ein neues Release in Produktion bringe.

00:00:11: Robert Ruzitschka ist Community Lead und Agile Engineering Coach bei der österreichischen Raiffeisenbank International mit 45.000 Mitarbeitern. Im Podcast sprechen wir über die IT Transformation der Raiffeisen Bank International und welchen Beitrag Team Topologies für die Entwicklung des Operating und Organisationsmodells hatte. Robert, herzlich willkommen!

00:00:33: Hallo Andreas, freut mich, dass ich hier bin.

00:00:36: Noch! (lacht) Das kann sich ändern. Schauen wir mal, wo wir rauskommen heute.

00:00:41: Da bin ich zuversichtlich. (lacht) Da wird nichts passieren.

00:00:44: Sehr gut. Ihr habt ja eine sehr interessante IT Transformation hinter euch. Magst du uns mal kurz auf eine kurze Reise mitnehmen? Im Galopp einmal durch die komplette Transformation. Wo habt da angefangen? Wo steht ihr heute?

00:00:58: Ja, das kann ich mal versuchen. Das ist natürlich eine längere Geschichte. Ich versuche mich da ein bisschen kurz zu fassen. Ich komme aus einer großen Bank, ein sehr traditionsbewusstes und traditionelles Unternehmen, sowohl was das Business als auch was die IT betrifft. Das heißt, da gibt es eine jahrzehntelange Tradition. Aber irgendwann so, ja, so gegen 2016 - natürlich vorher auch schon ein bisschen -, aber da hat sich das dann so herauskristallisiert, ist klar, wir müssen jetzt ein bisschen was unternehmen. Die Konkurrenz schläft nicht, da wachsen Internetbanken irgendwie raus, die uns möglicherweise Kunden wegnehmen. Das heißt, wir müssen uns jetzt mal doch ein bisschen um die moderne Technologie und um moderne Arbeitsweisen kümmern. Und genau das hat so ungefähr 2016 gestartet und der Ansatz, der da gewählt wurde, war aus meiner Sicht ein ganz guter. Wobei ich ehrlicherweise sagen muss, ich bin 2018 in die Bank gekommen. Das heißt, ganz am Anfang war ich nicht dabei. Aber der Ansatz, der gewählt wurde, war der... Man hat so ein kleines Greenfield Projekt gestartet, ein bisschen außerhalb der IT-Organisation, relativ eigenständig. Und dort hat man dann begonnen, mit modernen Technologien und mit modernen Arbeitsweisen - also agil - ein relativ modernes Produkt, nämlich eine Mobile Banking Solution zu entwickeln, die gut eingebettet in die Infrastruktur der Bank war.

00:02:29: Und natürlich gab es Verbindungen zu anderen Systemen in der Bank. Aber im Großen und Ganzen hat man drauf geschaut, dass hier eine kleine Seitenorganisation entsteht, die relativ getrennt von der anderen Organisation der Bank ist und hier eben einfach ein bisschen freier neue Dinge ausprobieren kann. Das hat relativ klein begonnen. Ich glaube, es waren so zu Beginn zehn Mitarbeiter, da wurde auch frisch vom Markt versucht, Mitarbeiter zu bekommen. Genau. Und so ist es gestartet. Also außerhalb, ein bisserl Greenfieldcharakter. Da gab es dann auch moderne Büros und so. Und so ist es losgegangen und das Modell war relativ erfolgreich. Diese Organisation, die so ein bisschen außerhalb stand, ist dann mit der Zeit ziemlich gewachsen. Ich würde sagen, über die Jahre bis zu 100 Mitarbeiter. Das war dann nicht mehr nur eine Mobile Banking Applikation, sondern da wurde auch eine cloudbasierte Plattform entwickelt. KYC Systeme, das sind so Systeme, Know your customer, alle diese Dinge, aber alles basierend auf moderner Technologie, alles agil, junge Leute und alles nach wie vor ein bisschen abgekoppelt vom Rest der Organisation.

00:03:44: Das heißt auf der grünen Wiese einfach mal den jungen Kreativen, den, könnte fast sagen, Rebellen mal eine Plattform gegeben und gesagt, macht mal, wie viele Leute waren das am Anfang?

00:03:53: Genau. Also ich gehe davon aus, es wurde wirklich klein begonnen, also mit zehn, fünfzehn Mitarbeitern und nach und nach ist das eben gewachsen auf bis zu 100. Und ungefähr so nach zwei, drei Jahren hat man dann begonnen, basierend auch auf diesen Ergebnissen das ein bisschen genauer anzuschauen. Das hat dann natürlich eine Größe erreicht, wo das nicht mehr so im Stealth Mode geht. Und dann wurde begonnen, basierend auf diesen Erfahrungen, die gesamte IT-Organisation zu verändern.

00:04:25: Zumal ihr ja nicht irgendwie lustige Prototypen gebaut habt, sondern ihr habt ja durch Anbindung an Kernsysteme auch ein Produkt geschaffen, was nachher ja nicht nur irgendwie in der abgekapselten Welt funktioniert, sondern was ja anscheinend dann auch wirklich an den Markt gebracht wurde.

00:04:39: Genauso ist es, ja.

00:04:40: Das hat ja... Das heißt, das erfordert ja auch eine Interaktion mit dem Rest der Organisation.

00:04:46: Selbstverständlich, ja.

00:04:48: Gab es da ja Schmerzpunkte? Hieß es, "Ach, lass die Verrückten mal machen. Hier haben sie, was sie brauchen", oder? Ja, es passiert ja. Ich hatte letztens einen Podcast mit dem Thomas Sattelberger und da haben wir sehr lange tatsächlich über diesen Ansatz gesprochen. Eindeutiger Tenor nach seiner Erfahrung, wenn du Innovation willst, musst du genau diesen Weg gehen. Und dann ist deine wichtigste Aufgabe, die vor dem ganzen Bürokratismus, von der Bürokratie, der alten Organisation eigentlich zu schützen. Und gerade wenn ich jetzt aber über Schnittstellen rede und über Anbindung an Kernsysteme, dann kann ich ja durchaus auch mal ausgebremst werden. Wie war das bei euch?

00:05:30: Das ist sicher so, ja, und da gab es sicher an diesen Schnittstellen zwischen altstrukturierter Organisation und neustrukturierter Organisation gab sicher Reibungspunkte. Es war ganz klar. Ich muss schon sagen, dass auch früher unsere IT-Organisation relativ gut aufgestellt war und recht effektiv gearbeitet hat. Da gibt es jetzt nichts wirklich herumzumeckern. Das war jetzt keine wirkliche... Da waren jetzt keine wirklichen Konfliktpunkte, das kann man so nicht sagen. Aber klar war, dass natürlich das Tempo in dieser abgekapselten Greenfield ähnlichen Organisation deutlich höher war als im traditionellen Bereich, wo halt ganz viel wasserfallartig gemacht wurde. Ich glaube, da gab es durchaus eben Reibungspunkte, aber da gab es durchaus auch schon ein erstes Aufhorchen auch von Leuten in der alten Organisation, die gesagt haben, okay, da passiert was. Das klingt recht spannend. Ich würde mal sagen, da war das Feedback hier war so ein bisschen gemischt. Also, das hat großes Interesse bei vielen Mitarbeitern hervorgerufen, aber natürlich auch ein bisschen Zurückhaltung und - Widerstand ist vielleicht ein bisschen ein starkes Wort - aber Skepsis auf jeden Fall.

00:06:50: Habt ihr denen am Anfang dann wirklich, also, was Technologien angeht, was Arbeitsweisen angeht, habt ihr wirklich gesagt, macht was ihr wollt? Oder gab es da gewisse Rahmenbedingungen?

00:06:58: Na ja. Also was klar war, war doch, dass wir, wenn wir hier was Neues machen, das muss alles sozusagen sofort in der Cloud implementiert werden. Das war mal sicher eine Vorgabe. Sonst gab es da relativ große Freiheit, was einfach auch damit zu tun hat, dass die Technologien, die wir dort benutzt haben, bisher in der Bank ja kaum verwendet wurden. Es gab niemanden, der mobile Apps gemacht hat. Es gab niemanden, der in größerem Ausmaß mit Cloudinfrastruktur gearbeitet hat. Das heißt, es war relativ klar, dass die Experten dort in diesem etwas abgeschlossenen Organisationsteil da eher große Freiheit haben. Aber es war natürlich auch Teil des grundsätzlichen Organisationsdesigns. Wir wollten autonome Teams haben, die hier mehr selber entscheiden können, wo es keine starke Governance auch aus technologischer Sicht gibt. Das ist ja so, im regulierten Bereich ist das ja immer so dieses Wort, das alle fürchten, Governance, also diese strenge, zentrale Regulierung. Und das wollten wir da auf jeden Fall weghaben.

00:08:05: Das heißt, gestartet mit zwei Händen von Leuten, dann skaliert auf ungefähr 100 Personen, die auch mehrere Produkte machen. Und dann kam es ja anscheinend irgendwann mal auf dieser Reise an einen Punkt, wo man sich mal überlegt hat, na gut, dauerhaft wollen wir nicht zwei Organisationen pflegen, sondern da war es dann eher ein ein Merger unter Gleichen, sag ich mal, oder wer hat dann eigentlich wem erzählt, wie es geht? Es ist ja oft so, wenn ich so neue Dinge anfange, kann es ja leider nun mal im Rahmen einer solchen Transformation vorkommen, dass eine Seite so ein bisschen übers Ziel hinausschießt. Die Neuen sagen, sie haben die Weisheit mit Löffeln gefressen. "Jetzt erklären wir euch mal, wie der Hase läuft" oder, dass die Alten sagen "Ja gut, das funktioniert doch sowieso nicht." Also da immer noch sehr aktiv in den Widerstand gehen. Das heißt, das braucht ja, das darf sich ja dann so ein bisschen zusammenfinden. Wie ist dieser Weg gelaufen dann?

00:09:01: Das ist es genau richtig. Du hast das genau richtig beschrieben. Also, klar war, dass sozusagen, wenn wir diese beiden Arbeitsweisen zusammenführen wollen, dann bedarf das auch einer größeren Organisationsänderung. Und das wurde dann so ungefähr 2018 angegangen. Da wurde tatsächlich die alte IT-Organisation wirklich komplett umgebaut in Richtung Produktorientierung. Kleinere Teams mit größerer Autonomie, Hierarchien wurden da radikal verflacht. Vielleicht sprechen wir nachher sowieso noch ein bisschen darüber. Im Großen und Ganzen geht die Organisation oder ging die Organisationstransformation ganz klar in kleine Teams mit hoher Autonomie, die dann thematisch gegliedert in Tribes zusammengefasst werden. Ganz flache Organisation, viel mehr Verantwortung für die Product Owner. Raus aus dieser Hierarchie, wo People Manager über ganz viele Dinge entscheiden. Also, da hat sich ganz viel getan. Das war klar, dass wir, wenn wir neue Arbeitsweisen irgendwie implementieren wollen, dass wir dann auch die Organisation substanziell verändern wollen und müssen. Das war ein schwieriger und schmerzhafter Prozess, der einige Zeit gedauert hat. Und wie du sagst, also natürlich gab es da die in diesem neuen, abgetrennten Teil, die gesagt haben, "Wir wissen natürlich, wie alles geht." Und die anderen haben gesagt in der alten Organisation, "So geht es nicht weiter. Wir müssen das alles strenger und genauer planen." Und im Endeffekt kam natürlich sowas raus wie so ein bisschen ein Mittelweg. Aber ich würde schon sagen, dass der Mittelweg ganz stark eine Schlagseite hat. Und die Schlagseite ist in Richtung moderne Arbeitsweisen. Also die, man kann sagen, die alte Organisation hat da sicher nicht gewonnen in diesem Spannungsfeld, sondern eher die neue.

00:11:00: Einen Eckpfeiler hast du ja schon gesagt kleine autonome Teams von maximal zehn Leuten. Orientiert ihr euch auf einer, sagen wir mal auf einem Flight Level Eins an Vorgehensmodellen wie Scrum oder ist es den Teams überlassen?

00:11:17: Ja, im Großen und Ganzen sozusagen haben wir als Arbeitsmodell Scrum ausgewählt, wobei die Teams hier relativ autonom sind. Aber die Erfahrung zeigt, dass die meisten Teams Scrum verwenden. Es gibt auch Teams, die mehr in Richtung floworientierter Vorgehensweise gehen, also die Kanban verwenden. Aber ich würde mal sagen, 80 % der Teams verwenden Scrum. Das ist vielleicht ein ganz interessanter Punkt, weil wir haben ja absichtlich vermieden, dass wir in diese großen Frameworks irgendwie einsteigen und so was wie SAFe verwenden, weil unser Ziel war immer klar. Wir wollten ganz stark in die Autonomie gehen und versuchen, sowohl in unserer Organisation, auch als auch in unserer Architektur die Dinge zu entkoppeln, Abhängigkeiten zu reduzieren. Und deshalb war für uns klar, dass wir jetzt nichts Übergreifendes irgendwie drüberstülpen wollen, was uns hilft, die Abhängigkeiten zu managen. Sondern die Idee war wirklich, was können wir tun, damit wir die Abhängigkeiten möglichst reduzieren, damit wir die Teams so autonom wie möglich bekommen und damit auch diesen Flow an Änderungen, diesen ungestörten einfach in die Organisation bringen.

00:12:29: Auf die Abhängigkeiten würde ich besonders wenn man noch mal über die Teamtopologien sprechen, darauf zurückkommen. Aber kurz eine Zwischenfrage, damit die nicht nicht untergeht. Du hattest ja auch gesagt, ihr habt viele Management-Hierarchien einfach aus der Organisation entfernt.

00:12:43: Genau.

00:12:43: Kannst du dazu noch was sagen? Wie war das? Natürlich tut es weh. Es geht ja mit auch Statusverlust einher. Sind viele Leute gegangen? Konnten das alle mitgehen? Was hat das mit euch gemacht?

00:12:56: Also es war... Natürlich sind die Zeiten dieses Umbruchs immer sehr, sehr schwierig. Aber es war tatsächlich so, dass unsere Organisation und unser Topmanagement gesagt hat, "Wir haben eine klare Vision, wie die neue Organisation aussieht. Wer da mitgehen kann, der ist willkommen. Und wer nicht mitgehen kann, für den ist es schwierig in unserer Organisation." Und das war in einigen Fällen betraf das so Mittel-Management. Leute, die halt einfach in der neuen Hierarchie keine Rolle mehr hatten. Und da gab es natürlich die Angebote, dass sie sich verändern in Richtung Product Owner. Teilweise. Aber wie wir wissen, ist das ja nicht so einfach. Das sind ja komplett unterschiedliche Rollen. Und Manager zu Product Owners zu machen, ist ja nicht unbedingt immer das Rezept zum Erfolg, muss man ja ganz offen sagen. Also, wir hatten da einige Leute, die uns verlassen haben. Das war ein schmerzhafter Prozess. Aber ich würde mal sagen, im Großen und Ganzen ging das relativ friktionsfrei.

00:14:04: Okay, und jetzt hast Du ja eben noch einen weiteren wichtigen Punkt angesprochen. Ich möchte fast sagen, da gab es eine sehr klare Haltung des Vorstands, zu sagen "So ist es." Wie wichtig oder wie hast du das in diesem Gesamtprozess erlebt? Dass... Also erste Schwierigkeit, Glückwunsch dazu. Mache ich so die Erfahrung, wenn du mit Führungsleuten über Organisation sprichst, dann ist es ja schon mal schwer zu vermitteln, dass es auch andere Ideen gibt, die nicht unbedingt auf eine Spezialisierung, Abteilung... Das ist immer der spontane Impuls, den ich wahrnehme. Immer wenn du über Organisation sprichst, zu sagen, eine Abteilung Spezialisierung, also immer mit dem goldenen Kalb der Effizienz im Hinterkopf. Also, da erstmal drüber zu kommen und dann noch dahin zu gehen, zu sagen, okay, und wenn auch dieses neue Terrain, so ein bisschen was Neues, also das ist ja offensichtlich neu, Ihr habt das probiert, aber da auch ohne ja, sag ich jetzt mal frech, ohne diese Kästchen aufzumalen und zu sagen, alter Zustand, neuer Zustand. Genauso ist es jetzt und da müssen wir jetzt nur den Übergang schaffen. Wie stark, also wie wichtig ist es da, einen starken Vorstand zu haben, eine starke Geschäftsführung, die vielleicht auch mal so ein bisschen Mut zur Lücke hat und so viel Vertrauen der Organisation schenkt, dass ihr sagt, das wird sich schon gut gehen. Aber ganz klar, das ist der Weg, den wir gehen, Freunde.

00:15:30: Das ist extrem wichtig, weil in dieser Übergangsphase braucht man einfach eine klare Botschaft und eine klare Vision. Also ich halte das für extrem wichtig. Wenn man das nicht hat, dann ist es sowieso schon verloren. Dann schafft man es sowieso nicht, weil es ist ganz klar, das ist ja, solche Transformationsprozesse sind ja nie linear. Da geht es vorwärts, dann geht es rückwärts und es dauert immer wesentlich länger, als man ursprünglich glaubt. Und da braucht man schon jemand, der an die Sache glaubt und auch ein bisschen längeren Atem hat und versteht, dass Verbesserungen in der Art und Weise, wie wir arbeiten und wie wir uns aufstellen, nichts sind, was sich sofort manifestiert. Du kannst nicht eine große Transformation machen und morgen verdoppelt sich dein Umsatz. So einfach ist die Welt nicht gestrickt. Da braucht man den Blick nach vorne, da braucht man die Unterstützung, da braucht man den längeren Atem. Das sehen wir. Ich meine, wir arbeiten jetzt an diesem Transformationsprozess seit, kann man sagen, wirklich, wirklich stark seit 2018. Und ich glaube nicht, dass jemand jetzt sagen würde, wir sind am Ende angekommen. Niemals. Das heißt, das ist unbedingt notwendig. Die Unterstützung, aber die wohlwollende Unterstützung. Also wie gesagt, es ist ein Transformationsprozess, da müssen alle mitgehen und es hilft auch dann gar nichts, wenn man da wahnsinnigen Druck von oben erzeugt. Das nützt nichts.

00:16:49: Ja, ja, man könnte sicher auch sagen, in so einer Arbeitswelt... Also ist nicht eine Transformation... Muss man davon überhaupt noch reden? Es ist ein natürlicher Bestandteil der Weiterentwicklung, weil die Technologien verändern sich. Wenn ich über eine IT-Organisation rede, dann wird möglicherweise die in zwei Jahren schon wieder komplett anders aussehen.

00:17:09: Das ist... ja, ja... Da hast du sicher vollkommen recht. Aber ich glaube, der Weg, den man geht, ist ja sozusagen von einer relativ starren Organisation zu einer Organisationsform, die die Änderungen permanent und dankbar aufnimmt. Das ist ja das Ziel. Also, es geht ja nicht darum, dass man einen Endzustand einer Transformation erreicht. Der Endzustand ist eine flexible Organisation. Das ist der Endzustand.

00:17:33: Ja. Und dann auch vor allem nicht bei den ersten. Auch das ist ja so ein natürlicher Impuls, wenn es mal ein bisschen hakelig wird, vielleicht nur in Verbindung mit einer gesamtwirtschaftlich eher nicht so berauschenden Lage, dass dann oft dieser Impuls folgt, jetzt geh mal wieder zurück auf Los, weil das ist sicher, das haben wir verstanden. Das ist ja auch so eine, haben wir ja eingangs auch mal über Heuristiken gesprochen. Diese Status Quo Verzerrung, zu meinen, dass der Status Quo die immer die sicherere Variante ist. Auch diesem Impuls muss man ja klar widerstehen und sagen, nee, wir gehen diesen Weg weiter, wir haben da so viel Vertrauen, auch wenn es jetzt gerade ein bisschen hakelig ist, das ziehen wir jetzt durch.

00:18:11: Also es ist ganz wichtig, Der Blick nach vorne ist ganz wichtig und im Endeffekt muss man ja einfach sagen, es ist ja auch alternativlos. Wir können nicht so tun, wie wenn sich die Welt nicht verändert hätte. Das funktioniert einfach nicht.

00:18:24: Jetzt an einem gewissen Punkt und so sind wir ursprünglich ja auch zusammengekommen, seid ihr über die Teamtopologien gestoßen. Also, magst du das mal kurz, was dein Verständnis, dieses Konzept ist, noch mal wiedergeben.

00:18:36: Ja, also im Prinzip ist es ein Muster an Organisationsformen, mit dem man eine Organisation in einer gewissen Art und Weise sehr kontextspezifisch designen kann, die optimiert ist für den kontinuierlichen Fluss von Customer Value, wenn man das so sagen will. Es klingt ein bisschen abstrakt, ja. Im Endeffekt geht es darum, dass die Organisation in der Lage ist, kontinuierlich und schnell zu liefern. Das hat viele Auswirkungen. Die Grundkonzepte dahinter sind sozusagen, dass es eine gute Übereinstimmung zwischen Organisation und Architektur geben muss. Das ist ein ganz zentraler Punkt. Und das zweite ist ein ganz klarer, teamfokussierter Ansatz. Also, das Team ist die zentrale Liefereinheit. Hier muss man schauen, dass man Teams hat, die entlang der Businesslinien aufgestellt sind, die autonom sind, die eigenständig Kundennutzen liefern können. Und rundherum baut man dann die Organisation auf, die sozusagen den Teams ermöglicht, das möglichst gut und möglichst schnell zu tun. Da gibt es noch so Konzepte wie das berühmte Cognitive Load, das irgendwie so ein bisschen aus der Lerntheorie kommt, wo man sagt, die Teams haben einfach nur beschränkte Kapazität und die beschränkte Kapazität sollen sie dort einsetzen, wo sie am meisten Kundennutzen bringt. Das heißt, in anderen Bereichen muss man sie entlasten. Und das ist ein relativ simples Konzept. Hat in der Industrie in den letzten Jahren, finde ich, ziemliche Aufmerksamkeit erregt. Das Interessante ist halt auch, dass immer klar gesagt wird, das ist jetzt nicht so ein Blueprint oder Framework. Das ist es einfach nicht. Es ist eine, wir sagen dazu so ein bisschen eine Mustersprache, eine Pattern Language, ja. Dinge, die immer kontextspezifisch angewendet werden können, aber die ein Modell irgendwie darstellen, wie man mit dieser organisatorischen Komplexität gut umgehen kann. Also, ich finde ein gut abgeschlossenes, kohärentes Modell. So könnte man es bezeichnen.

00:20:38: Ja. Das geht mir auch so, ich finde diese Teamtopologien, die schließen, man könnte fast sagen, eine Lücke. Weil in diesen gängigen Rahmenwerken heißt es dann immer, ich habe Teams, agile Teams, aber die liefern ja möglicherweise gar nicht. Immer arbeiten die immer alle an einem Produkt, weil die organisatorische Realität ist halt nun mal, dass ich vielleicht Spezialisten habe. Zehn auf, keine Ahnung, fünfhundert. Wie bringe ich die und bette ich die jetzt ein? Ich finde, da liefern diese Teamteopologien nochmal einen schönen Ansatz, wie ich überhaupt auch mal weiterdenken kann. Was ist denn überhaupt ein Team und wie interagieren Teams eigentlich miteinander? Das fand ich so für mich in der gesamthaften Darstellung, also wo fügen sich diese Teamtopologien ein, finde ich das am wertvollsten. Und ich gebe das auch immer jedem an die Hand und sag, schau dir das nur mal an, auch nur um mal ein sprachliches Modell oder eine Idee zu haben. Was heißt es denn eigentlich, wenn ich über Teams rede? Und was heißt es denn, wie ich auch Interaktionsmuster zwischen Teams überhaupt gut managen kann oder gut designen kann. Finde ich auch extrem hilfreich. Wie habt ihr konkret damit gearbeitet mit den Team Topologien? Habt ihr das reingegeben in Teams? Haben die dann Workshops gemacht oder auf welcher Ebene hat das bei euch Einfluss gehabt?

00:22:05: Wir haben das jetzt in unserem Operationmodell, das wir designt haben, so beginnend mit 2018, da gab es das ja noch gar nicht. Also wir haben das jetzt nicht unmittelbar berücksichtigt, aber es war so, dass diese Idee von Teams, die entlang von Business Value Streams aufgestellt sind, das war eigentlich immer schon so ein Teil, also da mussten wir jetzt gar nicht so viel nachschärfen. Natürlich ist das nicht immer hundertprozentig durchgezogen, aber grundsätzlich glaube ich, hatten wir das schon ganz gut vorgesehen, wo wir tatsächlich beträchtliche Inspiration aus dem Team Topologies gekriegt haben, war bei zwei spezifischen Dingen. Es gibt ja zwei spezielle Teams, die sozusagen diese Produktteams, die entlang eines Produktstreams arbeiten, unterstützen. Das eine sind Enabling Teams. Das sind so, man kann sich das so vorstellen als technische Coaches, die mit den Teams arbeiten für eine gewisse Zeit und ihnen einfach helfen, besser zu werden. Und wir haben bei uns in der Organisation so ein Team etabliert. Sehr erfolgreich. Wir nennen die Engineering Coaches, die arbeiten mit den Teams für eine gewisse Zeit und helfen ihnen einfach, die technischen Dinge sauber zu kriegen. Aber nicht so, dass wir die Arbeit machen, sondern wir helfen ihnen, zu lernen, so dass sie die Dinge dann selber machen können. Also, richtiges Coaching. Wir sind keine keine Ressourcen, kein Team, das für dich die Arbeit macht. Wir helfen ihnen, wir coachen sie. Das ist das erste. Und das ist ziemlich genauso, wie es eigentlich in den Teamtopologies beschrieben wird.

00:23:37: Und da hat uns das Buch sehr, sehr inspiriert. Und das zweite Thema, das für uns ganz wichtig ist, ist das Thema Plattformen. Ist ja nichts komplett Neues, gibt es ja schon lange in der Industrie, aber die Plattformen, wie sie in Teamtopologies beschrieben sind, haben irgendwie so einen besonderen Twist. Also früher hat man zentralisiert, weil man einfach effizient sein wollte und Kosten sparen wollte. Das war der Haupttreiber. In diesem gedanklichen Modell von Team Topologies ist das nicht der Fall. Sondern es geht darum, dass wir die Last für die Produkt-Teams reduzieren. Und das hat jede Menge an sehr interessanten Konsequenzen. Erstens einmal geht es nicht nur darum, möglichst Geld zu sparen, sondern es geht darum, den Teams zu helfen, möglichst gut zu liefern. Und das bedeutet auch, dass man in diese Plattformen ordentlich investiert, dass man die gut stafft, dass Kosteneffizienz nicht das Allerwichtigste ist, dass man großen Wert darauf legt, dass keine Abhängigkeiten entstehen. Ein ganz wichtiges Thema in dem ganzen Team Topologies Kontext. Das heißt, wenn man eine Plattform macht, dann muss man sicherstellen, dass die Services, die diese Plattform zur Verfügung steht, einfach als Self Service konsumiert werden können. Da darf nichts irgendwie mit Tickets oder sonst irgendwie da sein. Sondern die Teams müssen das einfach selber ohne große Reibung, ohne Reibungsverlust konsumieren können. Also, diese Ideen haben unsere Vorstellung von Plattformen ganz entscheidend geprägt.

00:25:06: Sehr interessant. Was würdest du denn im Rückblick, Du bist ja fünf Jahre, wenn ich das richtig überschlage, jetzt ungefähr dabei? Was würdest du rückblickend genauso wieder machen? An welchen Punkten sagst Du, naja, wenn ich nochmal hier stünde - hätte, hätte, Fahrradkette (lacht) - würde ich das dieses mal vielleicht anders machen.

00:25:28: Ja gut. Ich glaube, das Wichtigste, was man gelernt hat, ist, dass die Dinge immer länger dauern, als man denkt. Also das muss man einfach zur Kenntnis nehmen. Solche Prozesse sind langandauernd und sind schwierig. Man muss alle Leute mitnehmen. Das heißt, es ist unendliche Stunden an Diskussionen, an Erklärungen, an Kontext zur Verfügung stellen, an "Wieso macht man das? Wieso ist das wichtig? Was will man damit erreichen?" Das ist ganz wichtig. Wir haben das wirklich recht intensiv gemacht. Aber ich glaube, da hätten wir uns noch verbessern können. Ich glaube auch, dass vielleicht hätte man - da bin ich aber nicht ganz sicher - vielleicht hätte man eher so ein bisschen kontinuierlicheren Change machen können und nicht so eine Art Big Bang. Wobei, ganz sicher bin ich mir da nicht. Also, irgendwann muss man halt anfangen und irgendwann wird es halt schmerzhaft. Da kann man nicht herumreden drum. Ich glaube, was gut war, ist, dass wir uns relativ gut überlegt haben, wie unser Modell von vornherein ausschauen soll. Wir hatten da eine relativ klare Vorstellung von dem, wie wir unsere Organisation strukturieren. Aber wir hatten immer im Hinterkopf, dass wir uns erlauben, auch Iterationen zu machen. Also gute Vorstellung davon, aber keine starre Architektur im Sinne von "Da ändern wir jetzt nichts mehr." Und wir haben über die Zeit immer wieder Feintuning gemacht, nachgeschärft. Ich glaube, das haben wir ganz gut gemacht. Was wir auch ganz gut gemacht haben, war - und das spreche ich natürlich jetzt eher in meiner Rolle als Engineer -, dass wir klar verstanden haben, dass diese ganzen Transformationsprozesse einfach nur dann funktionieren, wenn man gleichzeitig auch an der technischen Exzellenz arbeitet.

00:27:25: Wie gesagt, wir waren da jetzt ja nicht so schlecht. Ganz gut. Eine leistungsfähige IT-Organisation, auch in der Vergangenheit, aber halt nicht basierend auf den letzten und neuesten Arbeitsmethoden. Und hier haben wir wirklich viel Aufwand und Zeit investiert. Training mit den Teams, Sprechen, auch eben, wie ich schon erwähnt habe, dieses Team von Enabling, Coaches, von Engineering Coaches, die mit den Teams arbeiten. Ich glaube, das hat wirklich sehr gut funktioniert und funktioniert nach wie vor und war auch ganz ein wichtiger Antrieb. Wenn man Teil einer Transformation ist, dann merkt man ja gar nicht, was sich alles verändert, weil es natürlich in kleinen Schritten geht. Aber ich sag halt immer, wenn wir uns die Organisation jetzt anschauen, auch welche Themen wir besprechen jetzt, die Gespräche sind vollkommen andere. Wir sprechen über andere Dinge. Vor zehn Jahren oder vor acht Jahren hat niemand über Continuous Delivery und über Wie schnell können wir liefern und was sind unsere Deployment-Zyklen gesprochen? Das hat man nicht gemacht. Und jetzt reden wir über solche Dinge. Das heißt, die Organisation hat sich komplett verändert, nicht zuletzt auch - und das ist ein ganz wichtiger Punkt - der Stellenwert der IT. Das hat sich total verändert. Früher klar, klassisch, traditionell Costcenter. Wir liefern so billig wie möglich, was das Business haben möchte, zu einem ganz anderen Verständnis und auch Selbstbewusstsein der IT. Wir sind die, die die Innovationen mittragen. Viele Innovationen kommen einfach aus der IT, das ist ja vollkommen klar. Und hier hat sich auch unser Selbstbewusstsein als Organisation komplett verändert, würde ich sagen.

00:29:05: Also, nicht nur... Mein Bild der IT. Ich habe natürlich eine ganz andere Vorstellung davon, aber es war wunderbar. Ich war Dozent an der Uni und - ich erzähl die Geschichte immer - wo saß die IT? Was denkst Du, wo saß die IT?

00:29:25: Naja, irgendwie hinten wahrscheinlich... oder...

00:29:28: Im Keller! (lacht)

00:29:28: Im Keller, ja, genau! (lacht)

00:29:31: Wo ich denke okay, wir reden hier auf der einen Seite über virtuelle Lernräume und wollen den Leuten was über Digitalisierung und agile Arbeitsformen beibringen. Aber wo sitzt hier die IT? Ja, im Keller. Ist leider oft. Deswegen finde ich es interessant, was du sagst. Es ist ja oft die IT als Costcenter, die IT so als der verlängerte Arm des Business. Die, statt zu sagen, "Hey, nee, wir sind eine Software Company mittlerweile, wir sind Mitgestalter dieses Business und wir brauchen eine gute. Ja, wenn jetzt mal eher auf die Business, wenn man dieser klassischen Unterteilung - die macht ja aber gar keinen Sinn mehr - aber, wenn man der mal folgen will, zu sagen, wir haben eine Business- und eine IT Seite. Da geht es ja eben nicht darum, dass die - ich hätte jetzt fast gesagt, Götter in weiß -, aber die - bei einer Bank wahrscheinlich eher die Götter in Grauweiß - Anforderungen von der Businessseite an die IT rübergeben und dann die IT einfach mal sagt, "Ja, danke, vielen Dank. Wir setzen das jetzt um." Wie seid ihr mit dieser oder wie sieht heute eine Verzahnung mit der Businessseite aus? Also sind die in eure Zyklen integriert? Habt ihr einmal im Quartal große Demos, große Produkttage?

00:30:46: Wir haben großflächig versucht, das wirklich eng zu integrieren. Das ist jetzt noch nicht überall der Fall, aber in vielen Teams ist es so, dass die Leute aus dem Business zum Beispiel Product Owner sind. Also, das ist für uns ganz wichtig. Wir wollen, dass die Leute auch beisammen sitzen. Das machen wir bei vielen Teams so, nicht bei allen. Aber grundsätzlich ist natürlich die Idee, dass wir die Trennung zwischen Business und IT so weit wie möglich aufheben. Das ist für mich eine der Grundlagen für Agilität. Anders ist das gar nicht zu erreichen. Da arbeiten wir dran. Aber ganz ein typisches Setting wäre zum Beispiel bei uns, dass das die Product Owner aus dem Business kommen und natürlich die dann kontinuierlich mit den Teams zusammenarbeiten. Das heißt, da hat man schon die Flexibilität und auch die schnellen Feedbackzyklen, ob das, was wir jetzt dann als IT im Team implementieren, auch dem entspricht, was das Business möchte.

00:31:44: Zum Abschluss. Was würdest du jemandem empfehlen, der in der verantwortlichen Rolle in der IT ist, der auch erkannt hat, okay, so geht es hier nicht weiter. Was würdest Du ihm sagen? Was sind die ersten drei Schritte? Was soll er machen? Was soll er vielleicht nicht tun? Wo hat er den größten Hebel?

00:32:01: Na ja, das ist kompliziert und hängt natürlich immer vom Kontext ab. Wie ich vorher gesagt habe, diese einfachen Rezepte gibt es halt leider nicht. Aber was ich über die Jahre gelernt habe und ich bin ja auch schon lange in der Industrie, dass für mich eine der wichtigsten Voraussetzungen, wenn man überhaupt in Richtung Agilität denken möchte, ist, dass man seine technischen Dinge in den Griff kriegt. Das heißt, ein solides Setup, Leute, die sich auskennen, die technischen Möglichkeiten, auch das Tooling, um schnelle Zyklen in der Lieferung mal überhaupt technisch hinzukriegen. Es hat ja keinen Sinn. Man kann ja nicht von Agilität sprechen, wenn ich zwei Wochen brauche, bis ich ein neues Release in Produktion bringe. Das ist ja vollkommen sinnlos. Das heißt, das ist eigentlich ein gewisser Reifegrad auch in dem, wie man arbeitet, eine wichtige Voraussetzung. Sowas kann man natürlich parallel machen und dann muss man halt beginnen, sich über die Organisation Gedanken zu machen. Und das ist ein schwieriges Thema, vor allem bei einer existierenden Applikationslandschaft, weil, wie ich schon vorher gesagt habe, es ist auch eine Idee von Team Topologies. Eigentlich muss die Architektur und die Organisation gemappt werden. Und wenn man große Monolithen hat, dann ist das schwierig. Dann muss man über die Zeit daran gehen, sozusagen diese Monolithen auseinanderzuschneiden in kleinere, unabhängige Teile. Das ist auch ein schwieriger Prozess. Aber es geht nicht anders. Wenn man eine Flexibilität und Geschwindigkeit erreichen will, dann muss man weg von den großen Blöcken zu kleineren autonomen Einheiten, sowohl in der Organisation als auch in der Architektur. Aber wenn du fragst, was ist der erste Schritt, dann würde ich mal schauen, wie schaut es aus mit der mit der technischen Exzellenz im Entwicklungsprozess. Das wäre für mich der der erste Schritt. Und von dort geht es dann weiter.

00:33:50: Wann würdest du an welcher Stelle auch mal auf Top Stakeholder zugehen und sagen, "Ich brauche mal ein bisschen Support?"

00:33:58: (lacht) Na ja, klar.

00:34:00: Vielleicht noch mal ein bisschen Budget.

00:34:03: Wenn es um Tools geht, wenn es um Upskilling geht, dann ist das meistens mit Zeitaufwand und Geld verbunden. Diese Diskussion muss man führen und wenn es dann um Reorganisation geht, dann sowieso. Aber wie gesagt, ich meine, bei sowas ist es immer gut, wenn man zumindest in kleinem Maß schon zeigen kann, dass das, was man an Transformationsaktivitäten entfaltet hat, einen Benefit bringt. Das ist immer das beste Argument. Natürlich, wenn man zeigen kann, okay, wir haben hier was verändert und das funktioniert, das bringt uns tatsächlich was. Auch aus Businesssicht. Das ist das stärkste Argument, das man haben kann, um zu sagen, okay, wir möchten das jetzt einfach in größerem Rahmen diese Veränderungen ausrollen. So fängt man an. Klein anfangen und dann von dort weg.

00:34:46: Also auch sehr Greenfield-lastig. Jungen Wilden mal möglichst den Rücken freihalten, die Autonomie geben, ihnen helfen. Nicht abgecancelt werden.

00:34:56: Das ist eine Möglichkeit. Und das ist, wie die Erfahrung zeigt, oft eine sehr gute. Aber ich schließe nicht aus, dass man auch in Teams, die schon lange zusammenarbeiten und vielleicht traditionell arbeiten, eine Gruppe von Leuten findet, die ernsthaft was verändern möchten. Also, das ist definitiv auch eine Möglichkeit. Da muss man halt die richtigen Leute finden, die sich interessieren, sowas Neues auszuprobieren. Dann geht das auch mit alten Mitarbeitern.

00:35:24: So wie uns. Aber ich würde uns aufgrund der Haltung auch eher zu den jungen Wilden zählen.

00:35:29: Naja, jung. (lacht) Du vielleicht. Ich nicht mehr ganz so?

00:35:29: Ja, doch, doch. Hier oben, da oben ist man jung.

00:35:37: Da ist es am wichtigsten! Keine Frage.

00:35:40: Sehr gut. Ja, dann bedanke ich mich recht herzlich. Vielen, vielen Dank, dass du deine Erfahrungen heute mit uns geteilt hast. Und vielleicht bis zum nächsten Mal.

00:35:49: Ja, ich sage auch Danke. War ein interessantes Gespräch. Hat mich gefreut. Bis bald.

00:35:53: Dankeschön. Bis bald.