変更は普遍的なものであるにもかかわらず、人は変更に対して不安を抱く。 この場合、未知への不安や安心感の喪失に対して抱くことがほとんどで、変更の受け入れを難しくする。 アジャイル・チームは変更に対して十分な態勢が整っているとはいえ、彼らの大部分は変更の影響がチームに及んだ場合、それを快くは思わない。
Dean Johnson 氏は Scrum Development グループでディスカッションを立ち上げ、チームからメンバを外す際の危険性について議論している。 氏は自身のプロジェクトの複数のスプリントにわたり、VP によってチームのメンバを引き抜かれたことがあり、このディスカッションはその経験に基づいている。 Dean 氏によると、これには次のような否定的な影響が伴うと言う。
- チームのリズムが乱れる。
- チームのペースが崩れる。
- チームの「結束力」が損なわれる。
このような問題があるにもかかわらず、ディスカッションの回答では、「現在のビジネスや市場の状況において、チームの変更は避けられない」とするものがほとんどであった。 チームはそのような変更の影響を建設的な方法で最小限に留めるよう努力する必要がある。 Jack Milunsky 氏は次のように述べている。
とはいえ、優先順位の変更などは付きものです。したがって、このことを企業のもっと広いコンテキストに照らし合わせて考える必要があります。 私なら、チームとのミーティングを設けて、リソースが欠けることによる影響を話し合います。 移動可能なメンバを何名か移動し、それ以上管理できないものや先に進めることができないものを優先順位から外します。
Chris 氏は、スクラム・マスタが変更を促進するうえで必要となる点をいくつか挙げている。
- 以前のチームでよかったと思う点や今のチームで変えたほうがよいと思われる点にてついて、ミーティングのときにチーム全員に対して聞く。
- 質問や懸念事項に対応できるようにしておく。
- チームで外に出かける。 チームをランチに誘い、ベテランのメンバの隣に新しいメンバを座らせるようにする。
- スクラム・マスタとして、新しいメンバが新しいチームにどの程度精力的に適応しているか確認するために、何らかの形でチームの全員と一対一で話す時間を設けるようにする。
Alan Dayley 氏は、変更による問題を最小限にする最善策の一つとして、「スプリントが終わるまでチームをそのままにしておくこと」を勧めている。 チーム・メンバの追加や離脱は、スプリントの初めや途中よりもスプリントの境目のほうが影響が少なくなる。
この方法を実行することにより、現行のスプリントの結果は確保できます。 また、両チームの後続のスプリントを明確に計画することも可能です。
Mark Levison 氏は、「既存のチームにメンバを追加するには、適切な統合も必要になる」と述べている。 チームの新しいメンバは、既存のコードベースに慣れる必要がある。また、新しいメンバによってコミュニケーションの複雑さが増し、その結果、チームの構成が乱れる。
Mark 氏は、変更による影響を最小限に留めるための興味深い方針をいくつか提案している。
- メンバを追加するには遅すぎる段階にプロジェクトが差しかかっている場合は、チームへの追加を断る。
- 段階的なチーム・メンバの追加によるコストを削減するために、新しいメンバの投入を一度にまとめて行う。
- 新しいメンバとベテランのメンバを組み合わせてチームを編成する。
- 新しいメンバに対して、チームのやり方に慣れてもらうために、単体テストや自動化された受け入れテストのリファクタリングおよび作成を依頼する。
- 新しいメンバを他の開発者とペアにする。
このように、チームの変更は必然的である。 重要なのは変更に適応し、プロジェクトを前に進めることによって、影響を最小限に留めることである。 結局、アジャイル・チームの目的の中心は、利害関係者のビジネス・バリューを最大化することにある。 Gary Brown 氏は次のように提案している。
あなたはこの話を聞きたくないと思うかもしれませんが、このチームのメンバはあなたの子供ではないのです。 ひどいことを言っているように聞こえたら、おわびします。 先ほど述べたことについてもう一度説明しますが、あなたとそのチームは、ビジネス・バリューを可能な限り最大化し提供するために、毎日職場に来て賃金を貰っているにすぎないのです。 ビジネス・バリューとは、彼ら (VP) が言うところのものであり、あなたが考えるものとは異なります。 彼らの良きパートナーとなり、 約束を果たし、 また綿密に調査し、上手く適応してください。