スクラムを失敗させる方法

みなさんこんにちは。@ryuzeeです。

How to make Scrum failが良い記事だったので、抜粋・意訳にてご紹介します。

1. ふりかえり（レトロスペクティブ）をしないか、間違ったふりかえりをする

ふりかえりをせずして、どうやって物事をよりうまくできるようにすることができるというのだろうか？ふりかえりは、全てのチームメンバーがうまく行ったこと、もっとうまくできるだろうことについて議論できるという点で必要不可欠だ。そしてもちろん言うまでもなく、失敗から学習しなければならない。もしそういったことが行われていない（形式的なふりかえり）なら、ふりかえりは役に立っていない。

2. ダメなプロダクトオーナー

プロダクトオーナーはいつでもプロジェクトのために時間を使えるようでなくてはならない。プロダクトオーナーはスプリントプランニングやふりかえりに参加しなければならない。また一方でプロダクトオーナーはスプリント中のタスクは見積りしてはならない。見積りはチームの責任なのだ。プロダクトオーナーはビジネス上の優先順位に基づいてプロダクトバックログアイテムの優先順位を付けなければならない。このため、プロダクトオーナーはビジョンやビジネス計画やリリース計画を持っていなければならない。また、プロダクトオーナーはチームが十分理解できるようにはっきりとしたプロダクトバックログアイテムを定義する必要がある。スプリント期間中のスプリントバックログの変更は行うべきではない。

3. ダメなスクラムマスター

スクラムマスターはチームの「管理者」であってはならない。チームは自己組織化されているべきなのだ。スクラムマスターは指示に従わせるのではなく、必要なときに助言すれば良い。スクラムマスターはチームメンバー間で合意できない事項について最終決定を下す必要がある。スクラムマスターは優先順位をつけたプロジェクトの障壁事項のリストを用意し、できる限り早く解決していく必要がある。スクラムマスターはチームを集中させ、物事が継続的に改善するようにする。物事はいつももっとうまくできる方法がある。タスクを個人に割り当ててはならない。タスクはチームメンバー自身が自分たちで選択・担当していく。

4. スクラムの儀式（スタンドアップミーティング、スプリントプランニング・・・）にとっても時間がかかる

スタンドアップミーティングでは、全員が、やったこと、これからやること、困っていることについて発言すべきだ。言わなければいけないことはこれで全てなのだ。スタンドアップミーティングはおしゃべりの場ではなく、詳細な情報について話す場でもない。スタンドアップミーティングはチームサイズによるが、10～15分以上かけてはいけない。ふりかえりとスプリントプランニングも時間を決めて行う。ミーティングの本質にこだわろう。スクラムはおもしろいはずだが、それは、遊び場であることを意味してはいないのだ。

5. 「完成（Done）」の定義を間違えている

各スプリントの終わりには作ったソフトウェア製品は製品としてリリース可能でデモが可能であるべきだ。これはソフトウェアがユニットテストと結合テストが手動ではなく自動で行われる必要がある、ということを意味する。もちろん、開発者はテスターがテストの合否を決める判定基準について知っておくべきで、自動テストと手動テストでは大きな違いがあるだろう。

6. ベロシティをトラッキングしていない

チームのベロシティをトラッキングしなければならない。スクラムマスターはもしチームのベロシティが停滞していたら、何らかのアクションを取らなければならない。スクラムマスターは「5回のなぜ」や石川教授が開発した「特性要因図」を使って根本原因を見つけなければならない。

7. スプリントの中でウォーターフォールをやっている

全てのプロダクトバックログアイテムを75%完成させるより、75%のプロダクトバックログアイテムを100%完了させた方が良い。（完成の定義を参照）。一個人ではなくチーム全体でプロダクトバックログアイテムを担当し、テスターもチームの一員とすべきである。

8. 技術的負債がある

技術的負債は、最後に更なる別の問題が発覚し、本来各イテレーションでは同じように機能を作れなければならないところなのに、最後の方のイテレーションが新しい機能を作れなくなりうる、という理由で、避けなければならない。リファクタリングや再設計は必要と思ったときに速やかに行われなければならない。なぜなら、最後にまとめてやろうとすると。多くのコストと時間がかかりすぎて行うことが難しいからだ。バグについても同じようにできる限り早く解決しなければならない。

9. 割り込み/プロダクトオーナーを経由されない

チームは集中し続けなければならない。これは多すぎる割り込みは「悪」である、ということだ。もちろん、誰でも助けを求めることができるが、新しい機能に関してはプロダクトオーナーに要求すべきである。プロダクトオーナーは新しい機能に関する要求をバックログに追加し、優先順位を振りなおすべきである。もしそれが重要な機能なら、チームは次のスプリントの最後には納品することができるだろう。誰もチームメンバーに直接機能の追加要求を行ってはならない。

10. 分析やドキュメントがない

スクラムは何の分析もしなくて良いし、何のドキュメントを書かなくても良い、と言っているわけではない。分析のとドキュメントの作り方は既存のやり方とはちょっとだけ違っていて、その違いは継続的なプロセスであるということだ。バックログに記載されたプロダクトバックログアイテムはチームがタスクに分割し、スプリントプランニングで見積もるのに十分なだけ、はっきりさせる必要がある。（スプリントで実装できそうであれば、それは十分に詳細化されている、ということだ。）これはプロダクトバックログアイテムはプロジェクトの開始時点で細かくし過ぎるのではなく、バックログを作る時にストーリーポイントで見積もれるくらいにしておくべきである、というこである。