スクラムマスダーの日記

アジャイル、スクラムに関連した内容が多めです。

スクラムフェス札幌(0日目)に参加しました! #scrumsapporo

2020/11/05から3日間に渡って開催されるスクラムフェス札幌に参加しました。

www.scrumfestsapporo.org

初日である0日目の参加報告ブログです。

スクラムフェス札幌は、オンラインで行われることもあり、自宅PCからの参加です。 ちょうど夕ご飯の時間帯ということもあり、食卓にPCを置いて、ご飯を食べつつ、見ていました。

妻(エンジニアどころかIT業界でもない)も一緒に見させていただき、ワイワイ見るのは、なかなか面白い体験でした。(チケット1人分しか買ってないけど、家族だし、"アーカイブの閲覧は参加者含んでいればOK"とあったので、閲覧は許してください!)

オープニングトーク

地域に「解」はあるという言葉が、本当に心に響きました。

いま、色々と仕事を探している最中の身なのですが、やはり圧倒的に仕事自体が、東京を含む関東圏に存在していると感じています。
だからこそ、東京でしかできないことが多くあるように感じます。

しかし、「本当に東京でしかできないのか?」というと、異なるように感じます。
僕は、大阪という、東京と比較すると、地方都市に暮らしています。
色々なコミュニティに参加すると、実践者は、数は少ないですが、いらっしゃいます。
地方ならではの悩みを共有できたりもするのです。

ちなみに、イクラ丼のお店が紹介された時、妻と「おいしそうだね〜。札幌行きたいね〜。」と言ったりしてました。

hachikyo.com

紙粘土スクラムから得たアンチパターン

紙粘土スクラムについては、登壇者である根本さん、Shodaさんから、お話を聞かせていただいことがあるだけで、実際に取り組んだことはないのですが、「あ〜、あるだろうな〜」という感じで聞いていました。

妻から「スクラムって、なに?」、「スクラムマスターって、開発の人に指示する人なの?」といった、質問を受けつつ、回答しつつ、見てました。

スクラムマスターアンチパターンで紹介されていたShokunin Masterの際に、「集中しすぎて、他のことに気が回らないって、あなたのことやん」と妻から言われたとき、「おいおい、僕がスクラムマスターを専門にしたいと思ってるところに、ピンポイントでアンチパターンに合ってるところ突っ込んでくるな!」と思いました…。するどい…。

妻は、スクラムはもちろんIT関連も全然知らないのですが、一緒にセッションを見ていて、こっちが気付かされること多いな〜といった感じでした。

プロダクト生存戦略 : スクラムギャザリング東京の10年から学ぶ

Regional Scrum Gathering Tokyoの歴史をふりかえる話をされていました。
完全に深夜ラジオだったので、おもしろ、楽しく聞きました!

ただただ、おもしろかったです!

おわりに

妻と一緒にスクラムのカンファレンスに参加するとは思ってなかったですし、実際に参加してみると良かったなーって思いました。
あと、札幌土産が宅配で届いたので、妻と一緒にお菓子を食べながらというのも良い体験になりました。(運営の皆様ありがとうございます!)
f:id:scrummasudar:20201105203140p:plain

スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみた

「SCRUMMASTER THE BOOK」を読んで、改めてスクラムマスターについて考えることが多くなりました。

考えているうちに、以前ryuzeeさんが紹介されていた「スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみた」を思い出しました。

自分が今思うスクラムマスター像を言語化することが大事だと考えたので、38個と数は多いですが、回答してみました。

私の回答

スクラムマスターの役割について

アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか?

そもそもスクラムマスターは、スクラムチームや関係者に対して単にプロセスを守らせる役割ではないと考えています。
スクラムマスターはスクラムチームや関係者の状況によって、振る舞いは変わります。スクラムチーム立ち上げ時やチームとして機能していないときには、型としてのプロセスを守らせることを優先する場合はもちろんあると思います。
しかし、そこにはスクラムチームとの対話があり、プロセスを守ることが現状では大事だと、皆が認識している状況を生み出すということです。 自己組織化がなされ自律的なチーム、組織であれば、プロセスは幾度となく改善されると思います。既存のプロセスを守ることは、むしろ改善の妨げになるでしょう。その改善を行うためにも、対話が必要だと考えています。

自分の組織でアジャイルがうまくいっていることを示す兆候は何か?また自分の働きが成功している兆候は何か?

自分の組織でアジャイルがうまくいっていることを示す兆候は、ビジネスといってうまくいっているかです。
ビジネスのフェーズによって、利益、売上、ユーザー継続率、ユーザー数など指標はあると思いますが、その際に定めた指標に対して、どれだけ達成できているかだと考えています。
そのビジネス指標を達成するための方法として、アイデアが出てからリリースされるまでのリードタイム・リリース回数が挙げられます。
また、従業員側が納得して継続的に働いているかを示す従業員満足度や勤続状況(残業時間、退職率など)も重要だと考えています。

自分の働きが成功している兆候は、チームや組織が自律的に動き自身のやることが減ってきて、チームや組織が成果が出せている状況だと思います。また、同時、自身が組織の中でよい評価をされているかも大事だと考えています。

追跡しないといけないメトリクスはあるか?もしそうだとしたら何の目的でどのメトリクスを追跡するか?

上記の「自分の組織でアジャイルがうまくいっていることを示す兆候」で回答した内容です。
やはりビジネスに関するメトリクスが最も重要だと考えています。

あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか?そして問題をどのように指摘するか?

考えられる理由としては、以下の通りです。

  • プロダクトバックログアイテムが大きすぎる
  • プロダクトバックログアイテムがReadyではない
  • プロダクトバックログアイテムの量が多すぎる
  • プロダクトバックログアイテム外の作業をする必要があるorしてしまっている
  • プロダクトバックログアイテムを取り組むにあたって必要な技術要素や業務知識が不足している

問題をどのように指摘するかですが、直接指摘するというよりは、スクラムチームが自律的に改善できるような場を作り、考えてもらうようにします。
なかなか話題に出ない場合は、スプリントプランニング、スプリントレトロスペクティブ、リファインメント、デイリースクラムなどの機会を通して、この状況をスクラムチームがどのように考えているかを問いかける質問をします。

製品のディスカバリープロセスにスクラムチームは参加してよいか?その場合はどのようにするか?

スクラムチームは参加した方がよい、むしろ参加すべきと考えます。
特にプロダクトオーナーは、プロダクト責任者であるので、ディスカバリープロセスに入っていなければ、何をユーザーに届けるのかを知ることができないため、必須だと考えます。
開発チームも、ユーザーが求めているもの、ユーザーの解決するべき課題をディスカバリーの段階から知っていくおくことで、自身に求められていることをより深く理解できると考えています。

設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか?

仕事をプロダクトオーナーにしかできないこと、プロダクトオーナー以外でもできることに分類し、プロダクトオーナー以外にもできることを開発チームやその他関係者に対応してもらいます。
プロダクトオーナーの最大の決定は、プロダクトバックログの優先順位です。個々のプロダクトバックログアイテムの内容は、プロダクトオーナー自身が詳細まで決定する必要はないので、色々な方にフォローしてもらえるような状況を生み出すことが大事だと考えています。

どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか?

できればプロダクト立ち上げ時やスクラムを取り入れるタイミングで、ステークホルダーに関与し、協力してもらうことをお願いしに行きます。もし、関与、協力いただいてない場合には、速やかに依頼することが重要だと考えます。
ステークホルダーも(むしろステークホルダーの方が)ビジネスの成功を考えているので、そのために共に協力し合える関係作りが重要だと考えます。

単にアクセスできるだけでは、プロダクトオーナーの決定を覆す状況を生み出します。 アジャイルスクラムの考え方を知らない場合もあるので、どういう関わり方をして欲しいのかを伝えることも重要だと考えます。

どのように複数の異なる部門にまたがってアジャイルマインドセットを広げるか?ITじゃないステークホルダーをコーチするのにどんな戦略をとるか?

ITに関わりがあるかに関係なく他の部門に対して、自分たちが各部門の抱えている課題を解決する手段を持っていること、そして実際に成功していることを示します。
事例は他の部門が理解するには非常に重要なので、社内で、実際に、アジャイルな取り組みで、ビジネスが成功していることを示すことができるように取り組みます。
成功することで、徐々に他の部門からも注目が集まるでしょう。
その後は、外部コーチを招聘してトレーニングを受講してもらうなど、社外の力を借りていくことも必要だと考えています。

上級管理職にどのようにスクラムを紹介するか

スクラムは、単にITのプロダクトを開発するための仕組みではなく、不確実性の高いビジネス状況において有効な手段であることを説明します。
社内の人間による説明だけで納得してもらえない場合は、社外のアジャイルコーチに協力してもらう、各種団体のトレーニングを受講してもらうなどの方法も必要だと考えます。

あなたはすでにステークホルダースクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか?またどんな経験があるか?

自身において、激しく抵抗された経験はないが、どのような戦略かは、対話しかないと考えます。
新しいことに取り組むこと、今まで異なることをすることに、抵抗を感じるのは人間であれば、誰しもあることです。
いま、抵抗する同僚が、どんなことを感じているのか、どういう風に考えているのかを対話を通して知り、解決できることであれば、協力していくことが重要です。
最終的に解決できない場合は、チームから外れてもらうことも選択できることを知ってもらうことも重要です。心身を害してまで、スクラムに取り組んでらう必要はありません。

プロダクトバックログのグルーミングと見積りについて

プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか?

よいと思います。
ただし、プロダクトバックログアイテムに落とし込むのは、ステークホルダーからの要求だけではありません。プロダクトオーナー自身のアイデア、開発チームからのアイデア、ユーザーから得たアイデアなど、様々な場面で発生するアイデアが、プロダクトバックログアイテムになります。
仮に、プロダクトオーナーがステークホルダーの要求のみをプロダクトバックログアイテムに落とし込んでいるのであれば、名前だけのプロダクトオーナーになっています。ステークホルダーがプロダクトオーナーに就いていただく必要があるでしょう。

また、開発チームが見積ることは大事ですが、プロダクトバックログアイテムに落とし込む前に、真に落とし込むかどうかを見極めることも重要です。見積ること自体もコストです。前段階で開発チームが関わることで、見積らなくてよい状況を作り出すことも大事です。

チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか?

プロダクトオーナーには、ビジネスにおける重要な指標を示してもらうようにします。(指標の例は、「自分の組織でアジャイルがうまくいっていることを示す兆候」で回答した内容です。)

また、チームが、そういった情報をプロダクトオーナーから伝わってくるのを待っているだけの状況は、チームが機能していないサインです。チームが、最新情報やマーケット状況を自主的にプロダクトオーナーはもちろんステークホルダーやユーザーからも取りに行くようなチームが理想的です。

誰がユーザーストーリーを書くとよいか?

スクラムに関わっている方であれば、プロダクトオーナー、開発チーム、ステークホルダー、経営層、協力してもらえるのであればパイロットユーザーなど、誰が書いてもよいです。

よいユーザーストーリーとはどんなものか?どんな構造か?

INVESTを意識して書いたプロダクトバックログアイテムがよいです。INVESTとは、以下の内容です。

  • Independent…独立している
  • Negotiable…交渉可能
  • Valuable…価値がある
  • Estimable…見積り可能
  • Sized Right…適切なサイズ
  • Testable…テスト可能

他には、誰が利用してくれるのか、ビジネス的にどれくらいのインパクトがあるのかといった項目もわかると、更に良いと思います。

「Readyの定義」には何が含まれているべきか?

開発チームが、プロダクトバックログアイテムを取り組んだときに、スプリント内で完了できると想定可能であることが重要です。

一例にはなりますが、プロダクトバックログアイテムの受け入れ条件が明確であること、開発チームが見積っていること、1スプリント内で収まるサイズであることなどが、具体的な項目になると考えています。

ユーザーストーリーを時間で見積もらないのはなぜか?

スクラムガイドではプロダクトバックログアイテムに対して見積りをする必要がある旨は記載されていますが、時間で見積ってはいけないとは書かれていません。時間見積り、相対見積り(ポイントを利用した見積り)は、それぞれのスクラムチームにおいて、選択できます。

時間で見積った場合の懸念点としては、開発メンバーにはスキル差があり見積った時間どおりに開発できるとは限らないこと、この時間内に終わらせればよいと考え早く終わらせるという考えから離れていくこと(パーキンソンの法則)、開発チームで見積った時間がそのままプロダクトの計画と同一視されてしまい関係者との認識がずれていくことなどが挙げられます。

相対見積りを行う場合、時間見積りより早く見積ることができるメリットがあります。具体的な単位で正確に計測しようとする行為より、特定の作業と比較する行為の方が、素早くできます。

プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか?スクラムチームは200個のチケットに取り組めるか?

あとから色々なアイデアを出すこと自体は、歓迎されることです。市場の変化、ユーザーの事情などによって、プロダクトに必要な項目は変化するからです。
200個のアイデアが出てくれば、プロダクトバックログアイテムを200個作り、既存のプロダクトバックログアイテムとともに、優先順位を付けて、上から順に実装していけばよいです。

また、すべてのチケットに取り組む必要があるとは考えていません。上記の通り、過去思いついたアイデアであっても、今プロダクトに必要な項目とは異なる場合があります。
特にアイデア出しから時間が経過しているプロダクトバックログアイテムについては、将来本当に必要なのかを考え、不要なプロダクトバックログアイテムは、リストから除外することも必要です。

スプリントプランニングについて

チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか?

スプリントプランニングの段階で、プロダクトバックログの優先順位が上のアイテム(最低限、今スプリントにおいて開発対象に入るアイテム)について、プロダクトオーナー及び開発チームの認識が揃っている状況を作ります。

そのためにも、プロダクトバックログリファインメントを活用することが重要だと考えています。 なぜこのプロダクトバックログアイテムを開発する必要があるのか、各プロダクトバックログアイテムを開発した時ユーザーにはどういう価値が感じられるのかなど、アイテムを開発する理由、目的、価値をプロダクトオーナーが考え、開発チームと共通認識を持っていることが大事です。

そうすることで、スプリントプラニングについては、なぜこの順番で実装する必要があるのかという議論に注力できます。優先順位を並び替えることで、より早くユーザーに価値を届けることができる場合もあるので、開発チームとプロダクトオーナーが対話できる場作りも大事だと考えています。

ユーザーストーリーの価値をどんなメトリクスに基いて判断するか?どんなメトリクスは受け入れがたいものか?

ビジネスにおけるインパクトを用いて判断します。インパクトの判断基準は、「自分の組織でアジャイルがうまくいっていることを示す兆候」に回答した内容が例になります。

受け入れがたいメトリクスとしては、社内政治に関わるような内容です。「○○部門からの要求を□□個含んでいること」といった、社内の政治バランスを考えて行うプロダクト作りは、真にビジネス価値を達成できるメトリクスではなく、ユーザーに価値を届けるとはかけ離れているメトリクスだと考えています。

チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか?

プロダクトバックログアイテムを上位から順に選択する際に、開発チームが、自分たちがどれくらいだったら出来るかを自分たちで判断することを促します。

ただし、過去のベロシティと比較して、多すぎる場合や少なすぎる場合は、開発チームに、その理由を確認します。
少なすぎる場合は、開発対象となるプロダクトバックログアイテムを追加する場合もあります。
逆に多すぎる場合は、開発対象となるプロダクトバックログアイテムをスプリントから外すように促します。この場合、プロダクトオーナーから減らさないようにする要請があると思いますが、スプリント予定していたプロダクトバックログアイテムを予定通り完了できていないことが連続している場合には、実際に開発できる量を認識してもらい、予定していたものが終わる状況に、まずなるようにプロダクトオーナーを促します。

どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか?

重要なバグの修正(ビジネスにクリティカルなダメージを与える内容を想定)については、原則実施するべき事項と考えています。そのため、適切な時間という考え方は持っておらず、必要な時間をかけるべきだと考えています。
他の新機能を追加するプロダクトバックログアイテムより重要な場合もあるでしょう。

リファクタリングや新しい技術やアイデアの調査は、やっていない状況も良くないですし、時間の半分以上を使っている状況も良くないでしょう。
10%から20%程度は使った方がよいと考えていますが、プロダクトやチームの状況に左右される数字だと考えています。

チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか?

プロダクトオーナーに対して、なぜ個人に割り当てようとするのかを、質問します。

プロダクトオーナーが個人に仕事を割り当てることこそが仕事だ、重要だ、と考えている場合は、開発チーム自身が決めることが重要だと伝えます。仕事を効果的にすすめるためには、自分たちで決めることが重要だと伝えます。個人に割り当てた場合、個人の最良に任されてしまうので何も出来上がらないスプリントになってしまう可能性があることも伝えます。

一方、開発チームが、プロダクトオーナーと接するメンバーを固定しているのかもしれません。そういった場合、プロダクトオーナーが特定の個人に仕事を任せるのは容易に想像できます。この場合、振る舞いを変える必要があるのは開発チームです。特定のメンバーのみが仕事をすることによる弊害(トラックナンバーが1だと、休んだりすると仕事が全く進まなくなるなど)を伝えて、改善するようにしてもらいます。

チームメンバーによるタスクのつまみ食いをどのように扱うか?

タスクのつまみ食いにより、プロダクトバックログアイテムの優先順位の高い順に取り組むことができていない、途中まで作った仕掛品ばかりで完成したプロダクトバックログアイテムがない、得意なタスクばかり取り組むメンバーがいて手が空いたときに他のタスクには取り組んでくれない、が発生している場合は、対処する必要があると考えます。

開発チームには、ふりかえりなどで、上記のが問題であることを認識してもらい、改善するように促します。 WIPを制限し仕掛るタスク数を制限すること、ペア作業やモブ作業で取り組む方法が効果的だと考えています。

「新しいことにチャレンジングしてみたけど、現状ではハードル高くて、ちょっと無理だった…。」のように、結果としてつまみ食いになった可能性もあるので、つまみ食いの結果で、どのような問題が発生しているかに注目する必要があると思います。

ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか?

Readyなプロダクトバックログアイテムとは言えないので、次のスプリント以降に回してもらうことを、プロダクトオーナーには提案します。

とは言え、それだけ重要で優先順位の高いプロダクトバックログアイテムであれば、スプリントを中止する選択肢も残して、プロダクトオーナーと開発チームが一緒になって、Readyなプロダクトバックログアイテムにする必要があると考えます。

スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか?

「なぜ参加したくないのか?」、「どういった内容を時間の無駄と捉えているのか?」を質問し、それらの回答に対して、これからどうするかを一緒に考えていく必要があると思います。

スタンドアップやデイリースクラムについて

チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか?

基本的に薦めます。

同一ロケーションにいる少人数のチーム(4人以下を想定)であれば、話す人数が必然的に限られるので、薦めずとも、実際にはスタンドアップが行われる状況だと思います。

ロケーションが離れているチーム、大人数のチーム、複数のチームが関連する場合には、スタンドアップを薦め、相互に連携できるような状況を意識的に作ってもらいます。

なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか?

待つよりも、随時助けを求めるチームが良いと考えています。

とは言え、助けを求める方の都合だけではなく、相手側である助ける方の都合もあるので、随時が常によいとは限らないです。
スタンドアップが、一日に数回行われているのであれば、両者の都合を付けやすいスタンドアップで助け合うことも、一つのやり方だと思います。

スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか?

報告セッションにしてしまうような方に対して、デイリースクラムの目的を改めて伝えます。
デイリースクラムは、特定の誰かに報告する場ではなく、チームとして、状況を確認したり、問題が発生していないかを確認する場です。

開発メンバーをリードするメンバーが該当する場合は、デイリースクラム時の立ち位置を他のメンバーより後ろに立ってもらう、他のメンバーに司会を担当してもらい報告する立場を体験してもらうとよいです。

プロダクトオーナーやスクラムマスターが該当する場合は、上記の対応に加え、あえてデイリースクラムに参加しないといったことも検討します。

スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか?

デイリースクラムが遅刻や欠席する方に対して、「なぜそういった行動を取るのか?」を質問してみます。
質問を通して、デイリースクラムの意義を伝え、遅刻や欠席することになる妨害事項が取り除くことができないかを確認します。

働き方や時間帯によって参加できない場合は、全員が集まることができるタイミングに実施するようにします。
デイリースクラムは朝会と称され朝時間帯にすることが多いですが、必ずしも朝に実施する必要はありません。

デイリースクラムが遅刻や欠席する方の行動が変わらない場合は、スクラムチーム内で相談し、スクラムチームから外れてもらうことも検討します。必ずしも、同じチームで働き続けることが良いとは限りません。

逆に、誰かに報告するだけの場になっている、単に雑談だけで仕事に関する話が一切行われないなど、無駄になっている場合もあります。そういった場合は、日々出席しているメンバーに対して、「いま、どういうことを感じて参加しているのか?」を質問し、デイリースクラムの目的に沿って実施されるように、改善を促します。

スクラムチームのスタンドアップステークホルダーは誰も参加していない。この状況をどのように変えるか?

デイリースクラムは、開発チームのためのイベントなので、ステークホルダーが参加する必要はありません。

ステークホルダーが参加して、スクラムで実施する開発内容に対して細かく指示を出したり、スクラムで取り組んでいる以外の仕事を指示するような事態になっている場合には、ステークホルダーが参加しないように促します。

分散チーム間のスタンドアップをどのように進めるか?

Zoomなどのビデオ会議ツールを利用して、出来る限り顔や声を使って、やり取りするように促します。
それも難しい場合には、Slackなどのチャットツールで、やり取りすることを勧めます。

スクラムチーム用の物理カンバンボードをいま書いてください

カンバンを導入する時点では、"TO DO"、"DOING"、"DONE"の3レーンでカンバンを作ります。

あとは、スクラムチーム内で、スプリントレトロスペクティブなどを通して、改善していきます。

ふりかえりについて

だれがふりかえりに参加してよいか?チームだけか?プロダクトオーナーも参加してよいか?

スクラムチームが参加してよいので、開発チーム、スクラムマスター、プロダクトオーナーの3者が参加します。

もちろん必要であれば、ステークホルダーに参加してもらいましょう。

チームが健全な状態かをふりかえりの中で確認するか?それとも不要か?もし必要だとするとどうやって確認するか?

チームの状態は常に確認するが、特にふりかえりは注目して確認する。

スクラムチームのメンバーの話す内容、話し方、行動、情動などで確認することができます。

過去に使ったふりかえりのフォーマットはどんなものか?

KPT、YWT、タイムライン、スターフィッシュ、Continue/Stop/Start、Fun/Done/Learn、Good/Bad、Mad/Grad/Sad、ファイブフィンガー、感謝の手紙などなど。

雑談して終わる場合もあります。

どうやってマンネリを防いでいるか?

手法自体が問題でマンネリ化することは、少ないと思います。

マンネリに感じている場合、ふりかえりをやっているにも関わらず、アクションが実施されず、改善されている実感できないということが多いと思います。 ふりかえりのアクションを出来る限り小さくし、スプリント内で実施し、少しでも変化を感じてもらうことを優先します。
変化だけでなく、改善したと実感してもらえると最高です。

チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか?

実際に行動できていないのであれば、妥当なアクションアイテムを選択できてない、と考えました。

アクションアイテムがスクラムチームの課題に合っていたり、解決を見込める内容であっても、期限が決められていない、サイズ感が大きすぎて取り組みづらい、技術的にスキルが足りず学習期間が必要、といったことが想定されます。

スプリントレトロスペクティブで、なぜ実際に行動できていないのか、開発チーム内で原因を考える必要があります。

もし単に実施することを忘れている場合であれば、スプリントバックログの計画時に、アクションアイテムを計画内に入れます。(スクラムガイドに沿った方法です)
カンバンを利用して、スクラムチーム内で見える化に取り組むことも良いと思います。

どうやってアクションアイテムのフォローアップを薦めるか?

スプリントバックログの一つとして捉えるので、デイリースクラムで実施状況を確認するのがよいです。
デイリースクラムの話題に上がらないようであれば、状況を確認してみます。

おわりに

書き始めてから、全部書き終わるのに3週間ほどかかりました…。38個は、なかなか多いですね…。

書いてみたことで、自分のスクラムマスターのスタイルを知ることができたように思います。

数年後に、再度書いてみると、考え方の変遷もわかって、面白いようにも思います。

僕は現役のスクラムマスターではないですが、ぜひ現役のスクラムマスターの方にも考えてほしい内容だと思いました。

他に回答した方のページ

他にも書いた方が、多くいらっしゃるので、ぜひ他の考え方にも触れてみてください。

www.ryuzee.com

medium.com

qiita.com

takaking22.com

enk.hatenablog.com

www.membersedge.co.jp

note.com

「SCRUMMASTER THE BOOK」を読みました!

タイトルの通りではありますが、2020/09/09に発売された「SCRUMMASTER THE BOOK」を読みました。

スクラムマスターとは、どういう存在なのか?どういう役割を果たすのか?」という内容について、丁寧に紹介されており、ぜひ読んでいただきたい本なので、このブログでも紹介させていただきます。

おすすめの対象読者

スクラムをやり始めたけど、スクラムマスターって何やってよいか全然わからない!」というスクラムマスター初心者の方に、ぜひ読んでいただきたいです。
また、会社でスクラムを取り組み始めたばかりで、スクラムについてまだ詳しくない場合は、プロダクトオーナー、開発者、経営層を含むステークホルダーの方にも、読んでいただきたいです。

この書籍は、200ページ強と、ページ数も、それほど多くありません。頑張れば十分週末で読み切ることができる分量です。
一人で悩んでいる方は、ぜひ週末に読んでださい。

アクティブブックダイアログ(ABD)やジグソー法を利用した読書会にも向いている本です。
スクラムに関わる人々で読むことも、よいと思います。

逆に、ベテランのスクラムマスターやアジャイルコーチを何年も経験されている場合は、目新しいことは少ないと思います。
(事実、僕にとっては、「この概念は、全く知らなかった!」と感じるものはありませんでした。)
しかし、"#スクラムマスター道"を始めとする、「こういった切り口で説明することができるのか!」という新鮮さがあります。
ぜひ手にとってみてください。

書籍について

ここでは、もくじの項目で書籍の全体感を紹介します。また、私がこの本で特に紹介したい内容をいくつか記します。

もくじ

本書のもくじは、以下のとおりです。

3章の"#スクラムマスター道"が本書の最もオリジナルな要素です。また、5章の"チームを構築する"は、タイトルは一般的ですが、内容はオリジナリティにあふれており、新しい考え方を提供してくれます。

スクラムマスター初心者の方は、1章の"スクラムマスターの役割と責務"、2章の"心理状態モデル"、7章の"スクラムマスターの道具箱"から、スクラムマスターの役割やどういうスキルを身につけることが望ましいかを知ることができます。

スクラムマスター道

"スクラムマスター道"とは、スクラムマスターの役割を理解するために、偉大なスクラムマスターを3つのレベルで表す概念です。
著者のZuziが提唱した概念です。

3つのレベルとは、以下の通りです。

  • レベル1:私のチーム
  • レベル2:関係性
  • レベル3:システム全体

レベルが上がるにつれて、スクラムマスター自身が担当しているスクラムチームの開発チームから、ステークホルダーを含むスクラムチーム、そして組織全体へと、考える視座があがっていきます。

最終的に、スクラムの理解・定義は「生き方」そのもの、とされています。

また、同じ組織内のスクラムマスター同士の関係においても、他のチームとの関係性を作らなかったり、相手のことを考えずに変わってもらいたいと思うなど、上記の"スクラムマスターの道"のレベル3の考えまで至っていないことがあります。

システム全体を俯瞰する視点から物事全体を考える力や、チェンジマネジメントの経験を積む必要があるとされています。

チームの毒

チームの毒とは、チームや組織を害する行動や状況です。

以下の4つがチームの毒とされています。

  • 非難する
  • 守りの姿勢
  • 壁を作る
  • 侮辱する

スクラムマスターの役割は、4つの毒についてチームに教え、毒に気づけるようにコーチングし、毒を用いず互いに指摘し合えるようにすることです。
議論には多くの毒が含まれているため、少し気をつけるだけで、非常に効果があるとされています。

アジャイルの車輪

スクラムマスターは組人や組織の変化を先導する必要があります。しかし、単に新しいからやるといっただけでは、理由にはなりません。
変化する理由はどういうものであるか?、変化するタイミングとしてはいつがよいのか?といったことをチームで理解するために、アジャイルの車輪という方法を紹介されています。

  • 市場に出すまでの時間
  • チームの健康
  • チームのコラボレーション
  • チーム外とのコミュニケーション
  • 継続的改善
  • 効率性
  • 品質
  • 変化への反応
  • 顧客からフィードバックを得る
  • デリバリーの予測可能性
  • 顧客満足
  • 生産性

この12項目において、現状とそれぞれの期待値の認識を合わせることで、どこに今取り組むべきかをチームで知るきっかけになります。

私の感想

私は、過去数年間ではありますがスクラムマスターとして仕事に携わっていました。
仕事を通して色々な経験をしたり、書籍を読んだり、技術コミュニティに参加することで、この書籍に書かれているような内容にたどり着きました。

この本を読みすすめる中で、「スクラムマスターになったときに、この本が手元にあれば…」と、スクラムマスター時代のことを思い返しました。
スクラムマスターを始めたときに、「スクラムマスターは、どういうことをしていったら良いのだろうか?」と悩んだときに、確認することで、行動が変わったのだろうと思います。
それほど、この書籍には、スクラムマスターの役割や必要なスキルについて、数多く書かれており、知ることができます。

ただ、この本には、それぞれのスキル(傾聴、コーチング、メンタリング、ティーチングなど)については、それほど深堀りされておらず、端的に説明されているのみです。
詳細を知りたいという気持ちはありますが、そこを書いてしまうと、非常に分厚い読みづらい本になってしまうので、あえて書いてないのだろうなと思っています。

端的に書かれているからこそ、サクッと呼んで、指針にすることにできる書籍だと思っています。

おわりに

久しぶりに、読んだ書籍の紹介をさせていただきました。

この書籍を読み終わったあと、「スクラムマスターにもう一度チャレンジしてみたいな」と本当に思いました。
いま、自分がスクラムマスターの役割を担った際に、どういう振る舞いをできるのだろうか?、チームや組織のことをどう捉えるのか?と、思いを巡らせる内容でした。
私にとって、非常にインパクトを与えてくれた書籍になりました。

最後に、宣伝も含んでいますが、訳者の大友さんやAkiさんが運営するコミュニティで読書会もありますので、ご興味のある方は、参加してみることをおすすめします!

kyoaja.connpass.com

scrumdo-kansai.connpass.com