形骸化しているスクラムイベントの生き返らせ方

スクラムはフレームワークと言われていて、実装を現場で考えることでチームの取り組み自体が改善していく仕掛けを持っている。スクラムガイドにも「ゲームのルール」と書いてあるように、この仕掛けをうまく動かすために、ロール・イベント・作成物、ルールが相互に作用し合っている。一見シンプルで単純、それゆえに難しい。

……ということを理解せずに、マネジメントのためのツールとして形ばかりのスクラムが導入されているのも、残念ながらよく見る。シンプルで単純に見えるからだろうか。ロールも揃って、イベントもやって、決められた作成物を作っているのに、まったく本質を外れたScrum But*1が足かせになってチームのモチベーションを下げているような状態だ。

全員参加が鬱陶しいだけのミーティングがやたら多いなと感じているとしたら要注意だ。スクラムをやっているチームで、「昨日これやりましたー、今日これやりまーす、問題はアリマセーン（ダルい儀式だなぁ）」「レビューやりまーす（っつーか実質進捗報告でしょ）」「はいKeep書いてー、Problem書いてー、Tryあげてー（さっさと終わらせたいなぁ）」みたいなシチュエーションに覚えはないだろうか？
おそらくそのイベントはうまくいっていないし、そもそもそのチームはうまくスクラムを利用できていない。本来は改善のメリットが自分たちで享受できるようなフレームワークであるはずなのに。

アジャイルコーチに仕事の依頼が来るようなチームは多かれ少なかれそういう状態で、自己流に色々やった結果悪化させていることが多い。しかしそんな現場によそ者が来て「そんなやり方じゃダメだ」「スクラムではこうするんだ」と型にはめようとすると、そりゃ現場の人は気分も良くないだろう。

わたしがいくつかのチームを支援してきた中で、Scrum But、つまり形骸化して機能していない仕組みを改善できるパターンが見えてきたので残しておく。

本質的で理想的なことを実現する（とくにスクラムの用語などは使わない）。
それが機能することでチームがメリットを享受できるようにする。
今までやっていた形骸化したものを捨て去る。

要は、機能不全とはいえすでに運用されているものを上書きするのはとても難しいので、新しく作って置き換えてしまおうというだけの話だ。今あるものを否定したりいきなり廃止されるには抵抗があるだろうし、旧習も抜けないだろう。システムの入れ替えには繊細な設計が必要なのだ。

事例

プロダクトの戦略は迷走し、将来のビジョンもイマココも不明瞭なチームがいた。開発チームはプロダクトバックログアイテムを作業項目に落とすことに必死で、プロダクトオーナーは開発チームにプロダクトバックログを通じて結果的に作業指示をしている。このチームのバックログリファインメントは、開発チームが細かすぎる見積もりを提示するか、Not Readyを突き返すだけの週1回の非協働的な儀式になっていた。
そこで、開発チームの選抜メンバーにはスプリント作業の邪魔にならない程度のバッファの時間を確保してもらい、プロダクトオーナーと協働してもらうことにした。入り口はユーザーストーリーマッピングで、まずはプロダクトの全貌を見直す。プロダクトオーナーは新しいストーリーを追加する時、地図のどこに追加するのか示しながら戦略、目的、価値をユースケースを示しながら共有する。開発チームは開発の観点から軽い実装から重めの実装までいくつかのオプションと、ざっくりした見積もりを提示する。プロダクトオーナーの挙げるストーリーが不要だと思えば代替手段を提案したり、優先順位に意見をしたりする。開発チームの選抜メンバーは入れ替わり立ち替わり携わることで、全員が理解を同じにしていく。この活動を薄く続けた。
プロダクトオーナーは、以前は週に1回しか開発チームからプロダクトバックログに対するフィードバックをもらえず、開発チームに手をつけてもらえるまで（Readyになるまで）時間がかかっていたが、これが早くなった。さらに、開発チームの提案の余地がないぐらい交渉不可能、かつ開発チームから見た重要な観点は抜けているというバックログアイテムを無理やり作って嫌がられるということがなくなった。開発チームは、自ら内容を理解して実現可能なオプションや見積もりを提示することができ、そうすることですなわちバックログアイテムが十分にReadyになっているのだった。
この活動を薄く続けていくことで、今までバックログリファインメントと呼んでいた週1回の謎の儀式は不要になった。