LinkedinのCertified ScrumMastersグループで「How do you measure team performance?」というディスカッションが活発に行われています。Linkedinだと職業などに特化した議題が多くてなかなか面白いですね。このディスカッションの始まりは以下の質問です。
Simply, how does you measure output, that team generates, its performance or what metrics do you use?
どのようにしてチームが生み出すアウトプットを測定していますか？パフォーマンスや基準として使っているものはなんですか？
前回書いた「XXXX」という記事にも繋がる部分があるので、投稿されているコメントをまとめてみました。
世界のスクラムマスターのコメントまとめ
南アフリカのスクラムマスターのコメント
パフォーマンス測定する方法があるとは思えないけど、モニタリングによってチームが改善しているならば、Doneした数やベロシティー、コード品質やユニットテストの結果が使えるかもしれない。
フィンランドのスクラムマスターのコメント
複雑なプロダクトの場合、測定しなければならないパラメタがたくさんありすぎるので、チームのパフォーマンス測定は不可能だと思う。結論を言うと、パフォーマンス評価や生産性の測定は害しか生み出さないもので、測定するとしても、重要なパラメタ（やるきとか、開発力）を測定するのはほぼ不可能だからやめたほうがいいと思う。
いかにも同じようなことが書かれている。
http://www.martinfowler.com/bliki/CannotMeasureProductivity.html
チェコのスクラムマスターのコメント
（彼はとある会社の創設者）私は昔の方法からアジャイルに切り替えたときの効果として、財務利益やチームの生産性、どれぐらいの価値を提供できたか（？ユーロ稼いだか）を知りたい
オーストラリアのスクラムマスターのコメント
当初はバグの数やストーリーポイントだと思っていたんだけど、実際はそれとはかなり違うということがわかった
フィンランドのスクラムマスターのコメント
パフォーマンスは比較できない。
イギリスのスクラムマスターのコメント
何％のストーリーを消化できたか？＋バグ指標。個人のパフォーマンスとしては、ベストな計算式は見つかっていないけど、
- 効率性として 個人の計画達成度とチームの計画達成度の比較
- ベロシティをチーム人数で割った平均値と、個人で消化したポイントの比較
- バグ発生率（１％以下を目標など）
など、工夫をしている。
さらにたくさんの議論がされているのですが、
- 無理やり数値を出すのは気持ち悪い
- 開発に特化した測定が中心になっていて、ビジネスサイドだと売上とかお金にならざるえない
- パフォーマンス測定したいけれど難しい
というのは共通認識のようです。
このディスカッションを読みながら、ビジネスサイドが納得するパフォーマンス測定方法を考えてみたのですが、実現した要求の数やそのボリュームで、ビジネスにどれぐらいデリバリーできているかは伝わりそうです。さらに、リリース回数を計測して、「１日に何回もリリースできる」ことができれば、改善されているイメージも持ちやすいのではないでしょうか。あとはもちろん、動くソフトウェアによるデモが最強でしょう。
開発に綴じた測定方法だと、Agile 2010でしいれてきた、Scrum Metrics for Hyperproductive Teamsのロボコーチで十分な気がします。スピーカーのスコットさんは「スクラムで600％成長した」っておっしゃってました。
ついでに、Linkedinにもロボコーチを紹介したのですが、久しぶりに調べてみると、セッションの動画がありますね。
すばらしい！個人的にはAgile2010の参加したセッションの中で一番おもしろかったセッションなので、英語ですが参考までにどうぞ。
旅と子育てとアジャイルコーチのブログ「世界」 