偉い人のスクラム。そして、現場のスクラム

以前、数百人のエンジニアを抱えるマネージャーと話す機会があった。その人は全体的にスクラムを導入したけど、なぜかうまくいっている気がしていないという。その理由を聞いてみると、こんな話をしてくれた。

偉い人のスクラム

彼の組織は、スクラムマスターやプロダクトオーナーの役割を明確に決め、職能横断的なチームを作ろうと組織的にアジャイルを導入していた。もともと、トップがアジャイル開発に知見があったため、トップダウンでの導入はスムーズに進んだそうだ。

扱う開発規模が大きくなるにつれて、エンジニアもどんどん増えていった。足りないリソースはオフショアまで活用するようになった。すべてがうまくいっているように見えた。しかし、何かが変だと感じていたそうだ。

「教科書のような事例ですが、何か変な感じがすると？」

「そう、なぜかうまくいっている気がしないんだ。特に生産性。たしかにみんな楽しそうに働いてはくれている。でも、それが成果物につながっている気がしていない」

その人はそう言った。

現場のスクラム

その人と話から、その現場を想像した。

• ベロシティを考えてのプランニングでは、ベロシティにあわせて計画を立てるが、未達でどんどん目減りしていくので、やれることがどんどん減っていく。チームのコミットメント力が弱い。
• スマートなプロセスで開発に集中できる環境はできたが、その浮いた時間が有効活用されていない。会社に来なかったり、時間を守らなかったり、仕事以外の時間で浪費されている。
• 見た目が派手なＵＩ改善などが多く、地味な改善ができていない。優先度がビジネスにつながっていない。

なかなかひどい。

その後

しばらくして、風のうわさが聞こえてきた。どうやらその人の組織は、解体へと進んでいるそうだ。

そして、現場のエンジニアは全員異動になり、その人は会社を去ったらしい。