開発者にアジャイルを強制するのは、危険信号

開発者にアジャイルを強制するのは、危険信号だ（Imposing Agile Is A Very Red Flag）とマーチンファウラーが書いた。
http://martinfowler.com/bliki/AgileImposition.html

要約すると、

アジャイルを管理者が押し付けてはならない、それは、 「プロセスとツールよりも、個人と対話に価値を置く 」という価値にも反するし、その背後にある原則である、 「動機付けされた人たちを中心にプロジェクトを構成する。彼らに環境と支援を与え、彼らが仕事を成し遂げることを信じる」、そして、「最高のアーキテクチャ、要求、そして設計は、自己組織化されたチームから創発する」 にも反する。

というのだ。

チームは自発的にウォーターフォール型の方法を選ぶことだってできる。その場合、アジャイルではなくなるだろが、アジャイルはもともと万能ではないのだ。私は、強制的にアジャイルを押し付けられたチームよりも、自分自身でウォーターフォールを選らんだチームがよいと思う。

うんうん、そうだそうだ。

ところがこの意見に、Kent Beck/Cynthia Andres が反論（ではないが）して、MLでちょっとした議論になっている。
http://tech.groups.yahoo.com/group/extremeprogramming/message/123271

Kentは、

管理者が「アジャイルをやろう」と言い出したっていいじゃないか。「個人と対話」というアジャイルの価値は、チームが管理者やCEOともよい関係を構築すべきことを示唆している。管理者からアジャイルを言い出してもいい。そこから対話が始まるはずだ。ソーシャルチェンジは、企業のどこからだって起こるはずだ。

というのだ。これも正しく、「どこから始まるか」は問題ではなく、その「対話の過程」が重要なんだ、かならずしも「ボトムアップで」やらないとうまく行かない、というものでもないはずだ。

ぼくも、アジャイルやプロジェクトファシリテーション、見える化をあちこちで話たりコンサルティングしているが、「やらされ感」をどうやってなくすか、が一つのテーマとなっている。ぼくは、いつでも、

• 最初に導入の目的をはっきりさせること。（上位目的レベルで「にぎる」こと。同意できなければ、さらに同意できる上位目的方向に登る。）
• チームの問題認識プロセスから参加型で始めること。
• その過程で、アジャイルやプロジェクトファシリテーションの手法を１つの解決策（オプション）と考えること。

を導入の肝としている。これによって、押し付けではなく、「対話」が最初に起こるように、また、納得感、の中で進められるように注意をしているつもりだ。

さて、現実うまく行っているかどうか、はフィードバックによるしかない。

常に「衝突」と「対話」が起こるのが現場だ。衝突を恐れては前に進めない。しかし、上位目的で合意していれば、安心して対話に持ち込めるのではないか。You vs. Me でなく、Problem vs. Us、「問題対私たちの構図」どうやってするかだ。意見がぶつかったら、「そもそも、こういう目的だよね」ということ、その目的がWin-Winである(Win-Loseでない)ことをお互いで確認し、再度衝突しよう。何か「私たち」にとっての解が見つかるはずだ。