スクラムで失敗する7つの方法
みなさんこんにちは。@ryuzeeです。
ジェフ・サザーランド氏のスライドが素晴らしいので抜粋・意訳にてご紹介します。 これは2007年の文書ですが、今読んでも全くもってその通りあてはまると思います。
1.プロダクトオーナーの失敗ポイント
プロダクトオーナーが、ビジョン、ビジネスプラン、リリースのロードマップを持っていない
プロダクトバックログが適切な順番で優先順位付けされていない。技術的な問題を含む、全ての仕事が含まれていない。スプリントプランニングに使えるようになっていない（適切なサイズになっていない、正しく見積もられていない、詳細化できるようになっていない）
プロダクトオーナーがスプリント期間中に無断でどこかに行ってしまう
2.スプリントプランニングの失敗ポイント
- プロダクトオーナーがはっきりと思いを伝えない
- チームがプロダクトバックログから離れている。フィーチャーをスプリントタスクにブレークダウンしていない
- プロダクトバックログの元の見積りがスプリントバックログのより詳細化された見積りと同一であることを、スクラムマスターが確認できない
- 信頼、透明性、真実がない
- 計画がthree finger testに合格しない
3.デイリーミーティングの失敗ポイント
- チームの人数が7プラスマイナス2名よりも多い
- 発言しない人がいる
- 意味ある情報が伝えられない（タスクの開始、停止、完了、見積り超過、個人的な問題を含むプロジェクトへの妨げ）
- チームが自己組織化されていない（聞いた情報を元に作業を再計画すべきだ。ミーティングで最も妨害となる事項の除去のために60秒ルールを使う）
- スクラムマスターが酷いミーティング（15分以上、ファシリテーションが欠如した）をする
4.スクラムマスターの失敗ポイント
- スクラムマスターがチームに奉仕、集中していない（バーンダウンを毎日更新する、毎日妨害事項を解決する、毎日個人の問題を取り扱う）
- 良いヒューマンスキル、ファシリテーションスキルを持っていない
- 良いリーダーシップスキルを持っていない（誠実でないことを黙って見過ごす、嘘や怠慢、情報の隠蔽。優先順位付けした妨害事項のリストを持たず、妨害を解決できない。個人の変化や問題に対応できない）
5.チームの失敗ポイント
- 必要な技術や知識領域を持っていない
- バーンダウンを作れない、妨害を除去できない、ベロシティを向上できない
- スプリントバックログに記載されていない作業をしている
- マルチタスク
- 過度な仕事量がある
- テストを早期に実行することができない
- エンジニアリングに関するプラクティスを改善できない
- 占有して自由に使えるリソースがない
6.スプリントレビューの失敗ポイント
- テストされた動作するコードをデモすることができない
- ソフトウェアの製造が完了していない（doneに関する統一された定義がない、プロダクトオーナーがフィーチャーが完了したことを確認しない、完了していない場合にプロダクトオーナーがプロダクトバックログの優先順位を振りなおさない）
- スプリントの結果としてのベロシティが明確ではない
- チームがふりかえりをしない（チームは改善のためのふりかえりをしない。スプリントの終わりにふりかえりの提案をすることができない）
7.管理者（マネージャ）の失敗
- ビジネスモデルを持っていない
- 十分なリソースを用意しない
- 均一に出荷することができない－ムラ
- 負荷がかかる構造を避けることができない（持続可能なペースに反する、スプリント期間中にチームを崩す）－ムリ
- 無駄を除去できない－ムダ
- チームが除去できない妨害を除去することができない
- チームを平凡なチームから押し上げるようにチャレンジさせることができない
それでは。
