Edited at

スクラムを失敗させる51のアンチパターン

スクラムは基本的にはスクラムガイドに背くことで失敗しやすくなります。

そんな中でもよくあるアンチパターンと一言解説をまとめました。


スクラムマスター(SM)の失敗


  • SMがDevを兼任する


    • スクラムマスターの仕事はそうなくならない

    • どちらかの作業が片方の作業のボトルネックになる



  • SMがチームに奉仕していない



  • SMがチームを管理している


    • 管理は自己組織化につながらない、Devに自発的に動いてもらう手助けはOK



  • SMが障壁リストを管理していない


    • チームが直面するあらゆる障壁をリスト化し管理する

    • 優先順位が高いものからSMが順に対応することでチームは円滑に作業ができる



  • SMがスクラムプロセスのファシリテーションをしていない


    • SMはスクラムプロセスの番人で、自分も守るし他人に守らせることが必要

    • バーンダウンチャートの更新なんかもちゃんと毎日SMがやる



  • バーンダウンチャートの乖離を気にしすぎる


    • バーンダウンは性質的に上振れした後に収まるもの(ギザギザになりやすい)

    • そもそもバーンダウンチャートが期待通りに行くのは50%くらいであると認識する




プロダクトオーナー(PO)の失敗


  • POがチームにビジョンを説明していない/できない


    • POはビジョンを持ち、そのビジョン実現のためチームを導く



  • POがPBLを管理していない


    • 優先順位が正しくつけられていない、機能への思いばかりになっていないか

    • リリースに向けて何がどの順番で必要なのかという優先順位を理解すべき



  • POがDevと同じ時間・空間で作業していない


    • 仕様の確認事項についてDevはPOに確認するが場所が離れているとロスが多い

    • 仕様の確認や提案資料作成の時間を本来は機能追加(価値向上)に注ぐべき

    • そもそも確認事項が多発する時点でDoneの定義がよくない可能性がある



  • POがユーザーから遠い


    • プロダクトの価値最適化が責務のPOがユーザーから遠いとPBLの優先付が難しい



  • POを経由しないでタスクが追加される


    • POはチームを外からの物言いから守るプロキシとなるべき

    • POは各種作業を把握し、優先順位をつける



  • 完了の定義をDevと共有していない(Done is Done)


    • PBIの完了の定義を明確にしDevに共有していないとDevは作業範囲がわからない

    • 受け入れ条件などを明確にするとよい



  • POがPOチームを組んでいない


    • POはプロダクトの価値最適化のために、様々な職能を持ったチームが要る



  • POがプロトタイプをDevに提供していない


    • ワイヤーフレームでも良いのでDevにプロトタイプを渡す

    • 認識齟齬や手戻りが格段に減る、プロトタイプ作成中にカイゼンもできる



  • POがテスト項目をDevに提供していない


    • PBIが求められる機能を満たすためのテスト項目をPOが責任もってやる

    • 受け入れてOK出した時点でPOの責任になるので、頑張る



  • POがスクラム外の仕事を抱える


    • プロダクトの価値最適化に注力できない

    • プロトタイプやテスト項目も作れなくなってしまう




開発チーム(Dev)の失敗


  • スーパースターエンジニア(またはゴリラ)がいる


    • その人の判断が無いとチームが動かず、結果チームが自己組織化しない

    • 抜けてもらうことも考える

    • そういう人は技術サポートとして外から支援してもらうと輝く



  • 開始の定義をPOと共有していない(Ready is Ready)


    • 作業を開始するにあたり、DevがPOに求める条件(完了の定義の説明)が曖昧

    • 内容が定まらないままPBIの作業を開始しても手戻りが発生する



  • クロスファンクショナルではないDev


    • PBLを上から作業しづらくなり、ボトルネックが生まれる

    • 得意分野にこもるとクロスファンクショナルになかなかならない



  • 作業に必要な知識や技術がDevにない


    • 誰も見積もれない、そのまま着手すると時間ばかりかかる

    • スキル習得をPBLに入れ、POに相談して優先順位をつけてもらう



  • YAGNIに反して作り込む


    • 後で必要になると思って作ってもそうならないかも、要求は変わり続ける

    • その時間で次のPBIに着手できたほうがより多くの価値を届けられる



  • 完了の定義を満たすだけのコードを書く


    • 動くからと言ってリファクタされていない読みづらいコードで出荷する

    • 技術的負債を常に減らすためにリファクタしてはじめて「完了」としても良いぐらい




チームの失敗


  • チームの人数が7±2ではない


    • 小さいとスクラムの効果はなく、大きいとスクラムではカオスになる



  • リモートワーカーがいる


    • スクラムはFace to Faceの価値と効果に重きを置く

    • リモートは情報格差が生まれやすく、リモートのDevに「作業を振る」ことになる



  • 発言しない・抱え込む人がいる


    • 問題があれば共有し、チームで解決する

    • 1人にとっての難しい問題は、もう1人にとっては優しい問題かもしれない



  • チームの階層がフラットでない


    • 契約や社内における上下関係があると、指摘などがしづらく透明性が保ちづらい

    • たとえそうであっても自由に発言できる風土は必要



  • チームの雰囲気が悪い


    • スクラムチームは信頼の上で成り立ち、それにより透明性を確保する

    • チームの雰囲気が悪いと相互補助やそもそも会話が減り透明性は濁り続ける

    • 最初は悪くてもカイゼンしていけるならありっちゃあり



  • チームのメンバーがコロコロ変わる


    • スクラムチームは信頼の上で成り立ち、継続により効果を発揮する

    • メンバーが頻繁に変わるチームは心理的安全性も低く、モチベーションも低い



  • プロダクトの利益の共有を行えない


    • 想定以上の利益がでればチームで共有すると、モチベーションが高まる

    • 継続的に実施できればチームのモチベーションは高く保てる



  • ドキュメントを軽視する


    • アジャイルはドキュメントを軽視するのではなく、必要なら書く

    • スクラムは共通認識なのでそのために必要なら書く

    • 簡単な連絡はSlackなどでもよい



  • 見積もりを詳細まで詰めすぎる


    • 詳細見積りのために割くコスト > ざっくり見積もって外れた場合に対応するコスト

    • ずれたとしても1スプリント分以上の差は出ない程度にブレークダウンしてる

    • プランニングポーカーで困ったことあまりない



  • スクラム外の業務作業が山積み


    • チームはサポートできない




スクラムプロセスの失敗


  • ビッグバンスタート


    • 初めてのスクラム + 初めての技術 + 初めてのチーム = 失敗しやすい

    • チームの負担も高く、開発も進まず、評価を得られず、になりがち

    • スクラムが初めてなら最初はスクラム・コーチをつけると良い



  • イベントがタイムボックス化されていない


    • 時間を決めて各種イベントを行ない、時間を厳守する

    • 時間を伸ばしてもわからないものはわからないし、制度を求めてもムダ

    • 本当に必要と感じた場合のみ、タイムボックスの変更を行なう



  • 技術的負債を解消させるタイミングがない


    • POが価値向上のため「機能」を優先しすぎてしまう

    • POの立場がDevより上でDevが負債解消を言い出せない

    • 負債はスプリントごとに解消しないと改修コストは上がっていく



  • 振り返りをしない、正しくしていない


    • そもそも振り返りをしてそこからカイゼンに繋げないとスクラムの意味がない

    • 振り返りをしてもカイゼンに繋がる行動を起こしていないと同じく意味がない



  • 自動化していない


    • テストやデプロイの自動化(CI/CD)がないと毎スプリント同じ作業に時間を使う

    • CI/CDは早いうちに環境を整えると良い



  • 動作するコードでスプリントレビューをしていない


    • 動作していないコードは価値を産まない、受け入れても価値を産まない

    • 出荷できる状態でOKにしないと完了条件を定義する意味がない



  • カンバンがアナログでない、公開されていない


    • カンバンはステークホルダーが全員見えるようになっていると良い

    • カンバンを見て、気づきを得て、カイゼンに繋がる



  • 見積もりに相対的なポイントでなく絶対的な時間を使う


    • 時間通りにできないと焦ったりつらくなったりする

    • 時間上のデータをよく見せるための行動を取りがちになってしまう



  • スクラムに慣れていない時期にスプリントの期間を1週間にする


    • イベントやプロセスにばかり気を使って疲弊しやすい

    • 2週間ぐらいがおすすめ、慣れてきたら短くても良い




ステークホルダーの失敗


  • プロダクトの方向性に口を出す


    • POがプロダクトの責任者、POと相談をすること



  • スクラムプロセスに口を出す


    • SMがスクラムプロセスの責任者、SMに相談すること



  • 開発手法に口を出す


    • Devが開発の責任者



  • 評価をチーム単位ではなく個人単位で行なう


    • スクラムの成果はチームの成果、徹底することでチーム内の協力を促す



  • プロダクトのROIばかり見てチームからヒアリングしない


    • スクラムは正しくやれば楽しくなるし、相互成長にも繋がる



  • スクラムを始めさせた動機が不明確


    • ウォーターフォールが適しているようなプロダクトでアジャイルやっちゃう



  • スクラムチームをトップダウンで結成させる


    • スクラムに合わない文化や性格の人をチームに入れるべきでない

    • やらされてる感よりもやってやる感が自己組織化には求められる




参考資料

この記事書くにあたり調べたらアンチパターン系の記事が色々あり、参考にさせていただきました。