はじめに
「スクラムマスターやらない？」
これが限りないスクラムスパイラルへの入り口だとはこの時思いもしませんでした。
私たちの開発チームではDBのDevOpsチームとして擬似的なカッコ付き「スクラム」を取り入れていたのですが、あくまでスクラムのイベントをこなしていく、といったやり方で、本格的にスクラムマスターを立て、スクラムによる組織変革、開発のアジャイル化、スクラム自体の改善を行うというところまでは到達していませんでした。
この記事では新人のスクラムマスターが半年で気づいたことや、起こった問題、改善の経過をまとめたものになります。何かの参考になれば幸いです。
スクラムについて漠然と思っていたこと
PBI(プロダクトバックログアイテム)をチームメンバーに作成させて進捗管理を行ってスクラムイベントのファシリテーションをこなしていけばいいんでしょ。
こう思っていた時期が自分にありました。実際スクラムマスターを置く前のチームにおける開発のスプリントはそんな感じだったと思います。
スクラムが上手くいかなかった事象と解決策について
スクラムは単なるフレームワーク
「スクラムとは単なるフレームワークに過ぎない」ということをスクラムを始めてから嫌というほど思い知らされることになりました。そのままスクラムを取り入れてもうまくいかない、ということはスクラムのフレームワーク自体の細かい改善が必要ということです。
以下うまくいかなかったこと、それに対する認識を改めたり、改善した出来事になります。
終わらないバックログリファインメント
- とにかくバックログリファインメントが終わらない
スクラムを厳密に適用していくと最初にぶち当たる壁として、時間が全然足りないと言うことはよく聞く話です。我々の組織もその典型に陥ってしまっていました。
特にバックログリファインメントがいつまでたっても終わらず長大になってしまう問題が発生しました。 - 解決策
我々のスクラムは1週間スプリントで行っていたので、スクラムイベントを組み直し、バックログリファインメントを週に2回行うという単純な施策を行いました。
幸いすぐ効果が出たので、とりあえず終わらないという問題は解消しましたが、もし解消しなかった場合には毎日バックログリファインメントを行うということも考えていました。
スクラムの改善策に従ってくれない
- 開発メンバーがスクラム改善策に従ってくれない場合がある
人間は簡単には動かないということもスクラムを始めて思い知らされることの1つでした。
例えばスクラムのアジェンダに改善案を挟み込んだり、バックログアイテムの内容を細かく書くためのテンプレ改修などを行っても実践してもらわなければ意味がありません。 - 解決策
スクラムの内容に「人の動かし方」は全く書いていません。「動かすためには」がほしいならコーチング、ティーチングのスキルが必要になります。
私自身に全くそのようなスキルがなかったので、付け焼き刃ですがいろいろな資料をあたってメンバーとの意思疎通を行うためのテクニックを養いました。
〜アジャイルソフトウェア開発宣言より〜：プロセスやツールよりも個人と対話を
デイリースクラムで進捗に対する障害を発見できない
- デイリースクラムで進捗に対する障害を発見するためにどうするか
デイリースクラムにおいてバックログアイテムの進捗状況を確認するときよく来る返事「問題ありません」これは信用してはいけません。よくよく聞いてみると潜在的な問題が隠れていることが多々あります。
ここは？ここはどうですか？詳しく聞いていくと詰まっているところや、上手くいっていない箇所を白状してくれることがあります。 - 解決策
結局スクラムの中で上手くいっていないことを言っていいんだ！ということが共有できていないと中々相談もしてくれないということだと思います。
解決策としては心理的安全性を高めて言いやすい状況を作る、困っていることを発表するアジェンダ(ただしそこで内容の追求などはしない)の追加などを行い、対策しました。
最初期は「問題ありません」がスムーズに進行できていると言う勘違いに陥っており、これが本当にまずい状態であると気づくのに時間がかかりました。
デイリースクラムのアジェンダの改善や、アイスブレイク、ファシリテート技術を取り入れたりすることで現在では大分解消したと思います。
完了まで持っていけないアイテムがあった
- 完了まで持っていけないアイテムが発生している
原因としてはAC(受け入れ基準)が詳細に書かれていないアイテムがあったため、そのアイテムが何を持って「完了」になるのか明確になっていなかったことがありました。 - 解決策
ACを詳細に書くための啓蒙活動、勉強会を行い、ACを詳細に書くことを徹底させました。アイテムの受け入れ基準が明確になったことで「完了」まで導きやすくなりました。
スクラムをやっていく上で大切なこと
ふりかえりは宝の山
- スクラムのイベントを「ただ行う」だけであれば簡単、「ふりかえって改善していく」ことこそがスクラムにおいて一番重要な要素
- スプリントレトロスペクティブは改善の機会という意味でスクラム内で一番重要なイベント
同じスプリントを繰り返さないためにもスクラムの推進を阻害する要因を特定して、スクラムチームを守り、障害を取り除くためにプロセスを改善していくことが重要
ふりかえりで出た課題とその解決策は浸透しているのか、浸透していなければ何故浸透していないのか、チームとしてルール化が必要かどうか、スクラムイベントを進めていく中でアジェンダに何らかの追加が必要かどうか。そのようなことをスクラムマスターとして常に考え続ける必要があります。
〜アジャイルソフトウェア開発宣言より〜：計画に従うことよりも変化への対応を
届ける価値が大事
- スプリントレビューの時間は「開発完了したものの発表会」ではない
- 完了したPBIの「価値」を確認し、ステークホルダーに価値を説明し、開発メンバー全員で完了したアイテムのフィードバックを行い「検査」「適応」させる大切な機会
「そのアイテム価値あるの？」はチーム内の口癖になりました。
〜アジャイルソフトウェア開発宣言より〜：契約交渉よりも顧客との協調を
曖昧さは最大の敵
- 詳細に書いてあるアイテムは品質も上がる
- アイテムの受け入れ基準(AC)は詳細に
- アイテムの「完了」の定義(DoD)を作成して満たしているかどうかを確認する
曖昧さを排除するために、ユーザーストーリーに沿ったアイテムを作るための啓蒙活動を何度か行い、チームに詳細なバックログアイテムを作成するための考えを根付かせました。
スクラムマスターとは何なのか？
半年間スクラムマスターをやってきて気づいたこととしては、スクラムマスターとは単にスクラムフレームワークを運用する話ではなく、「組織変革」の話であると言うことです。
つまりスクラムとは「短いスプリントで組織変革を繰り返すこと」でスクラムマスターは「組織変革の意識を根付かせる仕事」と言い換えてもいいかもしれません。
まとめ
偉そうなことをつらつら書き連ねましたが「お前はスクラムマスターになれたのか？」と聞かれれば
「全然なれていないし慣れていない」というのが答えであると思います。これからもチームにスクラムを浸透させて一緒に成長していければと思います。