チームトポロジーにおける4チームのインタラクションをUMLで整理してみた

「チームトポロジー」を理解するために、4チームのインタラクションをastahで整理してみた。

【参考】
チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する: プログラマの思索

チームトポロジーから組織の現時点を知る #チーム開発 - Qiita

SalesNowの開発組織を支えるチームトポロジー

30分で分かった気になるチームトポロジー

【1】チームタイプｘチームインタラクションモードをアクティビティ図を流用して表形式で整理してみた。
典型的なインタラクションのみ記載してみた。

やはり基本は、他チームにAPIを公開して利用してもらうIFだろう。
CollaborationやFacilitationでいつもチーム間でコミュニケーションを取るのはコストがかかりすぎると思う。
チーム間のIFが軽いケースが増えれば、結局、自身のチームで作成したAPIを社内の他チームに使ってもらうケースになるだろうと思う。

【2】チームトポロジーにおける4チームのインタラクションをクラス図で書いてみた。
典型的なインタラクションのみ記載してみた。

中心には、サービスを開発するStream-aligned teamがある。
Platform team、Complicated Subsystem teamがStream-aligned teamにリソース（API）を提供する。
Enabling teamがStream-aligned teamをコーチングしたり支援したりする。

もちろん、Stream-aligned team同士でCollaborationしたり、APIを提供する場合もある。

そういうチーム間の構造を見ると、チームの種類数はこれだけしかないのか、という疑問も湧いてくる。
おそらく、「チームトポロジー」の著者が色んな会社で大規模アジャイル開発を見てきて、これらのチームタイプに収斂されたのではないかと想像する。

【3】こういう内容を理解してくると、チームトポロジーを実際に使いこなして、試してみたくなる。

しかし、チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する: プログラマの思索でも書いたが、社内にあるたくさんのアジャイル開発チームを組織編成できる人たちのレベルは、CTOや事業部長クラスの人たちであり、普通のスクラムマスターのレベルの人達では難しいのではないだろうか。
一人の開発者をチーム間でやり取りするだけでなく、アジャイルチームそのものを切り出したり、吸収したり、統廃合する権限が必要になってくるからだ。

事例をあまり良く知らないので他にも探したり聞いてみたいと思う。

チームトポロジー [ マシュー・スケルトン ] 楽天で購入