Ich habe das Buch von Matthew Skelton und Manuel Pais gelesen. Deine Zusammenfassung und Lisas Sketch-Notes sind für mich sehr gute "Refresher" für das Thema. Frage: Sind die "Complicated Subsystem Teams" nur für kurze Dauer - so wie von Michael Plöd auf der OOP 2024 erwähnt -, angelegt, oder können sie Deiner Meinung nach auch auf Dauer angelegt sein und sogar eine Core Domain in der Organisation abdecken?
Danke für das nette Feedback! Ein Complicated Subsystem Team soll ein bestimmtes System handhaben, das Buch nennt beispielsweise einen Videocodec oder ein mathematisches Modell. Dadurch soll es Stream-aligned Teams entlasten. Das System wird vermutlich bestehen bleiben. Dann müsste man aber die Zuständigkeit anders verteilen, wenn das Team zeitlich begrenzt ist. Dann müssen aber vermutlich Stream-aligned Teams sich damit herumschlagen und das ist bezüglich cognitive Load nachteilig. Von daher verstehe ich nicht, warum sich ein Complicated Subsystem generell zeitlich beschränkt sein sollte. Ich habe im Buch in der Beschreibung des Teams dazu auch keinen anderen Hinweis gefunden.
Ein Complicated Subsystem Team deckt in erster Linie Bereiche ab, die ein besonderes Spezialwissen erfordern welches unter Umständen schwer am Markt zu "recruiten" ist. Mein Beispiel auf der OOP bezog sich auf eine Möglichkeit unter vielen: dass das Team perspektivisch (und ich meine das eher langfristig) eine Platform samt Enabling etablieren könnte und sich in diesem Zuge wandelt. Mir ist wichtig zu betonen, dass das ein Szenario ist. Genausogut ist es denkbar, dass das Complicated Subsystem Team einfach langfristig bestehen bleibt. Im Hinblick auf die Core Domain würde ich hier eher Fragen aufwerfen: das ist denkbar aber in den meisten Fällen würde man für den Core-Bereich auf schnell liefernde Stream-aligned Teams setzen.
Danke für die Vorstellung. In unsere Organisation wird momentan SAFe eingeführt, was ja viel von Team Topologies übernommen hat. Was mir oft zu kurz kommt bei der Vorstellung von Team Topologies ist, dass weder im Buch noch z.B. in diesem Video gut begründet werden kann warum etwas so umgesetzt werden muss. Mir fehlt einfach die Substanz, stattdessen wird es einfach in den Raum geworfen und der Leser/Zuhörer soll das so hinnehmen. Ich habe leider die Erfahrung machen müssen, dass es zur Isolierung geführt hat. Unsere Teams sind sehr klein, und nach Team Topologies soll Kollaboration und Interaktion zwischen den Teams minimiert werden, weil teuer. Unsere Kommunikation geht daher nur noch über Jira Boards. Es ist eine organisatorisch angeordnete Isolation.
Danke für das Feedback, das weißt auf einige interessante Punkte hin, die man nochmal diskutieren könnte: - IMHO muss Team Topologies nicht so umgesetzt werden. Im Gegenteil: Team Topologies beschreibt die Modelle als Magnet, auf die man sich zubewegen sollte. Außerdem schreibt das Buch gleich am Anfang, dass es neben dem Organigramm auch informelle Kommunikationskanäle gibt, d.h. die Teamaufstellung alleine ist nur ein Teil der tatsächlichen Herausforderung. Ich halte es für einen Fehler, irgendwie solche Modelle auf eine Organisation anzuwenden und dann zu erwarten, dass es funktioniert, ohne auf die spezifischen Herausforderungen einzugehen.. Es sind halt Menschen, über die wir da sprechen. - Ich halte es für falsch, Kommunikation einzuschränken. Wenn die Aufteilung der Aufgaben und Teams gut funktioniert, dann gibt es weniger Bedarf nach Kommunikation. Wenn es Bedarf nach Kommunikation gibt, würde ich auf keinen Fall die Kommunikation unterbinden. Ebenso würde ich nicht direkte Kommunikation durch schriftliche zwangsweise ersetzen. Die direkte Kommunikation hat eine deutlich höhere Bandbreite. Ich sehe bei Team Topologies durch so etwas wie eine Collaboration sogar Ansätze, die nur in Situationen mit hohem Kommunikationsbedarf eingesetzt werden sollen. Dann soll sich aber die Situation so ändern, dass irgendwann weniger Kommunikation notwendig ist. Ich halte das Geühl einer "organisatorisch angeordneten Isolation" für ein krasses Alarm-Signal. - SAFe und Team Topologies sind zwei unterschiedliche Dinge. Ich wäre überrascht, wenn die Autoren von Team Topologies SAFe für eine gute Idee halten würden, aber ich habe sie nicht gefragt. In dem Kontext wäre vielleicht auch die Episode zum Spotify-Modell interessant. Dort argumentiere ich, dass die Gilden etc. des Spotify-Modells nicht der Kern sind und es um etwas ganz anderes geht: software-architektur.tv/2021/09/03/folge73.html
Ich habe Matthew (einen der Autoren des Team-Topologies-Buchs) zu SAFe und Team Topologies gefragt. Meine Frage: SAFe seems to suggest that Team Topologies is a good fit for SAFe, see v5.scaledagileframework.com/organizing-agile-teams-and-arts-team-topologies-at-scale/ - is there any statement with your point of view concerning SAFe and Team Topologies? Antwort: TT is definitely not "part of" SAFe and we (TT) were not consulted by SAFe about them using TT patterns in SAFe. However, we're doing some collaboration around this with SAFe practitioners to try to nudge behaviour and awareness. mastodon.social/@matthewskelton/112310458438235110
Danke für die Nachfrage! Mit hat das geholfen, die Abgrenzung zu SAFe noch klarer zu bekommen und zu verstehen, welche Fehler beim Einführen für Team Topologies geschehen können. 🙇
@@EberhardWolff Sehr gerne, ich bin selber noch dabei mich durch die Themen durchzuarbeiten. Wie das heißt ist mir letztlich egal, ich möchte vor allem eine gute und gesunde Arbeitskultur ☺️
th-cam.com/video/sGEwmm-59ps/w-d-xo.htmlfeature=shared Michael Plöd schneidet hier ebenfalls an, dass man mit kontext diagramme die teams und komponentem der architektur in liefer und leistungsbeziehung untereinander beschreiben kann.
![ละลาย (LALALYE) - DAOU PITTAYA ต้าห์อู๋ พิทยา [OFFICIAL MV]](http://i.ytimg.com/vi/wo6r9TgausI/mqdefault.jpg)
Ich habe das Buch von Matthew Skelton und Manuel Pais gelesen. Deine Zusammenfassung und Lisas Sketch-Notes sind für mich sehr gute "Refresher" für das Thema. Frage: Sind die "Complicated Subsystem Teams" nur für kurze Dauer - so wie von Michael Plöd auf der OOP 2024 erwähnt -, angelegt, oder können sie Deiner Meinung nach auch auf Dauer angelegt sein und sogar eine Core Domain in der Organisation abdecken?
Danke für das nette Feedback!
Ein Complicated Subsystem Team soll ein bestimmtes System handhaben, das Buch nennt beispielsweise einen Videocodec oder ein mathematisches Modell. Dadurch soll es Stream-aligned Teams entlasten. Das System wird vermutlich bestehen bleiben. Dann müsste man aber die Zuständigkeit anders verteilen, wenn das Team zeitlich begrenzt ist. Dann müssen aber vermutlich Stream-aligned Teams sich damit herumschlagen und das ist bezüglich cognitive Load nachteilig. Von daher verstehe ich nicht, warum sich ein Complicated Subsystem generell zeitlich beschränkt sein sollte. Ich habe im Buch in der Beschreibung des Teams dazu auch keinen anderen Hinweis gefunden.
Ein Complicated Subsystem Team deckt in erster Linie Bereiche ab, die ein besonderes Spezialwissen erfordern welches unter Umständen schwer am Markt zu "recruiten" ist. Mein Beispiel auf der OOP bezog sich auf eine Möglichkeit unter vielen: dass das Team perspektivisch (und ich meine das eher langfristig) eine Platform samt Enabling etablieren könnte und sich in diesem Zuge wandelt. Mir ist wichtig zu betonen, dass das ein Szenario ist. Genausogut ist es denkbar, dass das Complicated Subsystem Team einfach langfristig bestehen bleibt.
Im Hinblick auf die Core Domain würde ich hier eher Fragen aufwerfen: das ist denkbar aber in den meisten Fällen würde man für den Core-Bereich auf schnell liefernde Stream-aligned Teams setzen.
Danke für die Vorstellung. In unsere Organisation wird momentan SAFe eingeführt, was ja viel von Team Topologies übernommen hat. Was mir oft zu kurz kommt bei der Vorstellung von Team Topologies ist, dass weder im Buch noch z.B. in diesem Video gut begründet werden kann warum etwas so umgesetzt werden muss. Mir fehlt einfach die Substanz, stattdessen wird es einfach in den Raum geworfen und der Leser/Zuhörer soll das so hinnehmen.
Ich habe leider die Erfahrung machen müssen, dass es zur Isolierung geführt hat. Unsere Teams sind sehr klein, und nach Team Topologies soll Kollaboration und Interaktion zwischen den Teams minimiert werden, weil teuer. Unsere Kommunikation geht daher nur noch über Jira Boards. Es ist eine organisatorisch angeordnete Isolation.
Danke für das Feedback, das weißt auf einige interessante Punkte hin, die man nochmal diskutieren könnte:
- IMHO muss Team Topologies nicht so umgesetzt werden. Im Gegenteil: Team Topologies beschreibt die Modelle als Magnet, auf die man sich zubewegen sollte. Außerdem schreibt das Buch gleich am Anfang, dass es neben dem Organigramm auch informelle Kommunikationskanäle gibt, d.h. die Teamaufstellung alleine ist nur ein Teil der tatsächlichen Herausforderung. Ich halte es für einen Fehler, irgendwie solche Modelle auf eine Organisation anzuwenden und dann zu erwarten, dass es funktioniert, ohne auf die spezifischen Herausforderungen einzugehen.. Es sind halt Menschen, über die wir da sprechen.
- Ich halte es für falsch, Kommunikation einzuschränken. Wenn die Aufteilung der Aufgaben und Teams gut funktioniert, dann gibt es weniger Bedarf nach Kommunikation. Wenn es Bedarf nach Kommunikation gibt, würde ich auf keinen Fall die Kommunikation unterbinden. Ebenso würde ich nicht direkte Kommunikation durch schriftliche zwangsweise ersetzen. Die direkte Kommunikation hat eine deutlich höhere Bandbreite. Ich sehe bei Team Topologies durch so etwas wie eine Collaboration sogar Ansätze, die nur in Situationen mit hohem Kommunikationsbedarf eingesetzt werden sollen. Dann soll sich aber die Situation so ändern, dass irgendwann weniger Kommunikation notwendig ist. Ich halte das Geühl einer "organisatorisch angeordneten Isolation" für ein krasses Alarm-Signal.
- SAFe und Team Topologies sind zwei unterschiedliche Dinge. Ich wäre überrascht, wenn die Autoren von Team Topologies SAFe für eine gute Idee halten würden, aber ich habe sie nicht gefragt.
In dem Kontext wäre vielleicht auch die Episode zum Spotify-Modell interessant. Dort argumentiere ich, dass die Gilden etc. des Spotify-Modells nicht der Kern sind und es um etwas ganz anderes geht: software-architektur.tv/2021/09/03/folge73.html
Ich habe Matthew (einen der Autoren des Team-Topologies-Buchs) zu SAFe und Team Topologies gefragt.
Meine Frage:
SAFe seems to suggest that Team Topologies is a good fit for SAFe, see v5.scaledagileframework.com/organizing-agile-teams-and-arts-team-topologies-at-scale/ - is there any statement with your point of view concerning SAFe and Team Topologies?
Antwort:
TT is definitely not "part of" SAFe and we (TT) were not consulted by SAFe about them using TT patterns in SAFe. However, we're doing some collaboration around this with SAFe practitioners to try to nudge behaviour and awareness.
mastodon.social/@matthewskelton/112310458438235110
Danke für die Nachfrage! Mit hat das geholfen, die Abgrenzung zu SAFe noch klarer zu bekommen und zu verstehen, welche Fehler beim Einführen für Team Topologies geschehen können. 🙇
@@EberhardWolff Sehr gerne, ich bin selber noch dabei mich durch die Themen durchzuarbeiten. Wie das heißt ist mir letztlich egal, ich möchte vor allem eine gute und gesunde Arbeitskultur ☺️
@@franziskah3759Ja, das finde ich auch sehr wichtig! 👍
th-cam.com/video/sGEwmm-59ps/w-d-xo.htmlfeature=shared
Michael Plöd schneidet hier ebenfalls an, dass man mit kontext diagramme die teams und komponentem der architektur in liefer und leistungsbeziehung untereinander beschreiben kann.
Ja. Ich denke, man sollte Diagramme zeichnen mit den Informationen, die einem helfen - ob die dann einem Standard entsprechen ist IMHO sekundär.