パイロットアジャイルチームが成功すると、アジャイル導入のプロセスが正しい方向に向いていると思い込みがちだ。Dave Nicolette氏が、試験的な試みが大成功した後で、導入に失敗した状況について興味深い洞察を示す。
Dave氏は、最初のケーススタディを観察した。そのケーススタディは、試験的な試みが非常にうまくいき、チームは「非常に生産性の高い」状態に達していたが、その後、考えられないようなことが起こった。
IT管理部門は、すぐにアジャイルグループの「主導権を握り」ました。一週間で、(a) 技術チームを顧客と共にオンサイトに置くというプラクティスを止めました。(b) アジャイル実践者たちを従来の組織の周りから追い払い、影響をなくすようにしました。(c) 組織内の重要なアジャイル提案者たちの悪い結果を示すパフォーマンスレビューを作り、会社を辞めるように仕向けました。試用中の状態にされ、辞めるように圧力をかけられた人たちもいました。(d) 何人かの成績優秀な人たちは、比較的重要ではないレガシーアプリケーションのお守をするという先の知れた仕事を割り当てられました。これも、辞めさせようとする戦術です。(e) ウォーターフォールのプロセスを再構築し(ほんの少しアジャイルのバズワードで飾り付けて)、社内の顧客にプロジェクトを納品する唯一の方法としました。1年後、「アジャイル」という言葉以外、何も残っていませんでした。
同様に、Dave氏が示した 2番目の例では、アジャイルコーチやコンサルタントが立ち去るやいなや、社内のアジャイル専門家たちは、コンサルタントがやって来て、チームが非常に生産性の高い状態になる前に従っていたプラクティスを再び主張し始めた。社内の専門家たちは、試験的な試みの成功に貢献する社外のコンサルタントたちに恐怖を感じていたのだ。そのため、コンサルタントたちが立ち去るとすぐに、自分たちがしていたことに戻したかったのである。
似たようなことで、Dave氏は他の例を挙げた。非常に成功した顧客として紹介する一人とは、再び仕事をすることがなかった。その理由は、示唆に富むものであった。
チームは、顧客の組織よりもずっと早いペースで仕事をしていました。顧客はバックログを素早く更新していくことができなかったため、チームは有意義な仕事ができませんでした。顧客はあたふたとストーリーを作りました。そうすれば、チームがぶらぶらして何かをするのを待っていることに対して、時間給を払わなくて済みますから。この経験は、顧客にとって非常にストレスが多かったため、顧客は自分たちがアジャイルには向いていないと思い、従来の手法と従来のサービスを行う会社へと戻りました。
では、これらの非常に成功したケーススタディが、成功していない理由は何だろうか?
Dave氏は、以下の2つの主な理由を挙げた。
- ローカルプロセスの最適化 – パイロットチームは、組織の他の部分とは切り離されていた。組織の他の部分から孤立して働き、パイロットプロジェクトが終わるとすぐに、大海のさざ波は静まったのだ。ローカルレベルの変化が大きすぎて、組織の他の部分では多くの摩擦が引き起こされたのだ。
- 感情的な要素に対する無関心さ – コンサルタントは、個人や部門のサポートを忘れていた。彼らの取り組みがあれば、成功を長続きさせる手助けとなっていただろう。この結果、コンサルタントが去るとすぐに、これらのサポートグループは、一緒になって以前の仕事のやり方に戻ろうとした。
人々は、完全に普通の人がするように反応しました。アジャイルの取り組みを押しつぶせるようになるまで我慢し、素早く、確実につぶしてしまったのです。「無知に罰を与え」、アジャイルグループに参加した人が黙って座りこむか、会社を辞めるようにしました。
成功の法則は、変化に耐える顧客の能力に合わせて、変化のペースと協力の必要性を調整するところにあるとDave氏は提案した。このようにすれば、初期のプロジェクトが成功するのにさらに長い時間がかかるが、アジャイルへの変換は、長い期間、成功するだろう。
人的費用を考えずに突っ走ることは、結局のところ、成功の定義にはなりません。非常に高い生産性という贈り物を持ってくるコンサルタントに注意しましょう。