背景

私はとある企業の子会社に出向し、とあるSI案件にて4年間、スクラムチームでシステム開発のPO/SM/Devを任された。

もうその現場での成長は鈍化したと感じたため、本社に戻りプロダクト開発のスクラムチームのPOを任されることに。

ただ、そのチームはスクラムなどやっていなかった。

スクラムの三本柱が崩壊

「透明性」「検査」「適応」が機能していない。

メンバーが何をしているのか、何に詰まっているのかが全く見えない。
スプリントにゴールがなく、何となくプロダクトバックログから取り出す。
レトロスペクティブは時間がないのでできない。感じたことがある人だけWikiに書いている。

三本「柱」とは言っても、こちらの記事で書かれているように「層」のイメージです。
「透明性」が確保されていないのが原因でしょうか？

新規メンバーを受け入れる準備（体制、余裕）がない

Wikiが新規メンバー向けじゃない、新規メンバーに目を向ける暇がない。

配属して2日目にしてチームのWikiを拝見しました。

それまで特にプロダクトやチーム（特に運用ルール）に関する説明もなかったもので、Wikiだけが頼りです。

するとまず思ったのが、エントリページはどこや？

いきなりプロダクトのコンポーネントごとにスペースが分かれていて、全体の概要が分かりません。

試しに開発関連っぽいスペースに入ってみると、コンテンツが細かくグルーピングされて全て同じ階層にまとまっています。

どれから読めばいいんでしょうね・・・？

また、めちゃめちゃエンジニア目線の資料ばかりです。
着任初日に誰がサーバのIPアドレスなんて知りたいんでしょうか・・・。

これに関しては同じ課題感を持つチームが多いでしょう。

確かに業務が忙しいとドキュメント作ってられないですよね。開発やりたいのにドキュメントなんて作りなんてモチベーション上がらないですよね。

でも結果としてチームのベロシティ下げる要因になってませんか？

現時点でわかっている要因

とりあえずスクラムマスターにぶちまけたところ、

• メンバーが他のスクラムチームも兼務している
• 基盤寄りの開発チームのため、そもそもスクラム体制が適しているのかがわからない

とのことでした。

前者は日本全体の問題ですね。
とはいえ、「しょうがないね〜」で片付けるのは私が許しません。
そもそも同じPdMチームを囲うスクラムオブスクラムチーム（表現古いか？）なのですから、チーム間で解決を試みるべきでしょう。

後者はチーム作りに問題がありますね。
現SMを否定するわけではありませんが、スクラムの価値、哲学をチームに教えることができているのでしょうか？
スクラムイベントの存在と進め方だけ教えて、それぞれの意義を伝えているでしょうか？

このスクラップについて

語れるほどの経験値はないので、チーム再建のTry&Errorを赤裸々に綴っていくことにします。
もちろんですが、

• 再建前に異動する
• スクラムチームを解散する

オチもありますので、ご了承ください。コメントもお待ちしております。

オンボーディングに関しては私の考えていることをまとめてくださっている記事がありました。

新しいメンバーの受け入れ体制について

とりあえずチーム運用改善に取り組みたかったのだが、チーム全員が空いている時間がないという始末。

全部キャンセルしてでも頼むべきだが、色々と事情もあるのでここは我慢。

課題抽出

まずはチームメンバーが言語化、共有できている課題についてアプローチしていこうと思い、
王道ですが KPT でチームの「Keep」「Problem」「Try」を洗い出しました。
すると、

1. コミュニケーションが取りづらい
2. スクラムイベントが機能していない
3. プロジェクトの見通しが悪い（透明性がない？）
4. プロダクトバックログが作れていない
5. 開発体制がぐちゃぐちゃ

という感じでまとまりました。

特に 5 に関しては業務のクロスアサインを別のチームと実施している関係で、
スプリントに集中できていないという本末転倒な状況です。
他はスクラムガイドに従ってまずはシンプルな構成にすれば少しはスッキリするかな？という印象です。

活動ルール制定

抽出した課題をもとに、今まで暗黙的にしかなかったルールを明文化し、内容も改めてみました。
あまり多くのルールを作っても定着しないでしょうし、もちろんスプリントごとにしっかり振り返り改善を繰り返していきます。

コミュニケーション

最終目標は進捗報告や課題共有のためだけの定例を無くすことです。

• NeWorkをメインツール、Microsoft Teamsをサブツールとする
  • これまでチームが使っていたツールなのでそれを継続
• 会話可能な時間帯は NeWork の専用室に常駐しておく
  • 出社して皆が同じ島にいた時代を思い出して、気軽に話しかけてほしい

プロダクトバックログ

我々のチームは Jira にて課題を管理しています。
課題の種類を以下のように分けました。

種類	定義
エピック	四半期や半期レベルのプロダクトゴール。複数のストーリーで構成される。
ストーリー	プロダクトバックログアイテム。1スプリントで終わる大きさにする。
タスク	スプリントバックログアイテム。1日で終わる大きさにしたい。
トラブル	障害等トラブル系。緊急性に応じて PO がスプリントに割り込ませるか判断する。

私が着任するまでエピックはただの課題のカテゴライズに使っていたので、
なんのための pbi なのかを意識させます。

課題への取り組み

• 作業プロセスを課題の中にコメントで残す
  • 個人の作業をオープンにし、早期に協力、検査/適応させる
  • これまで全く個人の進行中作業が見えていなかった
• なるべく複数人でストーリーに立ち向かう
  • 専門でない人は専門の人と組んでみましょう
  • これまで基本個人にアサイン
• 現在進行形で作業しているストーリーのみ「進行中」ステータスにする
  • 個人の作業をオープンにする
  • これまで同じ人物が同時に複数着手している不可思議な現象が発生していた

「個人の作業をオープンに」を特に意識させることにしてみました。
コミュニケーションさえしっかり取れれば不要と感じるかもしれませんが、
プロセスに潜在的な課題がある場合はこの意識が課題を表面化してくれるでしょう。