書評)大規模スクラム

感想

スクラムの本にマネージャーが役割として登場することはないけど、LeSSにおけるマネージャーの役割は組織がプロダクトを開発するにあたっての価値提供能力を向上させるための改善だと明確に言及があるのが良かったです。
マネージャーは組織が改善していることを保証することに注力する、チームが改善するにあたってチームだけではできないことを支援する、例えば規制やポリシーの変更など。Doneの定義をどうやったら拡張できて、チームが自己管理の元にデリバリー能力を向上させることができるかを考える役割だ、などなど。
また人気のマネジメントの本を読むだけで満足せず、現地現物に触れ続け、学習を継続し、今の現実の問題を見つけてそれを組織力の向上に活かすこと、という示唆はちょっとドキッとしました。
 
全体としてはLeSS(Huge)におけるスクラムマスター、プロダクトオーナー、プロダクトバックログなど項目ごとに解説されていて、わからないところを読み返すことができるような感じで実際導入する場合の手引きになるような内容でした。
 

ポイントサマリ

 
顧客価値による組織化
  • コンポーネントチームからフィーチャーチームへの移行を目指すf:id:takacyk:20210815151821j:plain
  • 機能別組織はない
    • f:id:takacyk:20210816161958p:plain

    • チームとPOは対等
    • Undone部門
      • 出荷可能とDoneの定義の差分を埋めるちーむ。無い方が好ましい
  • LeSS Huge
    • フィーチャーチームを要求エリアでグルーピング
    • f:id:takacyk:20210816162016p:plain

    • 各要求エリアの優先順位に基づきチームの移動が発生する
    • 優先順位が下がって小さくなった要求エリアは統合する
      • 小さな要求エリアが増えることで優先順位付けが複雑化したり、サイロ化したりする
 
 
LeSSでなマネジメント
  • マネージャーの役割は日々の作業の管理からプロダクト開発の仕組みの改善促進に変わる
  • 組織の問題はフィーチャーチームを当事者として向き合わせる
  • 組織が改善していることを保証することに注力する
  • チームが改善しようとしていることに対し、チームだけでは手の届かない規制や組織のポリシーの変更などを支援する
  • 現地現物
    • チームとユーザーの現場に習慣的に訪問し、実際の問題を理解して、それを組織力の向上に活かす
    • 現地で介入するとマイクロマネジメントになってしまう
    • チームが解決できない場合には方法を教えて促進しチームの問題解決能力を向上する
    • 現場から得たフィードバックをもとに優れた組織の意思決定をする
    • マネージャーは人気のマネジメントの本を読むだけではなく、最新のドメインと技術に触れ続け、今日の現実に触れ続ける
 
LeSSのスクラムマスター
  • LeSSがうまく機能していることに責任を持つ
  • システム思考とプロダクト全体思考を組織が持てるように支援する
  • 対象領域はチーム、PO、組織、開発のプラクティスでスクラムマスター専任
 
LeSSのプロダクト
  • チームが扱うプロダクトの定義を狭く細かく区切ると、サイロ化し、機能の重複が起き、互いに依存関係が生まれ、顧客の課題を解決する提案が狭い範囲でしか考えられなくなる
  • プロダクトの定義はプロダクトのビジョン、対象とする顧客や市場、ドメインの共通性によって広げるか狭めるかを考える
  • 理想はE2Eで顧客に価値を届ける範囲でプロダクトを定義することだが、現実的には組織の制約などで制限される。まずはそこから始めて将来底には理想を目指す