遅延とは、一般的に言えば、作業の実施が予定よりも後になることであり、それによって不満や作業が苦しみが生まれ、関係者に迷惑をかける。同じように、アジャイルプロジェクトでも遅延という言葉は無駄と考えられている。遅延はプロジェクトの流れを断絶してしまうので、再学習やタスクの変更などの更なる無駄を生み出す。
Jack Milunsky氏はいくつかのありがちな遅延について、その原因を下記のように列挙している。
- 事業認可 - 事業に認可がおりるのを開発者を抱えながら待つと時間とお金の無駄が生まれる。
- 正式な優先順位がついた要求リストを待つ - 仕事を始めるために。
- リソースが使えるようになるのを待つ – これは組織が働きすぎていないかどうか振り返るサイン。
- 承認プロセスの変更– これ自体が無駄。頻繁に発生するようならスプリントを短くしたほうがいいかもしれない。
- 仕掛かり作業の増加- 仕掛かり作業が増加すればするほど、開発者はコードを作業結果に反映できるようになるまで待たなければならない時間が長くなる。
- 顧客の受け入れテストが完了の遅れ – テスト完了だけではなく、要求の定義やデモのフィードバックなどでも顧客側が原因で遅れることがある。
Jack氏はスプリントの間にも様々な種類の遅延があると説明している。チームは少し力をいれて遅延を特定し、根絶すべきだというのが氏の意見だ。曰く、
バックログが適切に整備されていることを確実にしなければなりません。そのためには、市場や顧客について理解しているプロジェクトオーナの強力が不可欠です。しっかりとしたロードマップを書いて、開発者から早めに見積もりをもらい、プロジェクトオーナが企画会議に先立って意思決定できるようにする必要があります。こうすることはプロジェクトの仕組みから遅延を排除することに他なりません。こうすることでひとつの作業から別の作業へスムーズに移行できるようになります。また、作業の始まりと終わりを把握しておいて、その間に遅延があるかどうか特定することには価値があります。
同じようにWouter Baars氏もITプロジェクトでのよくある遅延について下記のように述べている。
- 金メッキ–顧客から要求されていない機能の実装に多くの時間を費やしてしまう。
- 品質管理の無視–時間的余裕がないとプログラマやチームはテストを省こうとしがちだが、テストを省くと結局、テスト行ったとき場合よりも遅延がひどくなる。
- 同時に数多くのプロジェクトで働く–作業をスイッチすることは利点よりも問題点の方が多い。
- ‘すべて同じ方法で解決できる’シンドローム–新しい問題にも従来の解決策を適用しようとしてしまう。
- 未熟な人々–技術力の不足や不十分なプロジェクト管理能力は様々な水準で遅延を生み出す。
- 顧客との取り決めが履行されない–顧客が関係しなければならない作業のときに、適切なタイミングで反応を返さない場合、プロジェクトは停止してしまう。
- 顧客と開発者との間の緊張–プロジェクトが十分な手続きを経ていないと、顧客と開発者の間の緊張関係が更なる遅延を生み出す。そして、互いの信頼関係や作業の雰囲気が悪くなる。
遅延の理由については、他にもRobert Neri氏がエンタープライズ分野へのアジャイルの適用の難しさも遅延を生み出すことがある、と指摘している。曰く、
よく出くわすのはプロジェクトを支援する組織がスプリントと同じ速度で動くことができずに、アジャイルプロジェクトが遅れがちになるという事態です。同じようにアジャイルでないプロジェクトをアジャイルプロジェクトに統合するのも時間がかかります。
あなたのアジャイルプロジェクトで遅延が発生したら、その原因を上述したような一般的な遅延の原因とつきあわせてみてはどうだろうか。原因が特定できたら、すぐに解決にむかった方がいいだろう。そうすればプロジェクトでの最大の無駄を削減できるはずだ。