この記事について
この記事は、aslead Agileの開発チーム「オキザリス」にて行っているアウトプット企画である「チーム「オキザリス」Advent Calendar」の14日目の記事です。
筆者の属性
2017年入社の社会人歴４年目の人間です。
2020年6月より業務にスクラムを取り込んで活動しています。
この記事の執筆時点でスクラム経験はちょうど６ヶ月です。
私のチームには１名アジャイルコーチがおり、週２日ほどの活動日にはいろいろとティーチング・コーチングいただきながら活動しています。
そのほか私が所属しているチームの詳細はオキザリスをご覧いただければと思います。
スクラムマスターを雇う時に聞いてみるとよい38個の質問
こちらのブログに記載されている、
「スクラムマスターを雇う時に聞いてみるとよい38個の質問」について、半年ほどスクラムを実践してきた身として、現在の理解度や自分の考えを整理する意味でこのタイミングで質問の回答を考えてみようと思った次第です。
質問数が多いため、このAdvent Calendarで予定している４回の記事投稿に分けて公開していこうと思います。
本記事はそんな企画の第三回の記事です。
第一回、第二回の記事もご覧いただけると幸いです。
それではそれぞれ考えていきます
21: どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？
品質改善はあとに回せば回すほどどんどん負債となっていくので、TDDを取り入れてみるなどしてプロダクト開発初期から時間を確保できると望ましいかと思います。
将来への投資として15%ほどとれると嬉しいなと。（私達のチームでは毎朝30分をLearning Sessionとして学びの時間としています）
また、リファクタリングなど改善の時間をプロダクト開発と切り離して考えるのではなく、あらかじめ完了の定義で
重要なバグであれば、別途バックログに積み、優先度を考慮した上でプランニング
22: チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか？
チームとして成果をコミットすることや、なぜ個人ではなくてチームとしてなのか？という点について会話をしようと思います。
チームで活動するメリットの一つとしてメンバーの相乗効果が得られることなどがありますが、個別にストーリーやタスクを割り当てることで、「自分ごと」の意識が弱まり、問題解決への協力が得づらくなることが考えられます。
プロダクトオーナーがストーリーやタスクを個人に割り当てようとする背景に、開発者に実現方法を委ねるといった権限移譲する意識がないことが原因としてあるかもしれないと感じました。
自分自身で気づきを得られるように、うまく問いかける能力がスクラムマスターにとっては必要なスキルだと思っています。
なかなかこのあたりが難しいところだといつも感じるところです。。。
23: チームメンバーによるタスクのつまみ食いをどのように扱うか？
「それってスプリントゴールに必要なの？」と問いかけてみます。
スプリントゴールの実現がそのスプリントでの最重要事項であることを思い出してもらいます。
仮にスプリントゴールに必要なのであれば、スプリントプランニング時などに漏れていた可能性もあるので、チームで対応を会話してみても良いかもしれません。
24: ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？
いくつか問いかけをしてみようと思います。
- そのユーザーストーリーは次のスプリントで実施が必須のものですか？
もし必須だという回答であれば、その理由を掘り下げていき、回答を踏まえて対応を考えるかなと思います。
25: スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？
まずはスプリントプランニングに参加したがらない理由を聞いてみます。
また、スプリントプランニングはそのスプリントでのゴールを設定し、チームとして方向性やタスクの詳細の認識を合わせる重要なイベントであることを伝えようと思います。
その上で、プランニングの進め方を工夫できたりしないかチームで会話してみるように促してみるなど働きかけることを検討しようと思います。
26: チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか？
全チームにスタンドアップを薦めようと思います。
チームの状況をきちんと共有して置くことはなにか良くないことが起こっていたりした場合に気づきやすくなりますし、場が最初から設けられていることで、相談のために時間をセッティングするといった心理的ハードルも下げるとができると思います。
ただし、チームのサイズや経験度合いに応じて進め方などは工夫したほうがいいと思います。
一人ひとりが簡潔に状況を共有したとしてもサイズの大きいチームだと時間がかなりかかりますし、
経験が浅いチームの場合はティーチングをしながら徐々にチームになじませていく必要があると思います。
27: なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか？
次のスタンドアップを待たずに、困りごとをチームに共有するのがよいと思います。
課題を”チームごと”と捉えるのがスクラムではポイントだと考えています。その点で、”チームの課題は”早めに共有して解決してしまうに越したことはないと考えるからです。
スタンドアップは定期的に状況を共有する場を設ける意味ではよいと思うのですが、逆に次のスタンドアップまで情報を保持したままにしてしまうことにもつながる可能性があるので、ここは少し注意点かなと個人的に考えています。
28: スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか？
スタンドアップの目的を聞いてみようかなと思います。あとは、「スタンドアップをどういう時間にしたい？」と聞いてみるとかでしょうか。
集まって会話するのだから、状況もそうですし直面している課題を解決したいと考えてるメンバーもいるかも知れません。
あくまでスタンドアップも１つのプラクティスであると考えると、そもそも不要なものかもしれませんし、まずは意見を聞いてみます。
29: スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか？
まずは、「スタンドアップはどういう目的の時間で、なぜ実施したいと考えているか」を伝えた上で、当人が「重要でない」「無駄」と考えている理由を聞いてみます。
もしかしたらスタンドアップがうまくできていないせいで、実際にもったいない時間の使い方をしているかもしれません。
そんなときは、「スタンドアップはどういう風にやりたい？」といった問いかけから、目的ややり方を工夫してみてもいいかもしれません。
30: スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか？
いくつかパッと思い浮かんだレベルですがいくつか案を上げてみます。
-スタンドアップを知っているがステークホルダーが参加してくれていない場合-
少し強引な方法もあるので、実際にステークホルダーが参加できそうな状況であるかは配慮する必要があると思います。
- スタンドアップ前日に次の日のスタンドアップの予定をステークホルダーにアナウンスする
- 名指しでステークホルダーを呼ぶ
- ステークホルダーがスタンドアップに参加してくれると、チームがどう嬉しいかを伝える
-ステークホルダーがスタンドアップを知らない／忘れている-
- スタンドアップに参加してほしい旨アナウンスする
まとめ
私のチームだと30分フラクタルスプリントを実践しているため、もしかしたら２週間といったより長いタイムボックスでの活動されている方とは感じ方や考え方が違う部分もあるのかなと思いました。
逆に、「30分フラクタルスプリントをしている人はこんな風に考えたりするんだぁ」と興味を持ってもらえたらそれも嬉しいです。
では次回は最終回の第４回です。
乞うご期待！