Scrum失敗例 楽天の場合
楽天のあるプロジェクトが「Scrumをやったもののうまくいかなかった」という経験談をスライドにまとめていました。
概要と感想を書きます。
[私がスクラムをやめた理由 - 全員スクラムマスター。@DevLove -](http://www.slideshare.net/TakaoOyobe/20120521-13014872)
View more [presentations](http://www.slideshare.net/) from [Takao Oyobe](http://www.slideshare.net/TakaoOyobe)
スライド概要
Scrumを導入したが、下記の問題により挫折。
- 人が選べない
- プラクティスに従ってくれない人がいる
- 切符を切る人(正しくバスに乗っているか確かめる人)がいない
- 役割は決められない
- 結局新たな滝(ウォーターフォール)ができただけ
- 教育が難しい
スライドを見て思ったこと
- 根本的にスクラムマスターの権限が弱すぎる?
- プラクティスを周知し、従わせる
- 合わない場合はプラクティスを軽量化するか捨てる
- どうしても従わないメンバーがいる場合、入れ替えられる機構が必要
- 結局スモールウォーターフォールになるのは自分も経験済み。恐らく「スモールリリース」に誤解
- 1スプリント毎に必ず成果をコミットする(タイムボックス化)
- 優先度の高いストーリーから消化する
- メンバーをバスに乗せるのは本当に難しい
- 「アジャイル開発のプラクティスをやれば良くなる」という自発的な動機がなければ、大量のプラクティスの学習で脱落する人が続出しそう
- スクラムマスターはここでも継続的・漸進的な推進をする必要がありそう
- 最初の2~4スプリントはふつうスパイクや調査の期間なので、ここで徐々に教育すれば良さそう
総じて、メンバーをプラクティスに従わせるのに苦労している印象を受けました。
アジャイル開発には自律的なプラクティスが多く、自ら行ってもらえるようにならないとうまく回りません。
メリットが実感できればもっと積極的になってくれるかもしれませんが。
プラクティスの意義を実感するためのワークショップ(短時間でできるゲーム)が多数あるので、これをまず体験させるのも効果的でしょう。
あとこれは私の経験則ですが、開発メンバーの主力がスクラムマスターを兼任すると、開発も指揮も中途半端になるのでオススメしません。