- なぜスクラムを実施しているのかをチームメンバに理解してもらい、自発的に参加してもらう必要があった
- 長期間続けるためには、スクラムの運営に必要なタスク(ex. プランニング/レトロスペクティブ)を特定の個人に集中させない必要があった
- なぜチームがスクラムを実施しているのか、スクラムを実施する上でメンバーに求められる考えは何か、などチームの基本方針となる文書をまとめた
- まとめた文書をプランニング/レトロスペクティブのはじめに必ず全員で読み返すようにした。これはある程度考えが定着した現在でも続けている。(繰り返しによる定着)
- 文書が陳腐化しないように、方針に対してチームメンバーから生じたフィードバックを即座に反映させるようにした。
- プランニング、レトロスペクティブのファシリテータを持ち回り制にした。
- 単純に持ち回り制を導入するだけでは上手くいかなかったため、プランニング、レトロスペクティブの手順をまとめ、その手順に沿って進めるようにした。
- 手順はフィードバックが発生次第、即座に反映するようにした。プランニング、レトロスペクティブの最中に更新したこともある。
- 二週間を一単位としたスプリントの他に、四半期を一単位とした規模の大きいレトロスペクティブを実施した。
- ここでは、日々のタスクよりも視点を高く持ち、チームのあるべき方向や各自がしたい新しい挑戦について議論する。
- スクラムの運営を補助するツールの作成を奨励した。エンジニアの興味とスクラムの運営を同じ向きにすることが狙いだった。
- タスクサイズをissueラベルで表現し、Github GraphQL API、Google Colaboratoryを用いたメトリクスの集計・可視化をレトロスペクティブ時に実施する。
- 付与されたサイズラベルを読み取り、どのくらいのサイズで見積りが行われたかをClose時に通知するGithub Actionsを作成する
- 補助ツールの作成に使用する技術の勉強会を開催する
- Github Actions
- Cloud Run
- Golang
- 補助ツールの開発をモブプログラミングで実施する