アジャイル・ボストン・ユーザグループ(Agile Boston user group) は先週，OpenSpace カンファレンスを終日開催した。記者はその中のひとつ，自分および／または自チームの組織に所属する，他グループに対する影響力行使に関するセッションに出席した。そこでは参加者たちが，それぞれの状況と問題について理解し合った結果，事態を改善するための複数の戦略を見出すことができた。その中にアジャイルのプラクティスは含まれていない。まずはセッションで紹介された状況の中から，いくつか紹介しよう。
- 私は複数のチームで作業しています。あるチームは旧式のウォーターフォールを，別のチームはアジャイルを採用しています。スプレッドシートを使用しているチームもあります。チームの仕事には依存関係があるため，この方法の違いがしばしば問題を引き起こします。さらに悪いことに，それらが世界規模で分散してるのです。
- 私たちのチームはこの５年間，アジャイルを実践して，うまく行っています。ところが関係するチームが他にあって，率直にいって彼らはうまく仕事をこなせていないのです。配送は良好なのに，セールス部門はとんでもない契約ばかりを取り付ける，といった具合です。
- 私たちには２つのチームがあって，関連性の強いプロダクトに関する作業をしています。私たちは，彼らの仕事に依存しています。彼らはウォーターフォール的な方法で作業していて，何をするにも，やたらと慎重です。彼らと一緒では効率的に作業できそうもないのですが，政略的な問題もあって困っています。どうしたら彼らをまともにできるでしょうか？
セッションの進行につれて私たちは問題を共有し，打ち解けた雰囲気の中，実行可能な解決策について議論をした。それぞれが自らのストーリーを語るごとに欲求不満が持ち上がり，"どうして他のグループは原因が理解できないんだ ?!" という感想が繰り返された。驚いたのは，同じ問題を抱えている参加者が多かったことだ。それでも他グループとの共同作業を続けなければならないのは，私たちの成功が彼らにかかっていて，彼らの向上なしには私たちの発展もあり得ないからだ。セッションで起こった共通のスレッドは，次のようなものだ。
- 多くのチームが互いに反目し合い，共通の目標を持てないでいる。彼らはビジネス上の成果に関係なく，自らの成功を主張する。
- ほとんどすべての場合において，いわゆる "我々 vs. 彼ら" という考え方が見られる。
- 他を変えようという試みは，徒労に終わる。
これらの問題についての議論の大部分が TDD やイテレーション，さらにレトロスペクティブ(retrospectives/振り返り)にも関連していないのは，すべての障害の発端がチーム以外にあることを考えれば，驚くことではない。しかし "他を変える/説得する方法" のアドバイスがないことについては，多少の驚きがあるだろう。実際に，参加者の多くがそれを試して，失敗した経験を持っていた。今回のミーティングで私たち - 参加者 - が得たアイデアをいくつか紹介したい。これらはアジャイルのプラクティスよりも基礎的なものであり，成功する可能性も高いと思われる。
- 他を変える方法ではなく，自分が実行できることを探そう。私たち自身どうすれば変わることができるか，他のグループについて理解を深めるにはどうすればよいか，彼らに何を望めばよいか，を問うてみるのだ。
- 目標を共有するための対話を始めよう。ひとつのチームだけが成功することはあり得ない。チーム個別の成功を越える目標を見いだせなければ，私たちは部分最適に陥ってしまう。
- 他の人たちを '私たちと彼ら' ではなく，私たちと同じように尊重に値する存在とみなそう。私たちはみな，不誠実を感じる術を知っている。'あなた方は間抜けだから，私たちが直してあげよう' といった考えに基づく行動が，肯定的な結果をもたらすことはあり得ない。
- 他のチームとの信頼を構築しよう。小さな同意の実績を積み重ねて，信頼の歴史を築くことだ。信頼に必要なのは a) 能力，b) 実績，そして c) 誠意 なのだ。
グループとして見たとき，これらの問題こそが失敗の核心である，と思われる。そして，私たちが成功するのに不可欠な個人の成長(私たちの変化)，あるいは誠意，信頼，明確な目標共有，といったものは，アジャイルのプラクティスで補えるものではないのだ。