ゾンビスクラムサバイバルガイド: 健全なスクラムへの道

第1部

リベレイティングストラクチャー https://www.liberatingstructures.com/ls-menu

第3章ゾンビスクラム入門

ゾンビスクラムが陥りがちな症例の紹介。ゾンビスクラム自体は造語。

ゾンビスクラムの症状

症状1 ゾンビスクラムチームはステークホルダーのニーズを知らない
症状2 ゾンビスクラムチームは速く出荷しない
症状3 ゾンビスクラムチームは（継続的に）改善しない
症状4 ゾンビスクラムチームは障害を克服するための自己組織化をしない

第4章スクラムの目的

ゾンビスクラムからの回復の鍵として、そもそもスクラムの目的のおさらい。

https://zombiescrum.org/scrumframework

p.36 経験主義とプロセス制御理論 複雑な物事に対しては取りうる全ての変数を包括した推論をするより計測して対応した方が良い。経験的プロセス制御は工業プラントの複雑な化学プロセスを制御するために開発されたが、他のドメインの複雑な問題にも同じ用に適用できスクラムフレームワークはその一例である。

p.37 経験主義とスクラムフレームワーク スクラムフレームワークは経験的プロセス制御を可能にする3つの柱に支えられている。

透明性：何が起こっているかを調べるために、指標、フィードバック、その他経験などのデータを収集する
検査：関係者全員で進捗を検査し、それが大きな目標にとって何を意味するか判断する
適応：大きな目標に近づくように調整する

透明性を作り、成果を検査し、必要があれば適応する短いサイクルを繰り返す。起こらないかもしれない未来について、リスクの高い仮定にもとづいた意思決定を行うのではなく、これまでに検出したシグナルに基づいて行う。これが経験主義である。

第2部ステークホルダーが求めるものを作る

第5章症状と原因

なぜ、わざわざステークホルダーを巻き込む必要があるのか？

組織は、価値あるものを世に出して初めて存続することができる。

実際のところ、ステークホルダーは誰？

価値に関する仮説の検証プロダクト開発は複雑な仕事でその本質はステークホルダーのニーズとそれを満たす一番よい方法について、あるいは何に価値があるかについてチームがたくさん仮説を立てることである。しかし、仮説はあくまでも仮説で間違っているリスクも伴う。開発の最後の最後に仮説を検証すると、間違いに気づいたときにたくさんの時間とお金を浪費してしまう。このようなリスクを軽減するために、速くそして頻繁に仮説を検証するほうが良い。

なぜ、私たちはステークホルダーを巻き込んでいないのか？

プロダクトの目的をあまり理解していない
ステークホルダーが必要とするものを決めてかかっている
開発者とステークホルダーとの間に距離をとっている
ビジネスとITは別物と考えている
プロダクトオーナーが実際にプロダクトのオーナーになることを許されていない
価値よりもアウトプットを測る
開発者はコードだけ書いていればよい
関与しなくてもよいと思っているステークホルダーがいる

健全なスクラム

誰がステークホルダーのことを理解するべきかスクラムチーム全員が、ステークホルダーのことをよく理解する必要がある。
ステークホルダーをいつ巻き込むか

第6章実験

実験：ステークホルダーを知る

ステークホルダートレジャーハントを始める
ステークホルダーとの距離を測って透明性を作り出す
ステークホルダーの席をスクラムチームの近くに用意する
プロダクトの目的に合わせてチームの部屋を飾りつける

実験；プロダクト開発にステークホルダーを巻き込む

フィードバックパーティーにステークホルダーを招待する
ユーザーサファリに行く
ゲリラテスト

価値あるものに集中し続ける

プロダクトバックログの長さを制限する
プロダクトバックログをエコサイクルにマップする
やるべき作業ではなく、望ましい成果を表現する

第3部速く出荷する

第7章症状と原因

速く出荷することの恩恵

あなたの環境の複雑さ
プロダクトの複雑さ

要するに、速く出荷しないのはゾンビスクラムのサイン

なぜ、私たちは十分な速さで出荷しないのか？
早い出荷がリスクを減らすことを理解していない
計画駆動型の管理が妨げになっている
速く出荷することの競争優位性を理解していない
早い出荷の阻害要因を取り除かない
スプリントで扱うアイテムが非常に大きい

健全なスクラム

リリースするかしないかを決断する
リリースはもはやゼロイチではない
スプリント中に出荷するスクラムフレームワークは少なくともスプリントの終わりにはリリースできるようにすることをチームに推奨しているが、スプリントの終わりまでリリースを待つ必要はない。
「ビックバン」リリースはもうしない

第8章実験

透明性と危機感を生み出す実験

継続的デリバリーに投資するための説得材料を集める
リードタイムとサイクルタイムを測るリードタイムは、ステークホルダーの要求がプロダクトバックログに入ってから、リリースされてステークホルダーに提供されるまでの時間。サイクルタイムは、アイテムの作業が開始されてからアイテムが出荷されるまでの時間。
ステークホルダーの満足度を測る

もっと頻繁に出荷するための実験

インテグレーションとデプロイ自動化への第一歩を踏み出す
完成の定義を強化する
スプリントごとに出荷する
ゴールを達成するためのパワフルクエスチョンを使う

フローを最適化するための実験

スキルマトリックスでクロスファンクショナルを強化する
仕掛中の作業を制限する
プロダクトバックログアイテムをスライスする

第4部継続的に改善する

第9章症状と原因

なぜ、わざわざ継続的に改善する必要があるのか

継続的改善とは何か？スクラムフレームワークは、本質的に2種類のエラーを検出するためのメカニズムである。1つ目のエラーは、バグからニーズに対する誤った仮定まで、スクラムチームが開発中のプロダクトに発見したエラーのことである。2つ目のエラーは、1つ目のエラーを早期に検出するために必要だったであろうことと、実際に行われたこととのギャップのことである。1つ目のエラーに対するシングルループ学習、2つ目のエラーに対するダブルループ学習の2つの方法でチームは学習できる。
継続的改善かアジャイルトランスフォーメーションか？

なぜ、継続的に改善しないのか

ゾンビスクラムでは、失敗に価値を置かない
ゾンビスクラムでは、具体的な改善をしていない
ゾンビスクラムでは、失敗するための安全性を作らない
ゾンビスクラムでは、成功を祝わない
ゾンビスクラムでは、仕事における人間的要素を理解していない
ゾンビスクラムでは、仕事のやり方を批評しない
ゾンビスクラムでは、仕事と学習は別と考える

健全なスクラム

自己批判的なチーム
木を見て、森も見る

第10章実験

深い学習を促すための実験

阻害要因ニュースレターを組織内で共有する
スプリントレトロスペクティブでパワフルクエスチョンを使う
問題点と解決策を一緒に深く掘り下げる

改善を具体化するための実験

15%ソリューションを生み出す
何をやめるかに焦点を当てる
改善レシピを作成する

新しい情報を集めるための実験

公式・非公式のネットワークを利用して変革を促す
ローテクな指標ダッシュボードを作成し成果を追跡する

学習環境を整える実験

成功体験を共有し、それをもとに事を進める
お祝いケースを焼く

第5部自己組織化する

第11章症状と原因

なぜ、わざわざ自己組織化する必要があるのか？

自己組織化とは何か？
シンプルなルールによる自己組織化
自己管理による自己組織化
自己組織化は複雑な世界におけるサバイバルスキル
要するに

なぜ、私たちは自己組織化しないのか？

ゾンビスクラムでは、自己管理が十分にできていない
ゾンビスクラムでは、市販の解決策を使う
ゾンビスクラムでは、スクラムマスターがすべての阻害要因を解決していく
ゾンビスクラムでは、スクラムマスターはスクラムチームだけに集中する
ゾンビスクラムでは、ゴールがないか、押し付けられている
ゾンビスクラムでは、作業環境を外部記憶として使わないチームが作業環境を外部記憶として使うと、自己組織化は次第に用意になっていく。スティグマジーは、あるエージェント（ヒト、アリ、ロボットなど）が次に何をすべきかを明確にする痕跡を環境に残し、続いてやってきた別のエージェントが直接コミュニケーションや制御することなしにそれを実行する場合に起こる。人間の組織では、ウィキペディアやオープンソースプロジェクトがスティグマジーの例だ。複雑な作業の調整に、直接的なコミュニケーションは必要ない。環境に残された痕跡の質とアクセスのしやすさが、その後の行動の質と自己組織化の程度を決めるのだ。
ゾンビスクラムでは、標準化が妨げになっている

健全なスクラム：自己組織化とはどのようなものか

スクラムチームはプロダクトに対する自律性を持つプロダクトオーナーはプロダクトの「何を（What）」、開発チームは「そのように（How）」に対する決定の自律性を持っている。府度ダクトオーナーには、プロダクトビジョンや立てた戦略にもとづき、プロダクトバックログの中身と順序に対する最終的な決定権がある。開発チームには、1回のスプリントの範囲内で、作業のやり方と作業量に対する最終的な決定権がある。
管理職がスクラムチームを支援するスクラムマスターだけでなく管理職は、自己管理とその結果としての自己組織化を支援する極めて重要な役割を果たす。戦略的ゴールを設定することに注力し、スクラムチームがそのゴールからプロダクト固有のゴールを導き出せるようにする。

第12章実験

自律性を高める実験

パーミッショントークンで自律性の低さによるコストを可視化する
統合も自律も高める行動を見つけ出す
ルールを壊す！

自己組織化を促進する実験

自己組織化のための最小限のルールを見つける
助けてほしい気持ちをはっきりと言葉にする
何が起きているか観察する

自己アライメントを促す実験

パワフルクエスチョンでもっとよいスプリントゴールを作る
物理的なスクラムボードを使う

現場での解決策を見つける

阻害要因を話し合うスクラムマスターの集いを開催する
オープンスペーステクノロジーで現場での解決策を作る

ゾンビスクラムというキャッチーな造語を用いてスクラムの現場におけるうまくいかない状況からの解決策を提供してくれます。単なるレシピ本のようにみえますが、なぜスクラムをやるのかだったり項目項目でwhyを掘り下げていて、スクラム自体の理解も深まりました。また、オンラインで無料でゾンビスクラム診断（https://scrumteamsurvey.org/）を受けることができます。

ゾンビスクラム診断（https://scrumteamsurvey.org/）

2022/11/16@engage

https://results.scrumteamsurvey.org/participant/d855f14d-f572-48b7-952a-7741147cb485/report

2023/03/27@engage

https://results.theliberatorsimproveyourteam.com/participant/34acae78-b401-4b42-9266-720e8987fbca/report

前回からの差分の考察

サマリー

チームとしてのスコアは前回でも低かったがさらに下がっている（36->25）。これはTeam EffectivenessとManagement Supportの項目が大きく前回から減少しているため。チームや会社として特段なにか悪化したということはなく（良くもなっていないが）、自分の解像度が上がりより問題として認識していることにより厳しいスコアををつけたことが原因。スクラムチームとしては、前回から良くなっているとは思っているが、計測項目的にはよくなったところより悪くつけてしまった部分の影響が大きかった。

前回からの向上した箇所

Continuous Improvement リリース後に手動で打鍵したりリリース通知などで手動の作業は残っているが、リリースフローがだいたい自動化されるようになった。
Sprint Retrospective Quality 以前は1時間でTryまで議論する時間がなかったが、レトロスペクティブの時間を30分長く取ることにより議論ができるようになった。
Learning Environment 2週間スプリントの途中に半日ほど学習時間として自由に使って良い時間を設けるようになった。会社として推奨という感じではなく、半ば強引に勝ち取った感じなので状況に応じては消滅してしまう恐れもある。また他のMTGなどが入れば使える時間が減ってしまう。

前回から悪化した箇所 明確に悪くなったところはない。会社やチームについての理解が深まり厳しくスコアをつけるようになったので大幅にスコアが下がっている項目がある。ただTeam ConflictやTeam Moraleについてはまた別かもしれない。これは少しモチベーションなども減っているかもしれない。

hayashi-ay / booklist