スクラムは基本的にはスクラムガイドに背くことで失敗しやすくなります。
そんな中でもよくあるアンチパターンと一言解説をまとめました。
スクラムマスター(SM)の失敗
- SMがDevを兼任する
- スクラムマスターの仕事はそうなくならない
- どちらかの作業が片方の作業のボトルネックになる
- Devとしての作業量が不安定でベロシティを計画のために利用しづらくなる
- SMがPOを兼任する
- POとSMはそれぞれの責任に関する作業のみでボトルネックになりやすい
- 時にはPOの立場（プロダクト寄りの視点）とSMの立場（チーム寄りの視点）がコンフリクトを起こすこともある
- SMがチームに奉仕していない
- サーバント・リーダーシップがない
- SMはチームが抱えるあらゆる障壁の解消に努める（全部自分でやらずとも周りと話をするなど）
- SMがチームをマイクロマネジメントしている
- マイクロマネジメントは自己組織化につながらない
- チームが自発的に動けるようなマクロマネジメントを心がける
- SMが妨害リスト(impediment list)を管理していない
- チームが直面するあらゆる障壁をリスト化し管理する
- 優先順位が高いものからSMが順に対応することでチームは円滑に作業ができる
- チームの課題に対してSMとして何に取り組んでいるかがわかると信頼関係を生みやすい
- SMがスクラムプロセスのファシリテーションをしていない
- SMはスクラムプロセスの番人で、自分も守るし他人に守らせることが必要
- ファシリテーションとは、ミーティングの司会をすることではなく、プロセスがうまく回るのを支援すること
- 最初は司会をしてもいいけど、徐々にチームが自走できる仕組みづくりを目指す
プロダクトオーナー(PO)の失敗
- POがチームにプロダクトビジョンを説明していない/できない
- POはプロダクトビジョンを持ち、そのビジョン実現のためチームを導く
- POがPBLを管理していない
- 優先順位の更新をしていない
- INVESTを満たしたPBIになっていない
- 機能のみでなくリリースに向けて必要なストーリーも載せると良い
- POがDevと同じ時間・空間で作業していない
- 仕様の確認事項についてDevはPOに確認するが場所が離れているとロスが多い
- 仕様の確認や提案資料作成の時間を本来は機能追加（価値向上）に注ぐべき
- そもそも確認事項が多発する時点でDoneの定義がよくない可能性がある
- POがエンドユーザーから遠い
- プロダクトの価値最適化が責務のPOがエンドユーザーから遠いとPBLの優先付が難しい
- エンドユーザーからのフィードバックをPBLに取り込むのが遅い、取り込めない
- POを経由しないで外部からタスクが追加される
- POはチームを外からの物言いから守るプロキシとなる
- POに話が通ってその優先順位がPOになされるならOK
- POは各種作業を把握し、優先順位をつける
- 完了の定義をDevと共有していない(Done is Done)
- PBIの完了の定義を明確にしDevに共有していないとDevは作業範囲がわからない
- 受け入れ条件などを明確にするとよい
- POが孤独
- プロダクトバックログ管理の相談をチームとすると良い
- POがスクラム外の仕事を抱える
- プロダクトの価値最適化に注力できない
- プロトタイプやテスト項目も作れなくなってしまう
- 本来POが中心となるべき作業もDevのものになり確認等時間がかかりスピードは落ちる
開発者(Dev)の失敗
- スーパースターエンジニア（またはゴリラ）がいる
- その人の判断が無いとチームが動かず、結果チームが自己組織化しない
- ペアプロ、モブプロを積極的にすると良い
- それでもチームが自己組織化しなければ技術サポートとして外から支援してもらうと輝く
- 開始の定義をPOと共有していない(Ready is Ready)
- 作業を開始するにあたり、DevがPOに求める条件（完了の定義の説明）が曖昧
- 内容が定まらないままPBIの作業を開始しても手戻りが発生する
- クロスファンクショナルではないDevチーム
- PBLを上から作業しづらくなり、ボトルネックが生まれる
- 得意分野にこもるとクロスファンクショナルになかなかならない
- キーマンが単一障害点になってしまう
- 作業に必要な知識や技術がDevにない
- 誰も見積もれない、そのまま着手すると時間ばかりかかる
- スキル習得をPBLに入れ、POに相談して優先順位をつけてもらう
- MVPやYAGNIに反して作り込む
- 後で必要になると思って作ってもそうならないかも、要求は変わり続ける
- その時間で次のPBIに着手できたほうがより多くの価値を届けられる
- 完了の定義を満たすだけのコードを書く
- 動くからと言ってリファクタされていない読みづらいコードで出荷する
- 技術的負債を常に減らすためにリファクタしてはじめて「完了」としても良いぐらい
チームの失敗
- チームの人数が7±2ではない
- 小さいとスクラムの効果はなく、大きいとスクラムではコミュニケーションコストが大きい
- 人数は多ければ多いほど難しい（Jeffは5人が良いって言ってた）
- リモートワーカーとオンサイトワーカーが混在
- スクラムはFace to Faceの価値と効果に重きを置く
- 混在は情報格差が生まれやすく、リモートのDevに「作業を振る」ことになりやすい
- 全員リモートでやる場合はオンラインでの通話を活用する、分報を使うなどの工夫をする（誰かの困り事をできるだけすぐ拾える仕組みづくりを！）
- 発言しない・抱え込む人がいる
- 問題があれば共有し、チームで解決する
- 1人にとっての難しい問題は、もう1人にとっては優しい問題かもしれない
- チームの階層がフラットでない
- 契約や社内における上下関係があると、指摘などがしづらく透明性が保ちづらい
- たとえそうであっても自由に発言できる風土は必要
- チームの雰囲気が悪い
- スクラムチームは信頼の上で成り立ち、それにより透明性を確保する
- チームの雰囲気が悪いと相互補助やそもそも会話が減り透明性は下がる
- 最初は悪くてもカイゼンしていきましょう
- チームのメンバーがコロコロ変わる
- スクラムチームは信頼の上で成り立ち、継続により効果を発揮する
- メンバーが頻繁に変わるチームは心理的安全性も低く、モチベーションも低くなりがち
- プロダクトの利益の共有を行えない
- 想定以上の利益がでればチームで共有すると、モチベーションが高まる
- 継続的に実施できればチームのモチベーションは高く保てる
- ドキュメントを軽視する
- アジャイルはドキュメントを軽視するのではなく、必要なら書く
- 共通認識こそ透明性につながる、そのために必要なら書く
- 簡単な連絡はチャットなどでもよい
- 見積もりを詳細まで詰めすぎる
- 詳細見積りのために割くコスト > ざっくり見積もって外れた場合に対応するコスト
- ずれたとしても1スプリント分以上の差は出ない程度にブレークダウンしてる
- プランニングポーカーで困ったことあまりない
- スクラム外の業務作業が山積み
- チームはプロダクトの開発にフォーカスするべき
- バーンダウンチャートの乖離を気にしすぎる
- バーンダウンは性質的に上振れした後に収まるもの（ギザギザになりやすい）
- そもそもバーンダウンチャートが期待通りに行くのは50％くらいであると認識する
- 熱意がない
- なんでモチベーションが高まらないのか
- チームがビジョン実現に燃えていない ⇒ ビジョンを知らない、共感していない
- チームに権限が与えられていない ⇒ 改善案を出しても実現しない、時間がかかる
スクラムプロセスの失敗
- ビッグバンスタート
- 初めてのスクラム + 初めての技術 + 初めてのチーム = 失敗しやすい
- チームの負担も高く、開発も進まず、評価を得られず、になりがち
- スクラムが初めてなら最初にスクラム・コーチをつけると良い（途中からだと難しい）
- イベントがタイムボックス化されていない
- 時間を決めて各種イベントを行ない、時間を厳守する
- 時間を伸ばしてもわからないものはわからないし、精度を求めてもムダ
- 本当に必要とチームが感じた場合のみ、タイムボックスの変更を行なう
- 技術的負債を解消させるタイミングがない
- POが価値向上のため「機能」を優先しすぎてしまう
- POの立場がDevより上でDevが負債解消を言い出せない
- 負債はスプリントごとに解消しないと改修コストは上がっていく
- 振り返りをしない、正しくしていない
- 振り返りをしてそこからカイゼンに繋げないとスクラムの意味がない
- 振り返りをしてもカイゼンに繋がる行動を起こしていないと同じく意味がない
- 自動化していない
- テストやデプロイの自動化(CI/CD)がないと毎スプリント同じ作業に時間を使う
- 自働化周りは早いうちに環境を整えると良い
- 動作するコードでスプリントレビューをしていない
- 動作していないコードは価値を産まない、受け入れても価値を産まない
- 出荷できる状態でOKにしないと完了条件を定義する意味がない
- カンバンが見づらい、公開されていない
- カンバンはステークホルダーが全員見えるようになっているとよい
- カンバンを見て、気づきを得て、カイゼンに繋がる
- ソフトェアを使う場合はひと目見て全体感がわかるようにするとよい（ダッシュボードなど）
- 見積もりに相対的なポイントでなく絶対的な時間を使う
- 時間通りにできないと焦ったりつらい気持ちになったりする
- 時間上のデータをよく見せるための行動を取りがちになってしまう
- ベテランと初心者が必要になる作業時間は違う
- 2週間を超えるスプリント期間に設定する
- その分、カイゼンのループが周りだすのが遅くなり、成長やリズムが生まれにくい
- 短ければ短いほどカイゼンのチャンスが生まれる
-
情報ラジエーターの概念がない
- データをただ単に見える化しただけではダメ
- 問題発見するためのデータなら誰が見ても即問題があることがわかるような見える化をする
ステークホルダーの失敗
- POに権限を与えない
- POがプロダクトの責任者で決定権を持たせること
- 口を出したくてもアドバイスとして、指示にはしない
- 指示したいならその人がPOになればいい
- スクラムプロセスに口を出す
- SMがスクラムプロセスの責任者、ステークホルダーはSMと会話すること
- 開発手法に口を出す
- Devが開発の責任者、懸念があればSMと相談すること
- 評価をチーム単位ではなく個人単位で行なう
- 個人の評価が中心の場合、個人の評価をあげることに目がいってしまう
- スクラムの成果はチームの成果、徹底することでチーム内の協力を促す
- プロダクトのROIばかり見てチームからヒアリングしない
- 事業としての成功だけじゃなくてチームとしての成功も見てほしい
- チームがどれだけカイゼンを積み重ねて成長したかも見てほしい
- スクラムを始めさせた動機が不明確
- ウォーターフォールが適しているようなプロダクトでアジャイルやるべきか
- スクラムを成功させるための投資が行われなくなってしまう
- スクラムチームをトップダウンの判断のみで結成させる
- スクラムに合わない文化や性格の人をチームに入れるべきでない
- 最初はスクラムに興味がある人、前向きな人をいれて小さな成功を生むとよい
参考資料
この記事書くにあたり調べたらアンチパターン系の記事が色々あり、参考にさせていただきました。
- Scrum Smells - Scrum Community Wiki
- スクラムで失敗する7つの方法
- みんな教えて！！スクラムアンチパターン / 聴講メモ