「SCRUMMASTER THE BOOK」の感想~スクラムマスターはチームが自己組織化したら御用済みなのか?
「SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ」を読んで、スクラムマスターはチームが自己組織化したら御用済みなのか?という根本問題に気づいた。
論理的でないラフなメモ書き。
スクラムマスターの目標は、チームを自己組織化させること。
スクラムマスターの手腕により、スクラムが上手く回ると、スクラムマスターの出番は少なくなる。
チームは自己組織化されると、スクラムマスターの力を借りずに、チーム自らが問題解決するようになる。
では、スクラムマスターの本来の責務は何なのか?
スクラムマスターはチームの秘書ではない。
スクラムマスターはチームの世話焼きではない。
スクラムマスターが他の役割と兼務した場合、どうなるか?
チームと兼務すると、リーダーシップが欠如となり、チェンジマネジメントの役割が消える。
プロダクトオーナーと兼務すると、相反する役割を1人の人間が持つので、矛盾する言動に陥る。
マネージャと兼務すると、チームへのマイクロマネジメントになる。
複数のスクラムマスターと兼務する場合、作業負荷は高くなるが、経験値は増えるし、システム思考で考えることに秀でるメリットがある。
自己組織化したチームとは何か?
チームの全メンバーがリーダーとなって、リーダーシップを発揮すること。
フォロワーはいない。
各人がリーダー経験があれば、問題を自己解決する能力はある。
リーダーがー求める行動を理解でき、そのように振る舞うこともできる。
スクラムマスターはリーダーである。
チェンジマネジメント、つまり、ステークホルダーとの関係を通じて組織変革の役割を担う。
スクラムマスター・ウェイのレベルは3つ。
レベル1は、私のチーム。
まず、自分のチームを自己組織化させる。
でも、自分のチームが自己組織化したら、スクラムマスターは何をするのか?
仕事がないのでは?
レベル2は、関係性。
つまり、チェンジマネジメント。
ステークホルダーとの関係を良くする。
スクラムチームの3つの関係が良くなる。
レベル3は、スクラムの価値観を企業レベルに持ち込む。
スクラムマスターのグループが集団となる。
スクラムマスター自身がそういう技術を持っているのだから、それ自身が自己組織化したチームとなる。
スクラムマスターの道具箱。
ファシリテーションとして、レトロスペクティブの技法。
コーチング。
根本原因分析として、特性要因図、なぜなぜ分析。
ここは古い技法を割と使っている。
製品開発の手法インパクトマッピングを使って、スクラムの導入・実践に適用する。
なぜ?=ゴール
誰が?=アクター
どうやって?=アクターの効果を変える
何を? =解決策
大規模スクラムは、LeSS一択。
窮屈な方法、官僚主義的な方法でスクラムを改修する必要はない。
スクラムはシンプルで経験主義なのに、なぜ官僚化したプロセスがいるのか?
LeSSの特徴。
製品の大きさに無関係にスケールできる。
製品の大きさに関係なく、プロダクトオーナー1人、プロダクトバックログは1つ。
計画フェーズは故意に2つ入れる。
プロダクトオーナーとチーム代表による計画、各チームのスプリント計画。
レトロスペクティブも2つ入れる。
OverAll Retrospectiveはチーム代表、スクラムマスター、プロダクトオーナー。
普通のレトロスペクティブは、各チーム。
再び、問う。
スクラムマスターはチームが自己組織化したら御用済みなのか?
スクラムマスターは、自分のチーム、外部のステークホルダーを通じて、組織文化を変革する役割を担う。
| 固定リンク
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント