キッカケ
一言で言うと、スクラム導入するなら、どうせならどっぷり浸かってやってみようという心意気でした。
スクラムを導入はしたはいいが、曖昧な知識のままスクラムを続けることで、それを続けていくことが果たして本当にスクラムを理解していくことに近づくのか？
という疑問と不安から出た感情でした。
一般的に多くの人にとって、初めて行うことに対して前任者などがいない状況で始めるというのは非常に怖いものだと思います。
後にも出てきますが、不確実性への向き合い方という面で、何から始めたらいいのかというのがボンヤリとなってる状況で人を巻き込んでやっていかなきゃいけないというのは、恐怖でしかないことです。
そんな、スクラムマスターをやってみたいけど、社内でスクラムマスターを(やってる|やったことがある)人がいないという状況の中で、自分と同じように何から手をつけたらいいだろうという思いをしてる人に経験を共有し、何から手をつけたら良いかの部分の参考になればと思い書きました。
やったこと
本を読む
必ずしもスクラムに関係してるものばかりではないですが、今年になってから読んだ本の中でアジャイルや、スクラム、そしてチームビルディングに関わるだろうと思われる本をいくつか抜粋しました。
チーム作りであったり、組織作り、そしてプロジェクトの進行というのにも、フレームワークというのがあり、それを学ぶ基礎になったと思います。
読んでいた時期と被って、仕事の内容も少しそっち寄りにもなっていたこともあり、実践しながらできたのは良かったと思いますが、学びながらの実践だったので、当時のメンバーには苦労かけてしまったと申し訳ない気持ちもあります。
ただプロジェクトを回すというだけでなく、プロダクトを作るという不確実性への向き合い方というのも以下で紹介する本で知識として取り組むことができました。
SaaS開発であったり、モノづくりというのは、大きな不確実性の毎日で、いかにブレイクダウンして、細かくすることで、何に取り組まなきゃいけないかを明確にし、一つ一つを確実性に変えていくという終わらない作業の連続なんだなということを理解し、自分がメンバーとして行う場合にも、できるだけ不確実性を意識してできるようになろうと思うようになりました。
その上で、スクラムというフレームワークを使うことで再現性の高い、かつ、チームにあったプロダクト開発に導くことができるようになれればと思っています。
最初の方に読んだ本は、まだそもそもの知識もなかったこともあり、定着も乏しく、記憶も弱かったと思うので、今一度最初の方の本を読んで、改めようという気持ちもあります。
読んだ本
みんなでアジャイル
SCRUM MASTER the boook
アジャイルサムライ
エンジニアリング組織への招待
The TEAM
童話で分かるプロジェクトマネジメント
スクラムガイドを読む
スクラムガイド2020を読みました。
スクラムの定義や理論、登場人物の定義が書かれています。
スクラムイベントの定義を理解し、何を目的にスクラムを行うかを把握します。
スクラムイベントによる目的を定義する三本柱(定義等はスクラムガイドを参照)
- 透明性
- 検査
- 適応
スクラムの成功
メンバーはお互いを尊重しながらサポートし合い、ゴールに向けて進捗することで
以下の5つのスクラムの価値基準を実践することが求められます。
- 確約（Commitment）
- 集中(Focus)
- 公開(Openness)
- 尊敬(Respect)
- 勇気(Courage)
読んでみて
シンプル かつ 的確
確かにスクラムの定義は分かるのだが、シンプルかつ的確に書きすぎて、具体例が見えてこないと想像しにくかったりもします。
例えば
9ページ: スプリントプランニングの項目に書かれている、スプリントゴールについて
トピック 1：このスプリントはなぜ価値があるのか？
プロダクトオーナーは、プロダクトの価値と有⽤性を今回のスプリントでどのように⾼めるこ
とができるかを提案する。次に、スクラムチーム全体が協⼒して、そのスプリントになぜ価値
があるかをステークホルダーに伝えるスプリントゴールを定義する。スプリントゴールは、ス
プリントプランニングの終了までに確定する必要がある。
12ページ: スプリントゴールには
確約（コミットメント）：スプリントゴール
スプリントゴールはスプリントの唯⼀の⽬的である。スプリントゴールは開発者が確約するも
のだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。スプリントゴールはまた、⼀貫性と集中を⽣み出し、スクラムチームに⼀致団結した作業を促す
ものでもある。
スプリントゴールは、スプリントプランニングで作成され、スプリントバックログに追加され
る。開発者がスプリントで作業するときには、スプリントゴールを念頭に置く。作業が予想と
異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダク
トオーナーと交渉してスプリントバックログのスコープを調整する。
とあります。
言いたいことは分かります。
スプリント内で価値を持つゴールを定めて、全員で達成することによりスプリントの完了を成果として残す。
しかし、これを読んでも「スプリントの価値って、どんなものがあるのか？」や「どれくらいの大きさのゴールを定めればいいのか？」が分からず、いざやろうとしてもこの説明だけではどうしたらいいか分からず困ってしまいました。
そんな時、いろんなアジャイルコーチやスクラムマスターの方の記事を読み、なんとなくイメージが湧きました。
先日読んだこちらの記事は非常に面白く、一気にゴールのイメージへの解像度が上がった気がしました。
スクラム外の要素
スクラムの記事を読んでいると、「ベロシティ」や「ストーリーポイント」などがいろんな記事で出てきたりしますが、スクラムガイドには一言も出てないのです。
アジャイルの文脈で出る言葉とスクラムのスコープとの境目が、自分のような初心者には混乱を招く要因でした。
アジャイルも並行して本を読んでいたので、スクラムの文脈で使った言葉がスクラムのスコープ外だったというのもよくあり、「スクラムをする上で」何をすれば良いのかという棲み分けが難しいです。
とりあえずやってみて
やってみました。
当然、右も左も分からず、スクラムマスターがこれまでいた訳ではなかったので、本などの見よう見まねです。
しかも、開発者との兼務だったので、イベント中は頭の中がパニックになります。
さらに、背景としてスクラムのフレームワークが今のチームに適用できるかどうか分からない状況下だったので、
スクラムの導入に意味があるのかというところはずっと頭を悩ませていて、今も悩ませています。
失敗
イベントにおける自分の立ち位置
スクラムマスターとして、メンバーの意見に耳を傾けることを意識しました。
引っかかることがあったり迷いがありそうであれば、深掘りしたりチームへの問いかけを行うように心がけてみました。
しかし、そこで自分はメンバーでもあるため、自分の問いかけに自分で答えないといけないという一人芝居のようなことが起こりました。
ここで、他の人からも意見を募ったり、機会を別途用意すれば良かったのかもしれないですが、自分は自分で答えを出そうとしてあれこれ考え、肝心のファシリテートの進行が難しくなる場面もありました。
慣れていればスムーズに意見を募ったり、レトロスペテクティブに繋げることができたのかもしれないですが、慣れないうちはただ順番に進行するだけの存在になり、うまくファシリテートできなかったなと経験不足もあり反省してます。
盛り上がる議題に一石を投じる
順調にイベントが進めばいいのですが、プランニングで迷いや不確実が残ると議論が広がることがありました。
これは当然の流れなのですが、いつまでもその場で議論することはできないのでタイムキープする必要がありました。
「この議論は、あと何分だけしましょう」という石を投じるのには「勇気」がいります。
みんなヒートアップしてる中に、水をぶっかけて頭を冷やすような行動なので、慣れないと場を白けさせる存在になりかねません。
解決策として、オフラインであればタイマーとかを用意しておけばいいのですが、オンラインだとスクラムマスターが画面共有しタイムキーピング用の時計をでかでかと表示させたり、Slack等の場合はスタンプを投じることで、声を出さずに時間を思い出すキッカケを作れるような意見を頂き、実践するようにしました。
スキップが生じる
レトロスペテクティブで、スクラム進行や課題となる障害の改善を行うと思います。
しかし、やはり忙しさが重なったり、様々な要因でスキップすることも出てきます。
特にレトロスペテクティブを2週間毎とかにしている場合は、一度のスキップで1ヶ月伸びることになるのですが、その時点で改善が大幅に遅れるなどが発生します。
他のメンバーとのスケジュールの調整もあるので、なかなか振り返りができず別途用意することもできなかったりなどがありました。
さすがに2回連続スキップが発生しそうな時はストップをかけ行いましたが、予期しないハプニングによるスキップをどうするか、チームを観察したり、前もってどうするか決めておくと良さそうというのを思いました。
レトロスペテクティブのジレンマ
レトロスペクティブで出てくる、チームの声というのは注意深く傾聴する必要があります。
どこに障害を持っているか、精神的なものなのか、プロセスのものなのか、体制的なものなのか。
しかし、自分が「メンバーとして」障害を書いた時、自分自身がスクラムマスターでもあるとそれを深掘りしていくのに気後れする時もあります。
他のチームメンバーが出す障害について広げて、解消に努めるのはスクラムマスターでもありますが、自分が出す障害について、自分で取り上げるというのは気まずさを感じました。
誰か取り上げてくれーーという気持ちを持ちながら、自分が取り上げにくい上にファシリテートを進行するので、結果として次の障害に焦点を充てて行きがちになります。
非常にジレンマとなります。
まだ、ここに対するアプローチは「兼務を無くす」くらいしか出ていないです。
匿名投稿制のものにして、個人に紐づく特定の障害としてではなく、全体に対する障害として取り上げたりすれば良いのかなと考えたりはしてますが、まだ実践はできていないです。
参考にさせてもらったサイトや記事
まとめ
今年一年は組織作りをかなり意識した学習が多かったです。
実践でもそうですし、知識のインプット、自分の考えのアウトプット、それらを全部含めてもかなりの時間と労力を使いました。
しかし、そうは言ってもまだ一年。スクラムマスターについてはまだまだ2ヶ月程度です。
昔から組織作りには興味はあり、見よう見まねで学んでいったものの、ちゃんと手をつけ始めることができたのは良い動きだったと思います。
まだまだ、ベロシティの計測であったり、リファインメントの粒度の認識合わせなど、改善は続けていこうと思うので、これからも組織作りのエキスパートの方の話を聞いたり、自分でも実践したりと、長く付き合いつつ記録していこうと思います。