アジャイルソフトウェア開発環境では、どんな指標をマネージメントに報告すべきなのだろう？
スクラム開発メーリングリストで、Charles Bradley氏は次のように問いかけた。
ある部門には3つの開発チームがあり、どのチームもある1人のシニアマネージャに報告することになっている。そして、そのシニアマネージャは数人とともに副社長（VP）に報告する。報告すべき指標があるとしたら、チームはシニアマネージャにどんな指標を報告すべきと提案するだろうか？
同様に、シニアマネージャから副社長に対してはどのような指標を報告すべきと提案するだろうか？
George Dinwiddie氏が提示したのは直接的な解決策だった：マネジメントにどんな指標が有用だと考えるかを確認せよ、ということだ。しかしながら、この例の場合、マネジメントはどんな指標が欲しいのか分かっていない。彼らは指標を要求することがスクラムの原理や精神をこわすことにならないか気にかけていて、それでBradley氏にアドバイスを求めているのだ。
アジャイル開発環境においてマネジメントに絶対に報告すべきではない指標はあるだろうか？ George Dinwiddie氏は次のように書いている。
一般的に、ナマの数字を報告してはいけません。開発から外された人は多くの場合その数字を合理的に解釈するための事情を把握しようとしません。そして、上位のマネージャにはそれらの数字を分析する時間がありません。
特に、Dinwiddie氏によれば、チームの速度はマネジメントに報告されるべきではない数字である。速度そのものよりも今後についての見積もりを報告すべきである。
Ron Jeffries氏が述べているのは、指標の意図がチーム間の生産性を比較することにあるような指標は悪い考えである、ということだ。
ここで何を測ろうとも、たとえそれが受け取った収入の金額であったとしても、チームの相対的な"生産性"を評価するために使うことはできません（すべきでない、のではなく、できないのです）。そんなものは機能しません。機能させることができません。私は、岩を支えるものなく空中で持ち上げることができない、という意味でできないと言っています。猫が橋を築くことができない、という意味でできないと言っているのです。車のセールスマンが1ヶ月に30台の車を売ったとします。不動産業者は1ヶ月に3戸の家を売ったとしましょう。どちらがより生産的でしょうか？ そして、片方と同等の生産性を得るために他方は何をすべきでしょうか？
では、どのような指標をマネジメントの流れにそって打ち上げるべきだろうか？ "karatasfamily"氏によって提示された1つのアプローチは、マネジメントがアジャイルかそうでないかに関わらず、ソフトウェア開発プロジェクトについて持つ疑問を考慮し、その疑問への洞察を与えるような指標を提供する、というやり方だ。いくつか質問の例を挙げる。
- 今何をしているのか？
- いつ作業しているのか？
- スケジュール通りなのか？
- 予算通りなのか？
この考え方をすれば、プロジェクトがアジャイルプロジェクトであるという事実はマネジメントからほぼカプセル化される。アジャイルプロジェクトにおける指標報告構造はマネジメントの現状の報告形式に合うように設計されているのであって、マネジメントがまったく新しいビジネスのやり方について学習しなければいけないわけではない。この指標に対する考え方はKen Schwaber氏の本スクラム入門 アジャイルプロジェクトマネジメントに書かれていることと同様のことである。
けれども、最も無駄にならない指標は最初からつくられる必要がない指標である。Douglas W. Hubbard氏は彼の本How to Measure Anythingの中で、次のように述べている。
仮にも指標による測定が行われるということは、決定や行動に対して想像しうる影響があるに違いないからである。どの決定が影響したかを提示した指標によって把握することができないのなら、そして、その測定指標によってそれらをどのように変化させうるかが特定できないのなら、その測定指標はまったく無意味である。
この尺度によれば、提案されたどんな指標も—アジャイルかどうかに関わらず—、"この指標によって後押しされる決定は何か？"という質問に答えられるべきである。もしどんな決定もその指標に影響を受けないのなら、その指標は無駄であり、報告されるべきではないものなのだ。