見出し画像

スクラムチームに役立つエクササイズがあると聞いてやってみた

shinichiro.kamo

この記事はスクラムマスター Advent Calendar 2023の17日目の記事です。

アドベントカレンダーで何を書こうか考えていた時、Xを見ていたら、
とあるポストを見かけました。

お題のカンバンボードをみて5分ほど考えてみた結果、いいなと思う点と気になる点もどちらも見つかり、せっかくの機会なのでと自分なりの見解をまとめてみました。お題の画像はこちらにあります。

是非皆さんも考えてみてください

いいなと思った点

まずはいいなと思った点からです。全部で7つあります。

①プロダクトゴールとスプリントゴールが可視化されている

今回のようにカンバンボードの近くにスプリントゴール・プロダクトゴールが置いてあると何度も意識するきっかけになるし、ふとした議論の時にゴールは何か確認しやすいので、いいなと思いました。

②スプリントゴールに紐づくPBI（プロダクトバックログアイテム）の優先順位が高い

スプリントゴールを達成する上で、「2拠点の信号機の間でシンプルなpingを送信する」は最初に検証することが重要である（なぜならシンプルな情報送信ができないと他の情報送信も実現できない）ので、優先順位をあげて取り組んでいるのはいいことだなと思いました。

③小さく実施している

たまにスプリントゴールとPBIの関係が1:1（1つPBI完了がスプリントゴール達成になる）になっているのを見かけますが、スプリント中の方向転換が難しくなるのであまりオススメできません。
今回のカンバンボードを見ると、「信号機との交信」を実現するためにまず送信自体が可能なのかを実現しようとしています。このようにシステムに対する変更を最小単位で実施しようとしているのがいいなと思いました。

④アラート情報を可視化している

アラート状態であることが、視覚的にわかりやすいのと、何が起きているのかを記載しているので何をすべきか判断しやすいのがいいなと思いました。

⑤誰が何をしているか可視化している

誰がどのタスクを実施しているか可視化するというカンバンの原則を体現していていいなと思いました。あと好みの問題ではありますが、人のアイコンが実物写真だと少し硬い印象を持ってしまうので、今回のような遊び心を感じるアイコンはいいなと思いました。

⑥PBIに紐づかないタスクも可視化している

スプリント中はスプリントゴールとの関連が薄いタスク（今回の場合オンボードタスク）を取り組む機会も多いと思います。これらのタスクがブロッカーとなりスプリントゴールの達成に影響が出ることも十分にあり得るので、可視化するのは大事なことだと思っています。

⑦開発系以外のタスクも可視化している

「契約」タスクが何を指しているかは確認したいところですが、恐らく他システムから交通データを取得するための契約なのではと推測します。
タスクの中身は必ずしも開発に関わるものとは限らず、「PBIを完成させるために必要なタスク」を洗い出すことが重要です。その点、今回のカンバンボードを見ると開発以外のタスクも可視化できていていいなと感じました。（一方で契約は事前にすべきではと思ったので、気になる点に入れています）

気になった点

次に気になった点です。全部で8つあります。

①「デモ&フィードバック」におけるレビューとは何を指しているのか？

最初に見た時に、「デモ&フィードバック」をレビューするってどういうことだ？と言う疑問が湧きました。「デモ&フィードバック」を関係者と実施するという話であれば進行中のレーンに置くのが適切かなと思いました。

また、付箋の内容から色んなシチュエーションが想像できるなと思っています。「関係者から返事がない」と書いてあるので、「デモする場に招待したけど返事がない」か「フィードバックをしてくださいとお願いしたけど返事がない」のどちらかの状況なのかなと推測しました。後者の場合、非同期的にスプリントレビューを実施している可能性がありそうです。
仮に非同期的に実施しているとしたら「ステークホルダーがプロダクトにあまり関心がない」、「チームが動くものをデモの場に持って来れていない」などの状態が起きてるかもしれません。そのため、どうして非同期で実施しようとしているのか理由や経緯を聞いてみたいと思いました。

②タスクの粒度が粗いのではないか？

タスク全体に言えることですが、タスクの粒度をもっと細かくできそうだなと思いました。例えば「開発」タスクにもサーバー実装・フロント実装など複数のサブタスクがある可能性があります。「開発」のような大きな括りでタスクを扱ってしまうと一人で開発作業を全て実施してPBI完成のブロッカーになってしまうリスクや、仮に複数人で協力していたとして誰が何をしているかの透明性が低い状態と言えます。

③PBI毎に完成の定義が異なっていないか？

PBI毎に実施しているテストが異なっているのが気になりました。どのようなテストを実施するかは完成の定義で定めていることが多いと思うので、「完成の定義が定まっていない」あるいは、「定まっているがきちんと運用がされていない」の可能性があるかなと思いました。（意図して実施テストを変えている可能性もあるのでその辺りはチームに聞いてみたいところです）

④特定の人に負荷がかかってないか？

レビューのレーンを見るとひげアイコンの方が2つタスクを持っていることがわかります。しかも2つのPBIに関わっているため、同時に進めているとすると、PBI完成のブロッカーになっていないか気になりました。また、複数PBIを同時並行で進める場合、複数人で協力するのが望ましいのですが、カンバンボードを見る限り開発系のタスクはひげアイコンの方が持っているため、特定の人に負荷がかかっていないのかも気になりました。

⑤作業の属人性が高くないか？

④とも似ていますが、赤の男爵アイコン？の方がドキュメント作業を全て担っているので、作業が属人性が高くないか気になりました。
また、作業前のレーンの状態を見て事前に男爵アイコンとひげアイコンの方にタスクが割り振られているのも気になります。得意分野のため実質やるだろうと割り振っているのではないかと推測しますが、事前に割り当てしまうことで、計画が硬直化し、不足の事態の時に修正がしづらくなる恐れがあります。今回の例だと、ひげアイコンの方がすでにレビューレーンで２つタスクを持っていますが、片方のレビューが長引いてしまい、もう片方のレビュータスクや作業前レーンにあるクレンジングの確認タスクを実施できない可能性は十分あります。
スプリント1であることを踏まえると、まだ得意分野が偏っていても不思議ではないです。そのため、まずはペアで作業するなど少しづつスキルトランスファーを進めていくのがいいかなと思っています。

⑥同時に仕掛かる数が多いのではないか？

全てのPBIを同時に進めているように見えますが、これだと「どのPBIも途中まで進めたが結局完成しない」リスクを高めてしまいます。
いわゆる仕掛かり数が多い状態ですね。
WIP(仕掛り数)の制限がされてないように見えるため、チームがPBIの進め方についてどのような認識を持っているか聞きたいなと思いました。
ちなみにWIPの制限についてはRyuzeeさんのブログ記事が参考になります。

⑦書かれているPBIの完了がスプリントゴール達成につながるのか？

例えば３拠点以上の交信は検証しなくていいのか？、一定以上のデータ容量の通信に耐えられるのか？などスプリントゴールを達成するために必要な要素って他にもあるのではないかと気になりました。
ただし、事前にスコープ範囲外としてチームが合意している可能性もあるので、その辺りは聞いてみたいと思いました。
また、スプリントゴールの抽象度が高すぎると、何をすればゴール達成なのかの認識が異なってしまう可能性があります。そのため、スプリントゴールをもう少し具体的に表現するのも一つの手だと思いました。（例えば２拠点間における信号機の交信を確立する、とか）

⑧スプリント開始前に確認すべきタスクではないか？

「契約」タスクですが、システムから交通データを取得するための契約と仮定すると、これはスプリント開始前に実施した方がいいのではと思いました。契約ができなければそもそもPBIを完了させることはできないし、別の会社・システムとの契約作業が必要になるかもしれません。このようなブロッカーになりうるものはスプリントに入る前に確定させてから（PBIをReadyにしてから）、またはスプリント中に実施するとしてもスプリント序盤での実施が望ましいと思います。

いかがでしたか？当然人によって見解は変わると思うので、意見などあれば是非教えてください。




この記事が気に入ったらサポートをしてみませんか？