AIIT(大学院)のPBL(模擬プロジェクト)で「スクラムをやろう！でもスクラムがわからん！」ってなったのでスクラム勉強会をやりました。
メンバーの中では自分だけアジャイル開発の実務経験があったので、僕がファシリをさせてもらいました。
勉強会の概要
「SCRUM BOOT CAMP」をみんなで読むという形式にしました。
「SCRUM BOOT CAMP」は自分はそこまで推していないのですが、まわりの評判はとても良かったので採用してみました。
あとは単純に、僕がスクラムの本をあまり知らなかったというのもあります。（「エッセンシャルスクラム」が個人的にはわかりやすくて好きなんですが、初心者が捌ける分量ではないので・・・）
勉強会の形式
自分が一番慣れているのは輪読会形式ですが、輪読会形式だと5,6回くらい続けないと読み終わらないので、時間の関係で不採用にしました。
あとは、新しいやり方にチャレンジしたいなと思ってたところもあります。
そこで今回は、全員で手分けをして本を読む「アクティブ・ブック・ダイアローグ」と、知識が偏らないようにする「Triple Nickels」を組み合わせる形式で行ってみました。
こんな感じです。
結構諦めた部分もあります。
アクティブ・ブック・ダイアローグは共有後の議論が肝ですが、今回は議論をしていません。
Triple Nickelsも全員分まわすのが通常ですが、今回は2回のみです。
ここらへんは時間と人数の制約ですね。
時間をかけて深く理解するよりも、短時間で浅く全体を知ってもらいたかったので、今回は諦めました。
スクラム勉強会をスクラムっぽくやる
途中でこの形式はスクラム実践型だなと気付きました。
この形式で行うことで、スクラムの重要な要素を体験しながら勉強会に参加できます。
この形式では「読む・まとめる・発表する」を2回繰り返してます。
そう、繰り返してるんですよ。これはもはやスプリントですね！
そして繰り返しているので、2スプリント目では1スプリント目の結果を使うことができます。
1回目の「読む・まとめる」での手応えをもとに、2回目の「読む・まとめる」の時間配分をできますし、
1回目の「発表する」の感覚をもとに、2回目の「発表する」のシナリオを練ることができます。
まさに経験主義ですね！
時間配分については相対見積もりを使えそうな気もしますね！
「発表する」については、特にテンプレートなどは用意しないようにしました。
なので、「何を伝えたいか」「どのようにすれば伝わるか」は各自で考える必要があります。
スプリントレビューの準備で一番悩んだり時間かかるところと同じですね！
ちなみに、1人あたり40ページくらいを30分でまとめてもらいました。
この本は半分くらいマンガなので、実質20ページくらいですね。
それでも、30分で20ページをまとめるのはかなり厳しい話です。
この無茶振り・・・まるで開発現場のようですね？
アジャイルサムライで紹介されている3つの真実のうちのひとつ、「やるべきことはいつだって、与えられた時間と資金よりも多い」1を思い出します。
そして2回目の発表では、1回目の発表資料を追記・編集するようにしてもらいました。
「自分で作り直したほうがラクなのになー」と思ってくれた参加者もいると思います。
あら、プロダクト開発でよく聞く悩みですね。
駆け出しエンジニアたちが見落としてそうなポイントだと思っているのですが、プロダクト開発では新規でコードを書くのではなく、既存のコードを修正したり追記したりすることがほとんどなんですよね。
今回はコードではなく発表資料ですが、同じことが体験できたのではないかなと思います。
進行するうえで気をつけたこと
ちょっといくつかは気をつけて進行を行いました。
タイムボックスを守る
アジャイル開発と切っても切り離せないのがタイムボックスだと思います。
特にスクラムは各イベントの時間も決まっているので、無視できません。
なのでタイムボックスについては強く意識をしてファシリテーションを行いました。
ただ、発表時に相手の発言を遮って止めるのは良くないかなと思ったので、区切りの良さそうな部分で「時間ですー」と入れるようにしました。
褒めない・指摘しない
今回に限らず、発表をきくと「よくわかってるな！」と思うことや「いやーこれは・・・」と思うことがよくあります。
勉強会のファシリとしては褒めたり指摘したりして方向付けをするのも手段のひとつではありますが、今回は行わないようにしました。
というのも、良かろうが悪かろうがその人が学んだということは事実で、それを尊重しようと思ったからです。
自分がフィードバックを返してしまうことで、学びの方向性が狭まってしまうリスクもありそうですしね。
ふりかえりを入れる
各発表のあとにふりかえりをする時間を設けてみました。
「アジャイルと言えばふりかえり」というぐらいにふりかえりの重要性は大きいので、ふりかえりの雰囲気に慣れてもらうことが目的です。
あと、アジャイルだと意見を発散させる場面が多いので、発散の練習という意味もあります。
意見の発散は性格的な部分も多少は影響しますが、鍛えれば上達する技術です。
やってみて
自分でやってみた感想と、参加者からもらったフィードバックを参考にしつつ、ふりかえってみます。
わりと成功だったのでは
とりあえずみなさんには、「スクラム、思ったよりも簡単じゃなさそうだぞ」というのが伝わったように思います。
アジャイルをやったことない人はわりとミニウォーターフォールを想像される方が多いので、そうじゃないことが伝わっただけでも成功かなと思います。
要素を削ったほうがいいか？
参加者からのフィードバックの対象が人によってだいぶ違っていました。
とある人は発表について、とある人は時間について、別の人はドキュメンテーションについてと色々でした。
これは勉強会を設計する側の問題です。
要素を削ることによって、設計者が見てほしいところに参加者が向きやすくなるかなと思います。
ただ今回の場合は「広く浅く」がメインだったので、これでもいいのかなぁとも思います。
次に勉強会を設計する時には意識したいポイントです。
場を作る能力がほしい
個人的にはにこやかな雰囲気とか和気あいあいとした雰囲気が好きなんですけど、そういった場を作る能力はまだまだ足りないなーという感じです。
前に澤円さんの発表を聞いたときに、場を一気に和ませていたのを思い出しました。あんな風になりたい。
最近はリモート会議でもカメラオフにしているので、だいぶ表情筋が硬くなった気がします。
笑顔の練習でもしようかな？
余談
「SCRUM BOOT CAMP」の主人公はスクラムマスターで、チームの問題になりそうなことを事前に取り除いていくタイプでした。
僕はチームの前に転びやすそうな石を置いていくタイプのスクラムマスターです。
こういうのは性格が出ますね。
