プログラマに都合のいいスクラム

「どうやったらアジャイル開発が成功できますか？」という質問に答えられませんが、悲しいことに「どうやったら失敗するか」は答えられます。本当はうまくいく方法があって、それをみんなで共有できればいいんですが。今日はこれまでに経験した「アジャイル開発を失敗させる方法」について書いてみます。

スケジュールにコミットしない

バックログというやることリストを作り、優先順位をつけ、上から順番にやっていきます。ベロシティとかがわかれば、「だいたいどれぐらいでどの量の作業が終わるか」を見積もることができますが、それとコミットメントは別です。

もちろん、関係者間で「ベストエフォートで作業する」という共通認識があり、信頼関係が築けているなら、多少の「ぶれ」、すなわち「ちょっとだけ目標より作業をこなせませんでした」とか「思った以上にできました」とかがあってもいいと思います。

ただ、その前提条件をクリアせずにやってしまうと「スクラムなんで計画に確実にコミットメント求められても困ります」といった、プログラマに都合のいいスクラムができあがります。

プログラミング以外に責任を持たない

スクラムをするならスクラムガイドの4ページ目にでてくる「スクラムチーム」を実現する必要があります。自分はこれが（スクラムだけでなくアジャイル開発全般における）前提条件であり、これが実現できればあとは簡単！と勝手に思っていて、このハードルが高すぎるから、いろんな失敗事例がでてくるのかなぁと思っています。例えば、スクラムガイドの説明を読んでみてください。

スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。

世の中の「スクラムやってます！」って企業はもうとっくにこれを解決しているのでしょう。すばらしい！うらやましい！ごめんなさい。ちょっといぢわるに書きました。

僕が言いたかったのは、こういった人のアサイメントや組織レベルの変化を実現できる環境なら、成功への道のりが見えてくるのではないでしょうか。ただ、そうじゃない場合、なかなか超えるのが大変な壁に見えます。

話が少しそれました。「チーム以外に頼らずに作業を成し遂げる能力を持っているチーム」を作っても、役割が大きく変わるわけではないと思います。しかし、近くにいることをいいことに、本来持つべき責任を丸投げするプログラマがいるようです。

たとえば、テスターが都度QAをしてくれるので、コードレベルの単体テストを実施しないとか、デザイン崩れなどはデザイナ責任としてチェックすらしないとか、プログラマに都合のいいスクラムができあがります。