スクラムで実際に患ってしまったゾンビスクラム病の改善アクションを考える part1

はじめに

会社のチームでゾンビスクラムサバイバルガイドを輪読しています。
会社の合宿で以前この本を読んだことがあり、チームで読んでみる価値があると思い、この本を推薦しました。
読んでみると、自分たちのスクラムがいかにゾンビスクラムに侵されているかが浮き彫りになります。

なかなか耳が痛い話が続くので、音読するのすら辛いときがあったりするのですが、ゾンビスクラムと化してしまったチームの状況を解消するための
具体的なアクションもこの本では示してくれています。

今回は、このゾンビスクラムをチームで読んで、チームで出てしまった症状とそれを解決するための具体的なアクションを今後の行動指針として記事に起こしていこうと思います。

症状①：開発者とステークホルダーとの間に距離をとっている

具体的には、ステークホルダーがチームに要件を渡すだけで、開発チームのメンバーがステークホルダーと直接会話できていない、というものです。

本にも書かれていますが、ステークホルダーとして会話している人は、プロダクトを実際に使っている人から 4、5 人が離れていて、真のステークホルダーと会話できていない、という症状にかかっていました。

プロダクト企画の部署がプロダクトの決裁権を持っているものの、実際のユーザーに話を聞けていないので、伝言ゲームのようになってしまいます。プロダクトオーナーを含めて、開発チームの誰として一次情報を手に入れる事ができないのです。

改善アクション

真のステークホルダーを特定し、スプリントレビューに招待する

これは実施しました。というかすでにしていました。
今はプロダクトの社内向け管理画面のリプレイスをしていることもあり、実際のステークホルダーが社内の営業や経理担当の方で特定しやすく、かつ招待しやすい、というのも理由にあるかもしれません。
実際に要求をヒアリングした機能が期待通りなのかを確認してもらう機会なので、高い効果を感じています。

しかし、招待したステークホルダーにスプリントレビューの目的を伝えきれておらず、フィードバックを思うようにもらえないという別の課題が発生しています。

また、今後は社外の実際のユーザーが使用する機能の開発に入るので、その時にどうしようか悩んでいます。

ユーザーサファリに行く

ユーザーサファリとは、プロダクトのユーザーがいそうなところに実際に行き、ユーザーがどのようにプロダクトを使用しているのかを観察し、質問することです。
具体的には、鉄道運行管理のプロダクトを開発しているのであれば、実際に鉄道事業者の管制室を訪問し、実際にプロダクトを使用する手順を観察し、「この機能はあなたの日常業務にどう役立ちますか？」と質問します。

実際にプロダクトを使用するユーザーが社外にいると、これは正直かなりハードルが高いと感じましたが、営業に同行し謝礼を払ってユーザーインタビューを行うとかやってみたいです。

事前に想定される手順から質問を考えて、営業さんに質問を渡し、営業さん経由で観察と質問を行う、とかがすぐ始められて高い効果を実感できるアクションかなと感じます。
ハードルがぐっと下がるので、このアクションを実施するのは有効そうです。

症状②：価値よりもアウトプットを測る

スクラムチームがアウトカム（= プロダクトを使うユーザーに価値を届けること）よりも、アウトプット（= できるだけ多くの作業をこなすこと）を重視してしまうことですね。
これも、チーム全員にこの症状が現れていました。
エンジニアとして毎日コードを書いていると、プロダクト = コードの集合体、ソフトウェアとしてしか見れず、その機能追加で実際に事業収益やユーザー価値がどれだけ向上したかに目を向けづらいのだと思います。

自分たちの組織で大きな課題だなと感じているのは、スクラムチームがこの症状に気づいて価値向上のために行動しようとしても、ステークホルダーがこの考えから変わらないことです。
この症状になっていないかを探すべきサインとして、、他のチームとアウトプット量で比較され、（明示的もしくは暗黙的に）もっと頑張れと言われたりするケースが本書で紹介されていましたが、まさにこんな感じです。
スクラムチームからボトムアップでこの辺を理解させるのはどうしたらよいか考えたいです。

改善アクション

プロダクトバックログのストーリーの書き方を変える

今の会社で取り組んでいるリプレイスにおいてこの機能の必要性を語るのは、プロダクトオーナーである自分であるため、これは日頃からかなり意識しているところです。

具体的には、ユーザーストーリーは、「［ユーザータイプ］として、［これこれ］をしたい。それは、［これこれの結果を得る］ためだ。」の形式で書いています。胸を張って言うことでもないですね。一般的なプロダクトマネージャーやプロダクトオーナーは普通にやっているはずです。

「この機能を作ってだれが嬉しいんだっけ？」「ユーザーはこの機能をどういうシチュエーションで使うの？」という質問に自答できるように語っています。
症状①の改善も期待したいしつつ、開発チームとステークホルダーのコラボレーションを増やす、情報のバケツリレーを防ぐ、という意味で、最近ではステークホルダーをバックログリファインメントに招待するといった取り組みを増やしています。
これは、以前投稿した記事でも話しています。気になった方はぜひ下の記事も読んでみてください。

アウトカム追求型のチームになるための即効性の治療は無いと思っています。ですので、こういった活動の積み重ねで、自分のチームを変え、その次は自分のチームに近いステークホルダーを変える、といったように、じわじわと周囲の人たちの意識を変えていく必要がありそうです。

part2 以降へ続く…

実際に苦しんだ症状はこの 2 つだけではないのです。
この調子だとかなり長い記事になってしまうので、part2 以降に続きます。
今日はここまで。