現場で感じた、いい雰囲気でスクラムを実施する7つのポイント

はじめに

初めまして！
メンバーズの宮本と申します。
現在、アカウントリーダーとしてクライアントのシステムの開発を支援させて頂いております。
今日は現場で感じたスクラムをなんとなくいい雰囲気で実施する、7つのポイントをご紹介します。
「現場でアジャイル・スクラムを実施していて、何かしらより良くしたい」
そういった方にぜひ読んでほしいブログになります。

7つのポイント

１：チームで目標を共有しよう

「チームが共通の目標を持つことが重要です。」そんなことはみなさん百も承知ですよね。
「目標」の捉え方について2つのポイントをお伝えします。

1-1.スプリントゴールは途中で変更してもいい　※1

スプリントを開始するタイミングで、スプリントで達成するゴールを決めているチームは多いですよね。
1week、2week、さまざまなスパンでのスプリントがあるかと思いますが、スプリントゴールを途中で変更したことはありますか？
本来の概念では行わない行為なので、初め僕は変更することに抵抗がありました。
やってみてからはスプリントの途中で、以下のアクションを実施しました。

1.何かしらの理由で「今週のスプリントゴールについて達成が難しいな！」と感じたら、時には本来のスプリントの概念の王道から外れる
2.スプリントゴールを変更して達成できる目標に修正をする

このようなアクションを行うことで、スプリントをPO・PM・ステークホルダー・開発者含めて、チームの関係性を向上させるために結構良いことだなと思いました！
スプリントの問題の本質を隠すための利用ではないことと本来の概念とは異なることは釈迦に説法かと思いますが、読まれている方も認識いただければと思います！

※1:スプリントゴールは基本的に変更しないことが望ましく、また「達成が難しいから変更する」は、その根本となる問題を隠してしまう可能性があります。また、そうした事態が頻発するようであれば、それはチームに問題があることを意味します。
参考:https://www.ryuzee.com/faq/0079/ 

1-2.中期的な目標をチームで共有しよう　

スプリントゴールはもちろん共有すると思います。ですが、1〜3ヶ月くらいの開発の流れなどを共有することでステージを把握できたり、開発する順序の意見が上がりやすかったりするメリットがあります。
目標の粒度はそこまで個人的には決まりがなく、「◯◯周りの実装は来月には終わっていたい」ぐらいでもわかっていればいいなと思っています。

２：困っていることは毎朝確認しよう

デイリースクラムの冒頭で簡単な雑談を行っているチームも多いと思います。
自分達もデイリースクラムの冒頭で簡単な雑談を行っていました。
デイリースクラムの中で困っていることの共有を行ってみました。
困っていることがなくても「ないです！」の一言があることが大切だなと思いました。
途中で「あ！」と思い出す人もいますし、デイリースクラムの後にそのまま困ったことを解決するのに会議が必要な場合は、カジュアルに開催することができ、問題解決までの時間が早くなりました！

３：リファインメントの事前準備をしてみる

リファイインメントが長引いてしまうことが度々ありました。
リファインメントで、話が右往左往してしまわないように、完了条件の整理や来週おこなうタスクなどをあらかじめ作成する事前準備を行ってみたところ、リファインメントの時間の質が向上したように感じました。事前準備として行ったことはタスクによりけりですが「完了条件の記載」「実装の背景・概要の記載」「必要資料へのリンクの事前設置」などです！

４：割り込みタスクは基本、リファインメントまでにもらおう

チームに、「割り込みタスクの発生があり、本来のタスクが進行しない！」といった悩みがありました。

僕たちのチームではスプリントの中盤にあるリファインメントを次回のスプリントのタスクを決定する活動としています。もし、POやステークホルダーが次回のスプリントで行ってほしいタスクがある場合は、その活動までにタスクの依頼をもらうようにしました！
そうすることで、完了条件などの整理もしやすくなり、普通のタスクと何ら変わりなく消化できました！

５：レビュー会は褒めてもらう場として認識してもらおう

どうしても実装した画面や機能をレビューする場なので、仕様、デザイン、使い方などさまざまな話やフィードバックが多く出ることで雰囲気がよくないという問題がありました。全体的に明るい雰囲気、褒める場であることをフィードバックをする方々に理解してもらうために、そのことをお伝えしてしました。
そこからレビューの雰囲気がよくなり、活発な議論が増えた気がしました！

６：ふりかえりのtryはベストじゃなくて、ベターでいい

問題があると、どうしてもベストアンサーが欲しくなる問題がありました。今より良くなるベターなTryで「とりあえずやってみよう」という考えを大事にしてtryを考えるようにしてみました。
理由としては下記２点です
・やってみないとわからない
・柔軟な意見が出やすい
そこからいいTryが生まれて、チームの改善が進んだ気がします。

７：タスクのタイトルを「誰が、何をできるようになる」文面にしてみた

リファインメントで作成するPBIのタイトルの付け方を工夫してみました。
レビュー会で使用する資料など、そのままタイトルを使用する機会が多かったので、ステークホルダーにどのタスクが何をできるようになるのか一目でわかるように「誰が、何をできるようになる」にするとわかりやすさが増した気がしました！「システムが、請求書を自動で作成できる」「事務の人が、顧客登録できる」「お客さまが、請求情報を閲覧できる」などです！

ブログを最後まで読んで頂き、ありがとうございます！
少しでも参考になるものがあれば、とても嬉しいです。
これからも新しい記事をお楽しみいただければと思います。