複数のプロジェクトにわたる安定したチームを持つことは、アジャイルソフトウェア開発にとってプラスになる。安定したチームがあると、プロジェクトの開始時に新しいチームを作って終了時に解散するのではなく、仕事は既存のチームに対して作られ与えられる。だが、もし安定したチームが期待通りに機能しない場合には、どうすればよいのだろうか？ 安定したチーム作りとその育成について、また機能不全なチームの対処について、さまざまな人がブログに記事を書いている。
Joe Little氏は「we want a stable team」というブロク記事で、安定したチームを持つことは重要だと考える理由について説明している。
(…) すばらしいプロダクトを考え出すためには、何か特別なものが必要になります。私は最近、この「特別なもの」というのは、すぐれたチームから生まれる可能性が高いと思っています。したがって、ビジネスマネジメントの観点から（納得しなきゃいけないのはマネージャですから）、安定したチームは必要なんです。
Joe氏は、チームにはビジネス側の人間と技術側の人間の両方が必要だという。そうしたチームで仕事をするのは、楽しくて満足感があるはずだという。もしすばらしいチームができているなら、それをキープするよう彼は提案する。
（すばらしいチームは）5倍から10倍よい仕事をします。 (…) これは金の卵を生むガチョウです。 (…) 満足のいく仕事を与え続ければ、それを変える必要はないかもしれません。
安定したチームのためには、仕事の作り方を変える必要がある。
もう、プロジェクトから始めて、プロジェクトに取り組む人を探すのではありません。チームから始めて、チームにとってよい仕事を探すのです。
Everett Zufelt氏は「building teams & avoiding dysfunctions」というブログ記事を書いた。そのなかで彼は、チームの機能不全と育成方法について調べている。彼はまずチームを定義することから始めている。
(…) ただ同じプロジェクトに取り組む人の集まりと、共通の成果に向かって取り組むチームとの間には雲泥の差があります。チームは共通の目標に気を配って、チームのエゴのために自分のエゴを犠牲にするのです。
クライアントにより多くの価値を届ける強いチームを育成するには、チームメンバーがお互いのことを知る必要がある。Everett氏は仕事をする人と知り合うようになると、いかにチームの育成が簡単になるかを説明している。
最近、私たちは「安定した」チームという目標を立てました。これはシフトや変化をしないチームを意味しているのではありません。チームの大きさと構成における変化に注意を払っているということです。ほかにも利点はありますが、安定性というのは集団としての成果に気を配ることのできるチーム作りの重要な部分だと思っています。
Roman Pichler氏は、安定したチーム作りのおすすめを紹介している。彼はまず、安定したチームを求める必要性について説明している。
チーム構成を頻繁に変えることは、個人と組織にとって望ましいことではありません。チームが活躍するには、安定性が必要です。アジャイルの世界では、市場、要件、技術が頻繁に変化しますが、安定したチームは安全性と継続性をもたらします。
プロダクトのリリース内およびリリースを越えて、チームに対する変化を最小限にするようアドバイスする。
チーム構成を変更すると、チームビルディングのプロセスをまた最初から始めることになります。それによって、生産性と自己組織化が損われます。 (…) チームメンバーの大部分がプロダクトに取り組み続けられるようにしましょう。そうすれば、情報のロスや欠陥、遅延が避けられます。
Kelly Waters氏は「the value of stable teams」という記事で、安定したチームをサポートする組織体制について説明している。彼女はそうした体制を作ることがいかに価値あることかを説明している。
シニアマネージャとして、開発チームに対して最もやるべき価値あることの1つは、安定したチームを可能とする組織体制を作ることです。ずっと続くチームを、プロジェクトのために集められて、新しいプロジェクトを作るために解散させられるチームではなく。
Kelly氏は、チームビルディングにおける「成立期、動乱期、安定期、遂行期」というステージについて説明している。チームがこうしたステージを通過するにはある程度時間がかかる。
いきなり意気投合し、途中少しだけ緊張もあるでしょうが、非常にすばやくこのプロセスを通過するチームもあります。これに対し、動乱期からずっと抜け出せず、本当にチームとして動けるようになるまで、かなり時間のかかるチームもあります。
組織として、安定したチームをどのようにサポートできるのだろうか？ Kelly氏は最初から届けられる製品を取り上げる。
(…) チームを特定のプロダクトやプロダクトポートフォリオに合わせるのが一番です。そうすれば、毎回チームを再構築する必要なく、最適化済みの関係、プロセス、ベロシティという利点を活かして、プロダクトからプロダクトへと一緒に動けます。人をプロジェクトにアサインし、毎回新しいチームを作るのではなく、プロジェクトを実績あるチームにアサインするのです。
Steve Martin氏は「the dysfunctional agile team member」という記事で、チーム構成の変更方法について書いている。まず彼は、場合によっては、チームからメンバーを外すという選択肢も検討する必要があると説明している。
(…) クライアントの多くはチームの入れ替えを望んでいません。それは聖域です。「チームは変えられないんです。これが私たちなんです。ほかにはいません。以上。」私だったらこう言います。「チームを変更できます」。いいえ、だれかを解雇すればいいと言っているのではありません（とはいえ例外的に、こういうはっきりした行動をとる場合もあります）。そう、チームメンバーの組み換えは頻繁にやるべきことではありません。でも場合によっては、チーム、ステークホルダー、そして顧客の利益のために、チームメンバーを入れ替える必要があるのです。
Steve氏はチームの変更を検討するのに、各メンバーの能力と意欲のマトリックスを使っている。
能力とは、コーディングスキル、テスティングスキル、ビジネス分析スキルなどの「技術的スキル」とアジャイルの価値と原則の実践を指しています。意欲とは、スキルの「人間」部分 – コラボレーション、変化への対応、フィードバック、（専門家としてでなく）1つのチームとしての仕事をすること、など基礎となるアジャイルの価値と原則をいかにオープンに受け入れ、賛同しているかを指しています。
最優先なのは、能力と意欲を合わせ持つチームメンバーだ。能力は低いが意欲の高いチームメンバーは、ペアと一緒に技術的スキルを養うことができる。能力は高いが意欲の低いチームメンバーには、意欲を高めるために個人的コーチングをしてもよいし、チームメンバーではなくてチームのコンサルタントにしてもよい。能力も意欲も低いチームメンバーについては、チームから外す必要があるか検討しなくてはならない。
結局、能力も意欲も低い人には、最初から腹を割って話をしなくてはなりません。たとえ最初のスプリントであっても、こうした人たちにはチームから完全に抜けるよう頼みます。こうしたやり方はマネジメントから非常にネガティブに反応される場合がありますが、時間がたてば、特にチームが機能するようになってくれば、そういう反応もなくなります。