はじめに
まだ道半ばです。
この記事は、やったことの備忘録として、都度編集していきます。
私について
開発メンバーとしてフリーランスでジョイン。
ジョインしたタイミングでちょうど、スクラムをやってみようという事になった。
スクラムマスターではなく、1メンバーとしてスクラムの導入を引っ張ることに。
チームについて
メンバーは私含め6人。
スクラム経験者は私のみ。
なんとなく、POとSMだけ決まっている。
これまではチームに分かれておらず、リーダー2〜3人、メンバー15名弱が各々作業していた。
なぜスクラムを導入することになったのか？
なんとなく部署内で「アジャイルって良いらしいね」「スクラムというやつやってみようよ」と話が挙がったことがきっかけのよう。
導入においてやったこと（〜1ヶ月）
スクラムとは何か？を共有する
まず初めに、スライドを用いてざっくりと以下について説明しました。
- スクラムとは
- どんなイベントがあるのか
- スケジュールのイメージ
スクラムガイドの読み合わせ
章ごとに担当者を設定し、5分間で各々読みながら、感想や学んだことを付箋に書くというワークショップを行いました。
ツールはmiroを使用しました。
【所感】
スクラムについての知見が少し付いたほか、miroすごい！という感想が挙がったりしました。
ホワイトボードの作成
日々の出来事を付箋に書いて貼れるボードを作成しました。
目的は、レトロスペクティブで出来事の振り返りがしやすいようにです。
ツールはmiroを使用しました。
最初は書き込む癖がなかなかつかないため、度々周知して癖づけてもらいます。
【所感】
初めは何を書けばいいのか分からない状態でした。
レトロスペクティブを実践していくうちに、議題に挙げられそうな付箋に絞られてきました。
レトロスペクティブの実践
スプリントはまだ始まっていませんが、ホワイトボードの付箋を元にレトロスペクティブを行ってみました。
私が説明を交えながらファシリテーターを行いました。
2週に1度、行うことになりました。
【反省】
説明を交えながらだったので、タイムキープが難しく、オーバーしてしまいました。
ですが、TODOまで決めることが出来、メンバーも「こんな感じなのか」と少し分かったようなので良かったです。
バックログリファインメントの実践
スプリントプランニングの前にバックログの整理をする目的で、リファインメントを行いました。
ポーカーをしてポイントを決めるという流れを体験してもはいました。
使ったツールはfirepokerです。
https://firepoker.io/#/
【所感】
チームに別れたばかりで、まだ各メンバーがそれぞれバックログを抱えている状態だったので、他メンバーに概要を共有するのに少々手こずりました。
また、別チームで担当するはずのバックログを持っていたりして少々カオスな状態でした。
いきなりチームにシステムを紐付けて分ける場合、混乱が生じるかと思います。
各イベントの台本を用意
私以外もファシリテーターができるように台本を用意しました。
またスクラムを始めたての頃はイベントの進行イメージが沸かないと思うので、こういったものを用意してあげるのは有効だと思います。
チームビルディング
目的：他メンバーの得意・不得意を知ることで、質問やコミュニケーションを取りやすくする
スキルマップの作成・共有
miroにこのようなグラフを各自作成し、共有しました。
ドラッカー風エクササイズ
参考： https://tech.pepabo.com/2017/07/07/the-drucker-exercise/
miroにこのようなスペースを作成し、実施しました。
とりあえずスプリントを始める（2ヶ月目〜）
やってみないと流れが理解できないだろう、ということで、実際に始めてみることに。
スプリントプランニングの実施
初回はまだ各自がバックログを持っている（属人している）状態でした。
ですので、各自が消化できそうな量のバックログを積み、スプリントをスタートすることに。
バックログリファインメントの実施
週に1度実施することにしました。
属人化していたバックログについても徐々にメンバーへ共有していき、チームの透明性が上がったかと思います。
スプリントレビューの実施
ステークホルダー（実際にシステムを利用する部署の方）を呼べないという事情が発覚。
仕方なく、チーム内のPOとメンバーでデモンストレーションを行い、フィードバックをあげる形で進行しました。
【所感】
これは今も続いている状況です。
ステークホルダーに見てもらえないとレビューの意味があまり無いと個人的に思っているので、ステークホルダーを招待するメリットを訴えていく必要があると感じています。
レトロスペクティブの実施
スプリント初回のレトロスペクティブでは、「これでスクラム開発ができているのか」「何ができていなくて何をすべきか分からない」のような疑問もありました。
これに関しては疑問や課題をとりあえず挙げていき、議論していくしかないのかなと思います。
現時点でのチームメンバーの感想
メリット
- コミュニケーションの機会が増え、質問などがしやすくなった
- 開発の効率が上がった気がする
- お互いが何をしているのか分かるようになった
- 実装方針や設計について相談することで、クオリティの担保ができている
デメリット
- MTGが多くなったので、開発時間が少なくなった
- メンバーに共有するなどの手続きが増えたので、開発効率が悪くなった気がする
導入前にやっておけばよかったこと
各種数値や課題を収集する
スクラム導入後、「なんとなく良い気はするが、本当に良いのか？」という疑問があがりました。
作業効率がよくなったのか、課題を改善できたのか等を比較・精査できるように、事前に数値や課題の収集・アンケート等を行っておくと良いと思いました。
主に以下を収集しておくといいかと思います。
- 作業の完了スピード
- アンケート
- 心理的安全性
- チームの透明性
- 現状の課題
その他
おすすめの書籍やコミュニティを共有する
以下の書籍とコミュニティを共有しました。
【書籍】
- アジャイルサムライ−達人開発者への道−
- いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法
- SCRUM BOOT CAMP THE BOOK
- アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット
【コミュニティ】
今後の課題
- スプリントレビューにステークホルダーを招待する・または成果物にフィードバックを得られる仕組みを構築する
- スクラムの成果を数値で集計する