スクラムのように見えるがスクラムではない、機能していないスクラムを「ゾンビスクラム」と名付け、なぜそれが発生するか、いかにそこから回復すべきかを説いた一冊。
ゾンビスクラムという、上手くいっていない状態を題材にすることで、本来はどうあるべきなのか、どのような状態を目指すべきなのかが、自然と理解できるようになっている。
スクラムガイドの内容がシンプルすぎることが、スクラムフレームワークの実践の難しさの一つになっていると思っている。
PBI には何を書けばいいのか、リファインメントはどのように行うのか、各種スクラムイベントはどのように進めればいいのか、具体的な方法はほとんど記述されていない。
組織や事業によって状況は異なるのだから、具体的なことが書かれていないのは当然だとは思う。
それに、何か具体的な方法論を書いてしまうと、どれだけそれを「一例である」と断ったところで、それが独り歩きしてしまうのは目に見えている。そしてそれさえやっていればいいと誤解されたり、逆にそれ以外のやり方は許されないと解釈する人たちが現れたりしてしまう。
だから、スクラムガイドがシンプルなものになっていること自体は、妥当なことだとは思う。
しかしシンプルにすると今度は、別の問題を生む。
具体的にどう実践していいのか分からないし、都合の良いように解釈できてしまう。
結果的に、スクラムガイドに書かれている「プロダクトバックログ」や「スクラムイベント」、「スプリント」といったものを形式的に導入しただけで挫折してしまう。あるいは逆に、形式を満たしただけで満足してしまう。
また、スクラムガイドが具体的な指示をしていないことをいいことに「これが俺たちのスクラムだ！」と都合の良い解釈をして、スクラムもアジャイルも関係ない何でもありの状態になってしまうこともある。
ちょっと前にバズっていた以下の記事にもあるように、スクラム風だが中身は全く違う、スクラムっぽいだけの何かになってしまうというのは、本当によくある事象なのだと思う。
本書ではそのような状態をゾンビスクラムと名付けている。
遠くから見るとスクラムなのだが、近くで見ると全く違う。脳はあまり動いていないし、何より心臓の鼓動がない。
ゾンビスクラムにありがちな症例を紹介していくと同時に、本来はどうあるべきかも語られていくが、これが本書の核だと思っている。
スクラムガイドだけだと理解しづらかったり見失ってしまいがちだったりすることについて、具体例を交えながら分かりやすく説明している。
「○○であるべき」という説明だけでなく、「××になっていてはいけない」「××は危険な徴候」という説明もあることで、より具体的にイメージできるようになっている。
タイトルに「サバイバルガイド」とあるように、ゾンビスクラムから回復するための方策も書かれてはいる。
しかしテクニカルなものはほとんどなく、透明性やより有益な対話を生み出し、チームの学習を促すためのものが大半を占める。
本書にも書かれているが、組織によって状況は異なるのだから、よその組織の事例をただ単にコピーしても上手くいかない。
そのため、出来合いの方法論を引っ張ってくるのではなく、学習できる組織になることが大切である。
本書が主張していることはシンプルで、ステークホルダーにとって価値のあるものを速く届けよう、ということに尽きる。
いくらたくさんのアウトプットを生み出しても、それらが価値を生み出していなければ意味がない。
しかしプロダクト開発は複雑な仕事であるため、何に価値があるのか事前に知ることは不可能。しかも、ニーズや市場環境は常に変化していくため、「何に価値があるのか」は常に変化していく。だからこそ、実際に動くプロダクト、スクラムの言葉でいえばインクリメントを、短いサイクルで提供しステークホルダーからフィードバックを受けることが大切になる。プロダクト開発という複雑な仕事においては、事前の予測は不可能であり、失敗は避けることはできない。そのため、とにかく速く小さく失敗し、そこから学習していくことが求められる。速く届けることはビジネス上のアドバンテージにもなる。
そしてそれは簡単にできることではない。チーム内外に様々な阻害要因がある。そのためチームは、仕事のやり方や環境を継続的に改善していく必要があるし、そのためにはチームは自分たちのことを自分たちで決められる状態になっていなければならない。
本書では上記の内容を「ステークホルダーが求めるものを作る」「速く出荷する」「継続的に改善する」「自己組織化する」の 4 つに分類し、それぞれの分野でゾンビスクラムではどのような症状が出るのか、そしてなぜそうなってしまうのか、説明していく。
そのどれもが、ありがちというか、耳が痛いものばかりだった。読んでいて何度も、「やめろ、もうやめてくれ」という気持ちになった。
最後に、耳が痛かった本書の指摘をいくつか載せておく。
ゾンビスクラムに苦しむチームは、スプリントの最後に価値のあるものを届けるのに苦労している。多くの場合、動くインクリメントすらない。（中略）この症状はスプリントレビューで明らかになる。ステークホルダーは作成されたプロダクトを自分で直接さわり、検証する機会がない。チームはプロジェクターの電源を入れて派手なプレゼンテーションをしたり、スクリーンショットを見せたり、スプリントバックログにあった内容をただ話すのみである。プロダクトが検査されたとしても、「次のスプリントで終わらせます」とか「おっと、まだ動かない」などのコメントが付けられるか、非常に技術的な話かのどちらかだ。 p20-p21
腕がもげても文句を言わないゾンビのように、ゾンビスクラムチームは、スプリントが成功しようが失敗しようが何の反応も示さない。他のチームが毒を吐いたり喜んだりしていても、彼らは感情もなく諦めたように虚ろな目でじっと眺めているだけだ。チームの士気は低い。スプリントバックログアイテムは、何の疑問もなく次のスプリントに持ち越される。 p22
目的や戦略がなければ、スクラムチームは何でもありのイケイケ開発に行き着いてしまう。そこでは、すべての作業が優先度「高（または低）」になる。その結果、肥大し続ける巨大なプロダクトバックログを抱えてしまうことになる。 p54
スプリントからスプリントへとアイテムを持ち越し続けていくと、問題はさらに大きくなり、スプリントは出荷はおろか、実際には何も完成できない意味のないタイムボックスであると感じるようになってしまう。 p117
開発チームが獲得すべき重要なスキルの 1 つが、大きなアイテムを小さなアイテムに分割するスキルと創造性だ。開発チームは、コードを書くことから作業を始めるのではなく「多くのことを学び、届けるものの価値を高めるために、構築してデプロイできる最小のものは何か」と問い、挑戦し続けることを学ぶべきである。 p118
スクラムチームが学ぶべき重要なスキルに、何を改善すべきかを具体的にする方法、改善を小さく分割する方法がある。大きなプロダクトバックログアイテムを小さなアイテムに分割して完成しやすくするように、大きな改善を小さく分割すると改善が成功しやすくなる。ゾンビスクラムに苦しむチームは、「プロダクトオーナーはもっと大きな権限を持つべきだ」というような、やる気をなくすような大がかりな改善で身動きが取れなくなったり、どこから始めればよいのかわからない漠然とした改善に途方に暮れる傾向がある。 p170
従来の管理では、チームや部署、従業員の仕事が、組織で定められた計画や目的、戦略に沿っていることを確実にすることが、管理職の主な仕事とされてきた。（中略）自己管理チームは、作業を調整し、チーム内およびチーム間の自己組織化を促進するために、これとは異なる仕組みを使う。専任の役割（管理職）や標準化された構造（階層や方針）の代わりに、人を奮い立たせるゴールと惹きつける目的によって自己調整を行う。p229-p230
成功するために他の人に求めることをはっきりと言葉にするのは簡単ではない。また、そのような要求を受けたときに明確な対応をするのも簡単ではない。曖昧なコミュニケーションは不満や非難に繋がりやすい。それでは上手くいかない。自己管理するチームが成功するためには他の人からの協力が多く必要だからだ。 p251
