スクラムは「気付いてもらう」とうまくいく、と気付いた話

こんにちは、コミューン株式会社でスクラムマスターを担っているヤマシタ(@yama_sitter)です。

前回「スプリントの属人性を減らしたらベロシティが安定した話」という記事を書きました。
この記事で紹介した取り組みに至るまでの過程に興味がある、という声を頂いたので、その過程、及び過程を振り返って得られた気付きを紹介させて頂きます。

ちなみに少し長いです。
ご了承下さい。

まずは結論から

  • 取り組みに出会えたのも上手くハマったのも正直偶然
  • ただそれらをメンバーが「必要」と感じてくれるよう、「気付いてもらう」ことが重要だった
  • 気付いたメンバーは勝手に良くしていってくれる
  • まぁ色々考えすぎず、とりあえずやってみよう

取り組みの出会いから定着に至るまで

「WIP制限の導入」に至るまで

出会い

  • 元々、前回記事で書いたような属人性の問題、加えて以下のような問題を抱えており、改善に苦戦していた
    • 機能しないSBL上の優先順位と長いリードタイム
    • コードレビューの長い待ち時間
  • 定期的に改善提案やメッセージを発信し続けるも大きく変わらず
    • この時は「何で分かってもらえないんだろう?」と独り悶々としていた
  • 試行錯誤していたころ、RSSか何かで流れてきた「スクラムチームを超生産的にするためのパタン・ランゲージ」という記事を読み、スウォーミングに出会う
    • 「属人性や優先順位といった諸問題が一気に解決できるんじゃないか?!」とテンションがブチ上がる
  • 開発メンバーに記事をシェアし「これ面白そうじゃない?!」と伝えるが、やはり大きな反応はもらえず

導入

  • ある時、殆どのストーリーが仕掛中のままスプリントが終了する事態が発生
    • 元々抱えていた問題が全て重なったような状態
    • 特に以下の点を危惧
      • そもそもユーザーに価値を届けられていない
      • 「全体の進捗が悪かった」ことは理解しているが、「自分の担当ストーリーが何故仕掛中で終わったのか」の詳細は理解し切れていないメンバー
    • これらの問題の解決策として、改めてスウォーミングを提案することを画策
  • このスプリントのレトロスペクティブで強い気付きを得られるよう、「何をやったか」以上に「何が起きたか」にフォーカスできるような手法を導入
    • 手法を「Fun Done Learn」から「タイムライン」に変える
    • 加えて「タイムライン」ボードの背景をバーンダウンチャートに設定
  • メンバーがレトロスペクティブで「何が起きたか」を理解したタイミングで、改めてスウォーミングを提案
    • 全部終わらないより1つずつ終わらせたくない?」「協力しあって特定のメンバーへの依存を減らせるかも」「2週間やってみて、駄目だったら変えたらいいよね!」といった形でメッセージング
    • 前回提案した時は特別興味を示さなかったしていたメンバーも「面白そう」と興味を示してくれる
    • まずは小さく始めるため、WIP制限だけ切り出して試してみることに

定着

  • WIP制限を入れたものの、最初から優先順位やリードタイムといった問題の解決には寄与せず
    • これまでと違う考え方であり、スクラムマスター含め探り探りの状態だった
  • しかし次のレトロスペクティブの際、スプリント途中で休んでいたメンバーから「自分がいない日でも回っていた!」といった声が挙がる
    • 問題の1つである「属人性」解決の1歩には繋がった

レトロスペクティブで挙がった意見

  • メンバーから要望もあり、次以降のスプリントでも継続してみることに
    • メンバーもWIP制限というプラクティスに慣れ始め、明確に優先順位やリードタイムといった問題が解決され始めた
  • 確実に結果に繋がることを全員が理解し、基本プラクティスとして定着する

「タスクサイズの制限の導入」に至るまで

出会い

  • これも前回記事で書いたような、以下の問題を抱えていた
    • タスクが大味且つプロセスでカットされるケースが多く、ものによって3日以上は平気でかかる
    • 予想外のことが発生した場合でも検知しづらい
  • スクラム関連の書籍や記事から「タスクサイズは2h以内にしてみるといいよ」というTipsを獲得
    • 思考停止で「なるほど!」となる
  • メンバーに提案するも、「2hは難しい、半日なら」といった意見をもらう。そのため一旦半日でスタート
  • ただ「メンバーがお気持ちで頑張る」以上のものではなく、浸透せず
    • 以降は地道に「サイズが大きくリスクが高そうなタスクにツッコミを入れる」を繰り返す

導入

  • とあるスプリントで盛大に失敗
    • 状況的にはWIP制限を提案したスプリントに近かった
  • レトロスペクティブでメンバーから「進捗が良いか悪いかのヘルスチェックができていない」という声が挙がる
    • 議論のフェーズでは特にここにフォーカスして話すようにファシリテーションを実施
    • 結果、以前から提案していたタスクサイズの話が再浮上し、改善アクションとして取り入れられる

レトロスペクティブで挙がった意見

定着

  • やっぱり抜け漏れラッシュ
    • タスクサイズの重要性を再認識したはいいが、これまで同様「お気持ち」の改善アクションでしかなく、人に依存しているため時折抜け漏れる
    • Jiraで滞留タスクをチェックするフィルターを作り口頭で共有するも、フィルターの存在が忘れ去られる
  • 自分がメンバーだったら、どうすれば忘れず、自ら気付くことができるか」を自問自答
    • 試しに毎朝利用されるデイリースクラム運用ドキュメントのフローの項に、「スプリントゴールを達成できるかを検査する」という見出しを追加してみることに
    • そしてそこにJiraフィルターのリンクを貼る
  • 以降は自然にデイリースクラムのルーチンに組み込まれて定着
    • やっぱり「お気持ち」では駄目で、如何に自然に気付けるか、が重要と理解
    • 要は、既存の仕組みの中に入れるのがいいよね、というお話

「死亡前死因分析(プレモーテム)の導入」に至るまで

出会い

  • あるスプリントの開始後に、幾つかのストーリー配下のタスクがどんどん増えて肥大化する状態に
    • 進捗しないストーリー、動かないバーンダウン
  • 試しにあるメンバーに「実際、今回の計画に自信を持てている?」と聞いたら「実はそこまで自信が無い」という返事をもらう
    • 「このスプリントは失敗しそう…」と予期
    • 計画に自信がないのにコミットメントも何も無いわけで…
  • 計画に自信を持ち強くコミットメントできるようにするにはどうしたらいいか?を考え続ける
    • 「スプリント 計画 失敗 分析」といったワードで調べた結果、「スクラムチームを支える心理学 - 死亡前死因分析」という記事に辿り着く
      • ここで死亡前死因分析を知る
    • ただ既にスプリント中盤だったため、メンバーにシェアだけして一度寝かせることに
    • ここでもシェアしたものはSlackメッセージの波に流され消えていった

提案

  • 予期した通りにスプリントが失敗
    • スウォーミングの時と同様、この問題の解決策として改めて死亡前死因分析を提案することを画策
  • メンバーに「計画に自信を持つためにはどうしたらいいか?」への解を持ってもらうため、そのスプリントでのレトロスペクティブのテーマを「チーム全員が計画に対して自信を“持ち続ける“ために何ができるか?を考える」に設定
    • 強めのテーマを置いたことで、メンバーも強く計画についての課題感を持ってくれた(と思っている)
    • そこで改めて死亡前死因分析について共有。「面白そうだし、試しに次回スプリントの最初にやってみない?」と伝え、ラフに実験してみることへの合意を得る

定着

  • 次のスプリントの開始前に死亡前死因分析を実施
    • なるべく楽しいと感じられるよう、大喜利のような失敗要因も拾ってテーブルに乗せる
    • メンバーからは「楽しかったし、やってみて良かった」といった声が挙がる
  • この後はタスクが増え続けることも無く、加えて事前にリスクヘッジもできていることから安定してスプリントが進む
  • レトロスペクティブにて「スプリントの出だしが良かった要因」の1つとして名前が挙がる
    • 以降はメンバーの方から「やりたい」と声が挙がるようになり、サイクルに加えることに

レトロスペクティブで挙がった意見

改めて振り返ってみて

「知識差・温度差がある中で提案やメッセージングだけを繰り返す」のはイケてなかったな、と痛感しました。
スクラムマスターに知識や観点、一定以上の熱量があるのは当然ですが、それをそのまま開発メンバーが飲み込めるかというとそんなことはありません。

ただこのステップを経て内省を繰り返した結果、「気付いてもらう」というマインドにシフトできたと感じています。
そしてそこからメンバーが気付き、意思決定したことで、改善の一歩を踏めたのだと確信しています。

また少しズレますが、過去の自分は慎重過ぎて何もできていなかったとも思います。それこそ「改善提案やメッセージング」で終わらせず、ガッと新しい取り組みを推し進めても良かったなぁ、と。
チームのアジリティを高めようとしているのに、当のスクラムマスターのアジリティが低い、なんて状況で物事が進む訳がないですね。反省。

まとめ

取り組みに出会えたのも上手くハマったのも正直偶然

  • 取り組みに出会ったのは本当にたまたまです
    • スクラムの改善に使えそうな情報を収集し続けており、その中の1つがハマった、という感じです
  • 取り組みを明確に「導入しよう」と思ったことはありません
    • 状況を観察し、引き出しから幾つかの道具を出して試してみただけです

「気付いてもらう」ことが大事。最後に決めるのはメンバー

  • 気付いてもらう = メンバーが「自分自身で状況を理解し、意思決定できる」ためのキッカケを提供すること
    • 気付いてもらう ≠ 提案すること、メッセージングすること
  • メンバーが気付けそうなタイミングを逃さない
    • 「失敗は成功の母」と言いますが、実際失敗が大きい時ほど気付きと改善のチャンスです
    • いいタイミングで引き出しから道具を提供したら、あとはメンバー自身が勝手に使って良くしていってくれます

「とりあえずやってみよう」くらいの気持ちで改善に取り組もう

  • 1スプリントは多くが1~2週間、何かあってもリカバリーできます
  • チームだけでなく、スクラムマスターも「とりあえずやってみよう」を忘れずに
    • (これは自戒も含みます)

最後に

コミューン株式会社ではエンジニアを募集中です! カジュアル面談もできますので、記事を読んで弊社のスクラムに興味を持ってくれた方、是非気軽に応募してみて下さい!

commmune-careers.studio.site