続・Agileでうまくいかないとき

Agileでうまくいかないときと同じ著者による続編をまたまた適当に翻訳。

Allan: More Agile failure modes

ちょっと前にAgileでうまくいかないときという話題を取り上げたけど、その後いろいろ考えているうちに、さらに二つの失敗状態があることに気づいた。(気づいた、というのは変な言い方かもしれない。失敗するパターンを見つけた、というべきか。)
一つ目は、開発者達が「俺たちAgileやってるぜ」と宣言するだけの状態。名付けて「なんちゃってAgile」。Agileだと宣言する事で、文書作成は無視できるし、プロジェクト管理も回避しちゃうし、ハックし放題。
正直言ってこれはAgileではないし、Agileやってる人には迷惑だ。こういう人達の中にはAgileでやりたいというのも混じっているのだろうけど、きちんと理解し、ちゃんと経験を積まないと、Agileしていくってのは難しいものなんだ。
格言：　Agileだと宣言すればAgileできるわけではない。
こういう事例もある。ある開発チームがTDDでやろうということになった。でも、誰もTDDの経験がない。三週間経っても、そのチームがTDDを始めた徴候はでてこなかった。で、これはそのチームが悪いわけじゃない。TDDしたいけど、どうやればいいか知らなかった、という事だ。
考えてみろよ。車を運転するために色々習ったでしょ？　スキーもしかり。ワインの楽しみ方もそうだ。大学での研究もそうでしょ。もちろん、やると決めてすぐ始めることもできる。そして、運が良ければ、あるいは自分がすごく賢ければ、その新しい事をたちまちできるようになるかもしれない。自分がプログラミングを始めたときみたいにね。
でも大抵の場合は、何か新しい事を始めたい場合には、支援や助言が必要なはずだ。
初めてTDDをしたいのであれば、その教育や訓練を行ってくれる人を手配する事をお勧めする。そうすれば、物事は進み出すはずだ。
二つ目の失敗事例はちょいとややこしい。この失敗の仕方は過去何度もみてきているし、Agile失敗現場の多くで共通しているんじゃないかな。こんな感じだ...
あるチームがAgileを始めようとしている。同時に、そのチームは新しい技術も採用しないといけない。チームが初めて手にする技術かもしれないし、市場に投入されて間もない(あるいはベータ状態)の技術かもしれない。あるいは、全くの新技術かもしれない。いずれにしても、そのチームは新しい技術を学ばないといけない。
つまり、新しいプロセスと新しい技術との両方があるわけだ。
最初のヤバい徴候はカード枚数の爆発だ。チームはイタレーション開始時にやらなければならない作業をカードに記録していく。が、イタレーションが進行していくにつれ、当初の作業見積りが足らなかった事が明確になってくる。作業時間も作業項目も、後からどんどん増えていってしまう。
(参考: タスク爆発検知のためにはカードとホワイトボードを使う方がいい。ツールを使うと、タスク数が爆発している事が隠れてしまう可能性がある)
進捗が捗々しくない時、開発担当者は「このカードは80%完了」というかもしれない。Agileにおいては、80%はゼロとされる。終わったか、終わってないか、このどちらかしかないわけよ。
新たな作業が発覚し、チームはより多くのカードを書く羽目になるかもしれない。その結果、カードの枚数が爆発していく。作業を進めていくうちに、予想よりも遥かに多くの作業があることがみつかっていくわけだ。これらの作業をカード単位に分割していくわけだから、そりゃ枚数は増えるわな。ホワイトボードに無理矢理貼付けるために、カードを半分に折っている現場なんてのも見た事があるよ。
こういう状況に対応する方法の一つは、新たにカードを書いて、より頻繁に優先度付けをしていくことだ。
もう一つのやり方は、時間制限制度だ。制限時間を設け、開発者はその時点で作業を打ち切る。できるまでのことはやってもらう、ということだ。
三つ目のやり方は、探索方式だ。新しい技術を(通常は時間制限をかけて)探索し、それから本来の開発作業に着手する。これにより作業分割が楽になる。
ただし、これらの３つのやり方はAgile上級者向けだ。上級者からなるAgileチームは、自ずとこれらのやり方を実施するだろう。だけど、そうじゃないAgileチームではうまく対応できず、しいてはプロジェクト失敗につながるだろう。
新しい技術が導入されるプロジェクトはAgileである・なしに関わらずぐちゃぐちゃになって失敗する可能性がある。採用される新技術はどれくらいの深みがあるのか見えてないし、調査習得に要する時間は多いのが普通だ。古典的プロジェクト計画管理であっても、問題にぶちあたるはずだ。
Agileの長所は、そういう問題をプロジェクト後半ではなく、プロジェクト早期に摘出できる事にある。でも、チームがAgile初心者で構成されていると、その持ち味を出せずにプロジェクトは失敗する可能性があるし、「Agileが悪い」と言われる事にもなるかもしれない。
対策は...自分にもわからないんだ。プロジェクトによっては、どう管理しても失敗する事ってあるしね。
対策があるとすれば、助けを求める事かな。Agileやったことがある人か、新技術を使った事がある人をチームにいれる事だ。教育や研修も役に立つ。Agileや新技術の教育、ね。
ここから得られる教訓ってなんだろう？　Agileってのは意外と難しい、ってことかもしれない。Agileするというのは、本を一冊読めばオッケーというものではない。何冊も本を読んで、多くの人と話をして、経験を積んだ先人達と一緒に仕事して、教育や研修を受けて、何度も挑戦して、それでもやっぱりダメだということもあるかもしれない。
Agileするってのは簡単ではないんだよ。

補足

Agileは確かに簡単ではない。
というか、ソフトウェア開発自体、そもそも簡単ではない。
そして、上記お話にもあったように「新しい要素」が入ってきたプロジェクトは特に難しい。
探索的要素が伴う以上、確定的計画を立てるプロジェクト計画管理方式では歯がたたないか、プロジェクトが著しく肥大するのは確か。