Agile Journalの9月号の記事(リンク)で、AOLのDirector of Program ManagementであるJoe Kreb氏は、Scrumの「sprint」という用語はAgile遷移に害を及ぼすと述べている。ソフトウェアプロジェクトは、短距離走よりもマラソン に類似していると言う。
ソフトウェアプロジェクトには、プロジェクトの期間が4週間以上であることを要求するスコープがある。それゆえ、運動の意味では一連の短距離走として捉えることができないが、長距離レースのタイムボックスやマイルメーカーとして捉えられる必要がある。チームが全速力を出そうとし、あらゆるiterationでダッシュする場合、杜撰、体力の消耗そして誤りが忍び込む。
同様の意味で、短距離走が長期にわたるとアスリートも杜撰になるだろう。アジャイルチームはできる限り速い速度を維持するために、不具合や次善策を取り入 れるだろう。結局は、実行が非常に限られるので、チームはどっちにしろペースを維持できない。その時点で、チームは燃え尽き、技術的な損失は高くなり、 チームの士気は低くなる。少しのiterationの後でちょっとだけ遅れを取っても、チームはすばらしいスタートを切った。アジャイルチームが自己管理 され、期待に抵抗したり管理することを望んでいるが、アジャイルコーチは、アジャイル開発に不慣れなプロジェクトチームを外部からの侵入や勢力から守るこ ともあり得る。そこでJoe氏は、チームの質や士気を絶えず見守り、この種の燃え尽きを早い段階で捉えることを提案している。
そこで、組織的な敏捷性を見ると、早期のiterationにおけるチームの速度だけでなく、その後のiterationの速度も計測する必要があり、 燃え尽きたのではなく弱まっていることを確実にする。チームが安定状態になかったということを見分けるために、幹部は単なる速度よりもメトリックを確認す る必要がある。質と士気は、速度と同じくらい重要である。質は、公になっている不具合の追跡と同じくらい単純で、士気はレトロスペクティブで収集された チームの平均の票として収集される。特に、さらに長いプロジェクトは早期のiterarionにおいて、適度であるが一貫したペースによって益を得る。 「sprinting」はうまい動機付けの語呂合わせのように聞こえるが、短期間しか続かない。多くのマラソン選手がそうであるように、道半ばにして壁に ぶち当たる可能性がある。Joe氏は、以下のようなアドバイスを残している。
一方において、「sprint」は組織内において幹部やチーム間でも一様に 、誤ったメッセージを伝え兼ねない。しかしながら、「sprint」が短いことを誰もが知っているため、ほとんど説明は不要である。単に「速い」ことを意 味するが、また「長期にわたる」や「強引なスケジュール」を意味する場合がある。反復的で漸進的なことを説明するのは、sprintの概念ほど直感的では ないが、長期的かつ持続的なアジャイル効果を求めている場合、安定を確保するにはおそらくマラソンの比喩が役立つ。sprintに対してもっともな理由が あれば、iterationとプロジェクト間でより長いリカバリー時間を考慮する。
興味深い議論がある。すでに知っていることだが、「sprint」という用語が「持続可能な速度」とかち合う(eXtreme Programmingからの引用)。また、Scrum(および概してアジャイル開発)を導入している新しいチームは、あまりにも急いでやろうとして問題 にはまることがよくあるというのは、このレポーターの経験でもある。これは問題の1つになるだろうか?
原文はこちらです：