感想
スクラムの本にマネージャーが役割として登場することはないけど、LeSSにおけるマネージャーの役割は組織がプロダクトを開発するにあたっての価値提供能力を向上させるための改善だと明確に言及があるのが良かったです。
マネージャーは組織が改善していることを保証することに注力する、チームが改善するにあたってチームだけではできないことを支援する、例えば規制やポリシーの変更など。Doneの定義をどうやったら拡張できて、チームが自己管理の元にデリバリー能力を向上させることができるかを考える役割だ、などなど。
また人気のマネジメントの本を読むだけで満足せず、現地現物に触れ続け、学習を継続し、今の現実の問題を見つけてそれを組織力の向上に活かすこと、という示唆はちょっとドキッとしました。
全体としてはLeSS(Huge)におけるスクラムマスター、プロダクトオーナー、プロダクトバックログなど項目ごとに解説されていて、わからないところを読み返すことができるような感じで実際導入する場合の手引きになるような内容でした。
ポイントサマリ
顧客価値による組織化
- コンポーネントチームからフィーチャーチームへの移行を目指す
- コンポーネントチーム
- フィーチャーチーム
- 機能別組織はない
- チームとPOは対等
- Undone部門
- 出荷可能とDoneの定義の差分を埋めるちーむ。無い方が好ましい
- LeSS Huge
- フィーチャーチームを要求エリアでグルーピング
- 各要求エリアの優先順位に基づきチームの移動が発生する
- 優先順位が下がって小さくなった要求エリアは統合する
- 小さな要求エリアが増えることで優先順位付けが複雑化したり、サイロ化したりする
LeSSでなマネジメント
- マネージャーの役割は日々の作業の管理からプロダクト開発の仕組みの改善促進に変わる
- 組織の問題はフィーチャーチームを当事者として向き合わせる
- 組織が改善していることを保証することに注力する
- チームが改善しようとしていることに対し、チームだけでは手の届かない規制や組織のポリシーの変更などを支援する
- 現地現物
LeSSのスクラムマスター
LeSSのプロダクト
- チームが扱うプロダクトの定義を狭く細かく区切ると、サイロ化し、機能の重複が起き、互いに依存関係が生まれ、顧客の課題を解決する提案が狭い範囲でしか考えられなくなる
- プロダクトの定義はプロダクトのビジョン、対象とする顧客や市場、ドメインの共通性によって広げるか狭めるかを考える
- 理想はE2Eで顧客に価値を届ける範囲でプロダクトを定義することだが、現実的には組織の制約などで制限される。まずはそこから始めて将来底には理想を目指す