ウォーターフォールに関するハーバード・ビジネス・レビューの最新記事

ウォーターフォールについて書かれている記事を見るたびに、どうせ批判的なのだろうと読み飛ばしてたが、いわゆるIT系のニュースサイトではなくハーバード・ビジネス・レビューが書いているのは、ちょっと気になる。

AgileFall is an ironic term for program management where you try to be agile and lean, but you keep using waterfall development techniques. It often produces a result that’s like combining a floor wax and dessert topping.

アジャイルやリーンを使おうとしてるのに、ウォーターフォールのテクニックを使い続けることをAgileFallという用語で呼ぶようだ。床ワックスとデザートのトッピングの組み合わせのようなものだと書いてるが、要するに気持ち悪い組み合わせだということだろう。

Over the last few months we’ve helped him inject the basic tenets of Lean into these projects. All are Horizon 1 or 2 projects – creating new features for existing products targeting existing customers, or repurposing existing products, tools, ortechniques to new customers.

この記事の筆者は多くのプロジェクトにリーンのtenets(教義)を導入する支援をする立場だ。Horizon1はMcKinseyが分類した概念のひとつで、すでに確立したビジネスを効率化する領域。Horizon2はコアサービスを置き換えようとする領域。そしてHorizon3は未知の領域へビジネスを広げようとする領域。このHorizon1-2のプロジェクトでAgileFallを目にしたというのだ。

Teams only checked in – wait for it – every three months in a formal schedule review. I listened as the client mentioned that the teams complained about the volume of paperwork he makes them fill out for these quarterly reviews. And he was unhappy with the quality of the reports because he felt most teams wrote the reports the night before the review. 

チームは3ヶ月ごとにレビューする。3ヶ月分のレビューだから量も多いし、それを突貫で作ってるから質も低い。

More importantly, we decided that he would focus these conversations on outcomes rather than reports. There would be more verbal communication and a lot less paper. The reviews would be about frequent delivery, incremental development, and how leadership could remove obstacles.

というわけで原則を見直し、最低でも月1で実施するよう見直すわけだが、もっと重要なのは回数ではなく方法を見直し、デリバリをどうするか、どう障害を取り除くかといった結果を重視するよう切り替えること。

なんだかスッキリしなかったが、方法論ではなくアジャイル・マニフェストに書かれている「プロセスより個人との対話」「ドキュメントより動くソフトウェア」を振り返ることが重要だということだろう。

この記事が気に入ったらサポートをしてみませんか?