コロケーション（共同の場所）はアジャイルにおいて最も重要なアドバイスのひとつだが、ますますプロジェクトは分散したチームで実行されるようになってきている。Scrum Developmentグループにおいて、Safari Asad氏は顧客が離れたところにいるだけでなく、開発者も離れたところにいるという危機的状況にあるプロジェクトに関する興味深い議論を始めた。
Asad氏はその状況を、よいものがどんどん悪化していったと表現した。この問題は、予算の都合上、チームが顧客の元から戻ってきたときから始まった。Asad氏によると、彼らがソフトウェアを届けようとすると、顧客は巨大なエラーリストと再発した欠陥を持って戻ってきた。Asad氏は、プロジェクトにおけるもうひとつの大きな問題は、リモート開発だったと述べた。開発者はみな家から仕事をしていて、アサインされたバグが新しいコードベースで解決されたのか、彼にはわからなかったと言う。
顧客がバグリストを送ってくると、私はそれを開発者に送ります。開発者はバグを解決して（あるいは、解決したと見せかけて）、私に新しいソースを戻します。私はそれをコンパイルして、パッチの当たったバージョンを作るのです。
チームがアジャイルに従っていなかったのか、あるいは、アジャイルに正しく従っていなかったのかが議論になったが、Asad氏はプロジェクトを救い出す提案を求めていた。
Mark氏は、現在のプロジェクトを救うには、大量の受け入れテストを書いて顧客にリリースする前にテストを走らせるとよいだろう、と提案した。これはシステムにある技術的負債にも大きく依存するのだが、届けられるソフトウェアが適切な品質にあるのか確認するには、完璧な方法だ。
Roy Morien氏は、この状況の基本的な問題のひとつは、ソフトウェアをテストして、バグが解決されたことを確認する責任にあるようだと言う。もし開発者にその責任がなかったのなら、彼らは修正された保証のないコードを返すだろう。
もしテストをする責任があなたにあるのなら、実際のところ開発者には仕事が正しくなされたのか確認する動機はないだろう。おそらく確認をあなた任せにして、「くそっ、それで動くと思ったのに。明日までに直しておくよ！」と言うにちがいありません。いつ彼らはそのバグを修正する仕事の対価をもらえるのでしょう？
Roy氏はまた、Asad氏は新しいソフトウェアを集めてテストしたら、すばやく適切なフィードバックを得るために顧客のところでデモするべきだ、と提案した。
Bachan Anand氏は、正直なコミュニケーションの重要性を強調した。彼によると、チームがプロジェクトを救いたいなら、今すぐ積極的に行動すべきだという。
起こったことは起こったこととして、これを解決できる唯一の方法は、まず起こったことを受け入れてから解決策を探すことです。したがって、最初のステップは、プロジェクトの現状について顧客にはっきりと伝えたあと、何よりもまず顧客にとって受け入れ可能なプロジェクトの救済策を考え出すことでしょう。
Pete Ruth氏はプロジェクトを救済する包括的戦略をまとめた。Pete氏によると、顧客はソフトウェアはすばやく費用効果の高い方法で修正できると納得したいのだという。彼は過去に役に立ったテクニックのリストを次のように提案している。
- 顧客のところに「キーとなるユーザ」を配置する。
- リモートアクセス設備を設置する。そうすれば、顧客のところでソフトウェアに何が起こっているのかを見ることができる。
- キーボードショートカットやソフトウェアスイッチによって特別なテスト機能を実行できるよう、ソフトウェアの変更を検討する。リモートアクセスが使えないなら、これは問題を特定するのに役立つだろう。
- あなたと離れたところにいる開発者との間で、リモートアクセスソフトウェアを使うことを検討する。
- ソフトウェアをモジュール化して、重要な機能を分離、集中させることを検討する。
- コードをできるだけ再利用可能にして、ソフトウェアの複雑さを最小限にする。
Jeff氏は、すべてを離れたところにいる顧客や開発者のせいにするのは、単に言い訳を探しているにすぎない、と言う。彼は分散した状態にあるプロジェクトを複数完了させて、すばらしい結果を得たそうだ。真の解決策は、チームと組織の両方が成功するために専念することだ。
このように、議論に参加した人のほとんどは、分散開発を問題であるとは見ていなかった。離れたところにクライアントがいることやリモート開発を行うことは、問題ではないという意見がほとんどだった。分散開発が苦痛なのは、正しく実施できていないことの症状にすぎない。離れたプロジェクトを成功させるために重要なことは、正しいツールを使った正しいアジャイルプラクティスの実施を強化して、成功するために専念することだ。