ベストスクラムチームに報奨を与えるべきか？

作者 Mark Levison , 翻訳者 笹井 崇司 投稿日 2010年9月14日

セクション

エンタープライズ・アーキテクチャ,

プロセス/プラクティス,

設計/アーキテクチャ

トピック

Scrum ,

Agile ,

ヒューマンリソース

共有 |

原文(投稿日：2010/08/25)へのリンク

Rajesh Velliyatt氏は “四半期毎のベストスクラムチーム賞” を創設するというマネジメントのアイデアの良し悪しについて尋ねた。彼はこうした報奨システムに対して、次のようなマイナス面があり得ることを懸念していた。

• 主観的である（他のシステムと同様に） 
• すべてのチームがうまくやっていても（あるいは、どこもうまくやっていなくても）、そこからチームを1つだけ選ぶのは、他のチームをおとしめることになる。
• チーム間の協力に対して、マイナスに働くかもしれない。
• 選定委員会に対して「自分たちが抜きんでいる」ことを証明するには、オーバーヘッド（データ収集など）がありすぎる（スクラムマスターにとって？）。
• 様々なプロダクトチームがあって、同一条件で比較できない。

Rajesh氏の指摘に加えて、こちらの報告者は、競争は不健全になるおそれがあると述べている。そして、Driveの著者 Dan Pink氏が、報奨は機械的なタスクにはうまく機能するが、ソフトウェア開発のようなクリエイティブなタスクには役に立たないと表明していることを指摘した。Pink氏は、外発的動機付けよりも内発的動機付けがクリエイティブなタスクにおける生産性を改善すると説明している。Michael James氏はDan Ariley氏の言葉を引用した。「9つのタスクで3つの実験を実施しましたが、そのうちの8つのタスクにおいて、インセンティブが高ければ高いほどパフォーマンスは低下しました。実際、その結果のロバスト性には驚きました」 -  Dan Ariely, Uri Gneezy, George Loewenstein, and Nina Mazar (2005) “Large Stakes and Big Mistakes” Working Papers No. 5-011, Federal Reserve Bank of Boston.

Steve Janvrin氏は自分のスクラムチームに対して、「もし複数のスクラムチームがあって、自分が受賞できなかったら、あなたはどう感じますか？」とみんながどう思うのかを尋ねた。彼らの回答は「腹が立って、一緒に仕事をしたくなくなるだろう」というものだった。

Paul Tiseo氏はトップチームに対する報奨ではなく、すべてのチームが得られるよう努力するものにすることを提案した。1つのチームに報奨を与えると、どのチームが最高のことをしたのかに悩むことになる、と指摘する。これについて、Rajesh氏はいくつかの評価基準を提案した。

1. チームのベロシティトレンド（条件: チームが一貫したポイント見積りをしていること。報奨システムによって影響を受けるおそれはあるだろうか？）

2. スプリント実行効率（バーンダウンチャート、発生した障害、チームが障害をどう処理したか） 

3. DoD（完了の定義）の順守（データはPO（プロダクトオーナー）から得られる） 

4. スクラムプロセスに対するチームのコミットメント/姿勢（データはSM（スクラムマスター）から得られる）

こちらの報告者は、これらすべての評価基準、特にベロシティ（詳細については、Misuse of Velocity of an Agile Projectを参照）は、ズルされるおそれがあると指摘した。一般的にどんな評価基準であっても、そのための取り組みが必要になる。そのため、こうしたことをチームがやりすぎると何が起こるのかを考えなければならない。

Jay Conne氏は、マーケットドリブンな代替案を提案した。「ビジネス部門にプロジェクトをやらせたいチームを競り落させてはどうですか？ これなら数多くの側面を一挙にカバーできます。そして、バランスを保つために、チームにもプロジェクトを競り落させるのです。これは双方向に得られた信頼を示すことになります」

Bachan Anand氏はこうした「健全な」チーム間の競争を実施したことがあるそうだ。彼は、短期的には非常に不健全で、チームはサイロの中で仕事をするようになり、同じプロジェクトで仕事をしている他のチームと協力しなくなると感じたそうだ。しかしながら、Bachan氏の組織は、複数のチームから関連する人を集めてコーチングやメンタリングのセッションをするのは、コラボレーションを改善するのに役立つと感じたそうだ。