スクラムは開発プロセス改善のための柔軟で適用しやすいソフトウエア開発手法と思われている。何年もの間、スクラムは多くの成功を納めてきた。しかし、スクラムを導入しても未だに硬直的なチームがある。スクラムに欠点があるのだろうか、それとも、スクラム導入に失敗したのだろうか。
Terry Bunio氏はスクラムへの手紙の中で、自身の体験を述べている。氏は当初、スクラムのプロセスとその成果物に惹かれたが、次第にスクラムの硬直さはプロジェクトの成功させるために必要な自由さをもたらしてくれないと感じるようになった。
私が必要としていたのは要求を見つけたときに、スプリントの最中でもその要求を追加できるようなプロセスです。また、振り返りの最中に議論を展開しようと感じたときに制約によって何もできないのは嫌でした。… また、私自身がスクラムマスターだと思われるのも苦痛でした。そう見られることで私のプロジェクトマネージャとしての価値は低くなり、価値あるチームのメンバではなく単なるプロセスの監督者と思われるようになってしまいました。もうチームのメンバではないように感じました。
Marek Blotny氏もデイリースタンドアップミーティングで同じようなことを感じた。氏は話す順番が来るまでチームのメンバが'固まる'のが好きではなかった。これでは自然発生的な知識共有が死んでしまう。毎朝、固まった15分の時間を取るのは役に立たない。価値ある議論が続き、チーム全体がその議論に巻き込まれているなら、15分以上議論が続けるべきだ。
デイリースクラムの硬直した構造を強制するのは意味があるのか。こう問われたら、ありません、と答えます。チームワークを促進する効率的で役に立つデイリースクラムがある一方で、すべてガイドブックにしたがう極めて硬直的な構造があるのです。
Rod Claar氏はスクラムが柔軟でも、スクラムの導入は硬直的になりやすいという。これは初めてでも正しく導入できるようになっているのが原因だ。Rachel Davies氏はスクラム導入の傾向について語っている。氏が言うには、
スクラムマスターやチームのメンバが"ガイドブックに従ってスクラムを導入"しようとしていると言うときは警告の合図です。スクラムはアジャイルソフトウエア開発への出発地点にすぎません。スクラムを実施するのがゴールではないのです。製品を継続的に提供するためにスクラムを実施するのです。スクラムという手法にどの程度従順かを確認する人はいません。
Geoffrey Wiseman氏はプロセスの硬さと敏捷性を図式的に対立させる必要はないと言う。スプリントが始まってしまえば、障害物は何もないということをスクラムははっきりと定義している。スプリントは計画と実装の最小構成要素であり、当然実践上意味のある柔軟性を持っていると考えられる。
これは厳しい見方でしょうか。ひょっとしたらそうかもしれません。このような制約の中で働けないのなら、スクラムを使うべきではないと考える人もいます。しかし、現実的にスプリントがめまぐるしく変わるリソースの状況に耐えられるでしょうか。私は耐えられると思います。
スクラムの硬さはそのチームがどの程度の硬さを望ましいと考えているかに依る。プロセス全体が破綻しないように制約を遵守するのはいいが、実際のプロジェクトの状況を無視して硬直さが広がればプロジェクトにとってもチームにとっても有害だろう。