スクラムで実際に患ってしまったゾンビスクラム病の改善アクションを考える part2
はじめに
この記事は、前回投稿した「スクラムで実際に患ってしまったゾンビスクラム病の改善アクションを考える part1」の続きです。
もし最初から読みたい方は、下のリンクからどうぞ。
症状③:開発者はコードだけ書いていればよい
ゾンビスクラムサバイバルガイドでは、この症状について以下のように書かれています。
以前の自分のチームでは、ステークホルダーとの会話はプロダクトオーナーが 10 割で、開発チームはスプリントバックログをこなすだけ。といった体制でした。
これの問題点は以下が考えられます。
情報が伝言ゲームのようにわたってくるので、本来知りたいこと以外の周辺情報を拾いにくい
ステークホルダーがポロッとこぼした周辺情報から実装が大きく変わることもあるが、それに気づけない
社内受託のように開発タスクが振られるだけになってしまい、プロダクトに責任を持たなくなる
改善アクション
ユーザーサファリに行く
ユーザーサファリについては前回の記事でも紹介したので、今回は軽く紹介のみします。
ユーザーサファリとは、プロダクトのユーザーがいそうなところに実際に行き、ユーザーがどのようにプロダクトを使用しているのかを観察し、質問することです。
この本では、この症状を改善するためのアクションとしてもユーザーサファリが紹介されていました。
フィードバックパーティーにステークホルダーを招待する
ざっくりいうとスプリントレビューにステークホルダーを招待する、というのがこのアクションです。
本書では紹介されているのは対面での実施を想定していたので、リモートワーク主体の自分のチームに導入できそうな形に改めてみると以下の手順になりそうです。
スプリントゴールに設定した作業について、アイデアやフィードバックを持っていそうなステークホルダーをスプリントレビューに招待する
スプリントレビュー前にチームにとってフィードバックがほしい機能またはアイテムを 5 ~ 7 個選び、機能やアイテムごとに ミーティングルームを作り、ルームごとにチームメンバーをルームオーナーとして割り当てる。そしてルームオーナーはフィードバックを記録するためのポストイットやメモの準備をする
スプリントレビューの最初に、ステークホルダーを歓迎し、なぜ彼らの参加が有益なのかをしっかり説明する。そして、軽くルームを紹介し、10 分の短いタイムボックスでステークホルダーがルームに入り、インクリメントを試し、フィードバックできることを説明する
ルームオーナーに簡単に機能の説明をしてもらう。その後、全員が各ルームへ均等に分かれ、1 ラウンド 10 分で、グループは順番にルームを訪問する。このとき、ルームオーナーは新機能をデモするのではなく最低限の機能を案内だけ行い、ステークホルダーに新機能を試してもらう
グループがすべてのルームを見て回ったら再度全員を集めて、「今見てきたことを踏まえて、今後私達は何をやっていけばよいですか?」と質問し、考えてもらう。1 分後、ペアになって考えたことの共有をお願いする。数分後、ペア同士で 4 人組を作り、5 分間で自分たちの考えを深めてもらう。その後、グループ全体で共有し、最も重要なアイデアを記録する
ステークホルダーに時間の余裕があれば、次にやることやルームでのフィードバックを掘り下げる。プロダクトオーナーはスクラムチームと一緒に、フィードバックを具体的なアイテムや今後のスプリントの目標に落とし込んでいく
本書でも言われているとおり、いきなりこれを導入すると初回はかなり気まずい雰囲気になりそうです。
自分で考えても、実行に移すのはかなり腰が重いのですが、緩やかにステークホルダーがこの取り組みに関心を高めていくことを期待して、取り組むべきですね。
症状④:関与しなくてもよいと思っているステークホルダーがいる
この症状の具体事例は、スクラムチームがステークホルダーの時間を奪ってしまうという理由からスクラムイベントに招待しなかったり、ステークホルダーの関心が薄く、「あなたは専門家なんだから、自分でなんとかしなさい」といった態度を示したりすることです。
改善アクション
スプリントレビューでフィードバックを求め、リリース可能な価値としてスプリントごとに出荷する
この症状を解決するためには、スプリントレビューでフィードバックを積極的に集め、それを早い段階でインクリメントとしてステークホルダーに届けるしかないかなと思います。
ステークホルダー自身がフィードバックしたことが、すぐにプロダクトの価値として現れたら、スプリントレビューやその他の関わり合いに積極的になろうと思えるはずですので。
Part3 へ続きます。
この記事が気に入ったらサポートをしてみませんか?