小さなチームのためにプロダクトを独立した小さな単位に分割しないほうがよい理由

今日、スケーリングについて二人が同じ勘違いした助言をしているのを聞きました。違うチームが作業するには、プロダクトを独立した部分に分けるのが良いというものです。この助言は決まり文句と言えるほどありふれています。アジャイルのコーチング及びトレーニングのコミュニティに広く見られる盲点がここに現れています。

プロダクトを予め分解すれば、スクラムチームが楽をできるように見えます。しかし全体的に見れば、実際にはプロダクト開発を行う組織のアジリティを減少させてしまうのです。

• ご承知のとおり、アジャイル開発者は_事前の大規模設計（BDUF）_を避けようとします。どのチームがどの部分を担当するかを中心とする組織設計は、_事前の大規模設計（BDUF）_です。将来、優先順位を再考する際の抵抗力を増し、結果として優先順位から外れた仕事を行うチームが出て来ることになります。アジャイルは優先順位の再考を_容易にする_はずではありませんか？大規模組織におけるソフトウェア開発の誤解その２:すべてのチームが等しい価値の業務に取り組んでいるか？もご覧ください。

• 狭い視野でしか見ていないチームでは、重要な問題を、チームの自己組織化ではなく、伝統的なマネジメント手法の領域に据えてしまいます。大規模組織におけるソフトウェア開発の誤解その３：チームの視野は狭くて良いか、プロダクト全体を見るべきか?もご覧ください。

• 顧客が求めるものは統合された製品やソリューションであって、組み合わさらない断片ではありません。大規模組織におけるソフトウェア開発の誤解その４：各チームが作ったパーツは、魔法の力で組み合わさるのか？もご覧ください。

• これは「自分のコード」の外の世界に関するチームの学びを減少させます。私のコード、あなたのコード。アジリティを害するプライベートコードポリシーもご覧ください。

代わりに、私たちは、チームに共有された製品のビジョンおよび優先事項に向かって協働 してほしいと考えています。