ちょっとagiliを導入してみて気付いたこと

いくつか面倒を見ているプロジェクトの内、プロジェクトの局面が変わってagiliを適用できるのではないかと思い、それとなく組み込んでみたときに気付いたことを書く。

伏線を張る
そのプロジェクトは、waterfallで考えると比較的短いスパンでリリースするようなプロジェクトに変わった。
わかりやすく言うと、システムをリリース後の“継続的な機能のリリース”フェーズに移った。
これまでの開発の経緯とこの機会を考えて、「あぁ、agiliの方が向いているな、やるなら今だな。」と思って、ちょっとずつagiliの単語や考え方を入れて助言することをはじめた。
つまり、伏線を張ったわけだ。

WBSは短く、アウトプットは早く
最初に手をつけたのは、WBSのタイムスパンの短縮
長くて1週間以内で“何らかの”アウトプットを出すようにWBSを変えたこと。
これまでも、WBSのスパンについては、短くするように助言してきたけれど、それを徹底するようにした。
大概、waterfallであっても1週間以上のタイムスパンの塊で線を引くような作業は、ロクなアウトプットが出ないことが多いので。
中間成果物にアウトプットできない人ほど、deliverableの品質に勘違いしていることが多いから手戻りのリスクが高い。
だからこそ、タイムスパンを短くして、且つ、短くしたWBSの作業の中のプロセスを分解し、どこをチェックポイント(＝マイルストーン)にするかを相互で認識を合わせておく。
これでもずれる人は、もっときめ細かくプロジェクトマネージャが見るようにアドバイスするしかないけどね。

決まった時刻に短時間で
次に取り入れたのは、daily scrumを決まった時刻にするようにしたこと。
これは、waterfallでもagiliでもコミュニケーションギャップがあったらどうしようもなくダメプロジェクトになるのでね。
決まった時間に、決まった内容をやる。
お祭り状態になったプロジェクトでも、架橋に入ったプロジェクトでも日々の定例で“全員集まって”やるのは、前日の成果確認、今日の予定、課題の聞き取りだけ。
ここの課題は、そのあとに“必要な人”だけに絞ってやる。
これは、agiliに限ったことではないけれど、ね。

意識を変えることは難しいからこそ
仕事のやり方を変えることはそれほど難しくないけれど、個々の意識を変えることは難しい。
他人には変えることは出来ないから。
だからこそ、変えようとしている“新しいやり方”を実践して、何か良いことを感じてもらえるように意識している。

WBSのタイムスパンを短くすることは、担当するひとがアウトプットをより早く実感できる効果があるし、顧客にとっても早く手に入れて使うことが出来る。
顧客からのフィードバックも早くなるから、顧客が喜んでもらえれば、担当者は、その喜びを早くフィードバックを受けられる。
これって、いいよね。
daily scrumもメンバ内の情報のタイムラグが今まで以上に解消されるから、情報のタイムラグから来るストレスが解消される。
これって、プロジェクトの中でのそれぞれのメンバが自ら孤立しない効果がある。
「わたしには直ぐに教えてくれない」という疎外感から、ね。

waterfallとagiliのブレンドプロジェクト管理って楽しいねぇ。