「ウォーター・スクラム・フォール」はイケていないプロジェクトを改善する手段です
ウォーターフォールとスクラム。スクラム界隈の人の以前の（一部の）言動を思い出すとどうにもウォーターフォールvsアジャイルの対立構造を作ろうとしているように見えて、正直そんなのどっちでもいいから
「プロジェクトマネージャとしては楽してプロジェクトをキャリーできるノウハウの本質を知りたいんだけど」
なんて思っていたものです。
いつも書いていますが、プロジェクトなんて唯一無二なわけで、プロジェクトごとにシステム開発手法だってプロジェクトマネジメントだってテラーリングが必要なわけです。それを一律どっちがいいなんて決め付けてしまうことは損だと思うわけです。やりたいことを実現するために合法で円滑にやれるなら手段選ばず、でしょ。
で、「ウォーター・スクラム・フォール」です。
これ、なんとなくワタシが感じているのは、
なコンテキストなんですよ。
ワタシ、
「あまりイケていないウォーターフォールだからこそ、ダメなままじゃダメなのでスクラムとかカンバンの要素を取り入れて改善しようよ」
と思うんですが。
だから、ウォーターフォールで上手くいかないプロジェクトの原因が作業負荷だったので、WIP(work in progress)が可視化できるようにカンバンを入れたのとチケットシステムをいれてプロジェクトマネージャが指示した作業を逐次記録できるようにしたんですよ。それでcsvで引っこ抜けば進捗報告にも使えるしね。
さらに言えば、KPTだってやらせたもの。最初はファシリテーションして定着するまで面倒を見て。
「ウォーター・スクラム・フォール」ってさ、見る人の観点でというか、解決したい要件でどっちにでも捉えられるんですよ。少なくともワタシは後者なんです。
それで１つプロジェクトを救ったし、そのあとも事故予防の観点からお勧めしまくりです。お勧めすればするだけ現場は増えるし亜種は増える。でもいいじゃないですか。プロジェクト自体が唯一無二なんだから。
それよりも１つでもプロジェクトを思い描いたようにキャリーして欲しい。それを「ウォーター・スクラム・フォール」でできるならそれも選べるよと言いまよ。
