アジャイル初心者の多くは、スクラムでアジャイルをはじめる。スクラムには明確な指針、ルール、プラクティスがあり、チームにアジャイルを導入するのに役に立つ。ところがスクラムもまた組織の中でさまざまな問題に直面し、多くの会社にとって成功を難しくする一因になっている。スクラムをやってきた人たちは自問する。どうすればよいのだろう？ スクラムだけで十分なのだろうか？
Jimmy Bogard氏は、なぜスクラムをやめたのか、なぜ彼のチームはスクラムで成功した後、そのコアプラクティスをいくつかやめることでパフォーマンスを改善できたのかについて、次のように説明する。
イテレーションはpullベースのアプローチほど効率的ではない。
タイムボックスで仕事をすること、割り当てて空きを埋めることには、何かしら心理的影響があります。明確なタイムボックスのイテレーションをやめて、できる限り早く納品することにのみ注力することで、私たちは大幅に納品を改善できました。
イテレーション計画ミーティングはムダだった。
確かにイテレーション計画ミーティングは有用でしたが、それにかけた時間に見合うものとは言えませんでした。私はミーティングの席につきながら「ソフトウェア開発をはじめちゃいけないの？」と思っていました。
代わりに、ほとんどすべてがJIT化されていました。設計はアーキテクトとプロダクトオーナーがやって、見積りは技術リードとアーキテクトが協力してやっていました（実際のところ、大きな新規案件があるときだけでしたが）。ストーリーが用意できると、ボードに貼られていきました。開発者が開発に取り掛かれるようになったら、アーキテクトと開発者でストーリーについての簡単なミーティングが開かれました。
スクラムは確立された組織を大きく乱す。
スクラムを組織に強制すると、特に開発チームから、失敗する可能性が高いです。すでにやったことを改善することにフォーカスして「レガシーコードで効果的にやる」のには、スクラムの“File –> New Organization”というアプローチよりもカンバンの方がよいと思います。
スクラムは納品にフォーカスしていない。
私にとって、スクラムとリーンソフトウェア開発などとの大きな違いは、プロセスにフォーカスしているか、納品にフォーカスしているかです。リーンは価値を届けることにフォーカスし、それを実現するための独自の方法を発見するというアプローチを提供します。これに対して、スクラムはプロセスのフレームワークであって、このアプローチにしたがわないと失敗すると教えます。
彼はスクラムの好きなところについても言及しているが、フレームワークの気に入らないところについて、次のように述べている。
スクラムの気に入らないところは、どこでもうまくいくと思っていることです。そんなことはありません。もしスクラムがうまくいかなくても、それはあなたの組織の問題ではありません。それはスクラムの問題なのです。
Francisco Aquino氏はコメントで、スクラムについてこう述べた。
スクラムは自己破壊的な手法で、みんなが何をすべきか、いつすべきかを知る機会を殺します。そして、プロセスは障害や頭痛の種になります。あなたが遭遇したのは、おそらくこれでしょう。
Ryan Cromwell氏はこう付け加えた。
本来、pull/flowベースのシステムとスクラムのフレームワークは競合するものではありません。私が仕事をしたチームでは、スクラムのなかで完成したフィーチャを出荷していました。そこではタイムボックスによるメリットとして、イテレーションを使って残りのビジネスを予測していました。
J.B. Rainsberger氏はこう注意した。
少し注意させてください。あなたがもはや土台を必要としなくなったからといって、あなたにそれが必要なかったというわけではありません。イテレーションは土台の役割を果たします。これは規律づくりにも役立ちます。もちろん無意味な進捗ミーティングになることもありますが、そうなったのはルールのせいではなく、それをやっている人たち自身のせいなのです。
この記事はHacker NewsやDrupal Groupsでも議論を呼んだ。Fingerprinter氏はこうつけ加えた。
100名ほどのスタートアップ企業で、まったく機能していないエンジニアリングチームを立て直すという仕事を引き受けたとき、（彼らについて学習するために少し観察してから）私が最初にしたことは、スクラムを取り入れることでした。スクラムはうまく機能しました。本当に、本当にうまくいきました。
それから2年後、スクラムはもはや機能していませんでした。チームは成熟し、組織はもっとリーンなプロセスや考え方を取り入れていました。時がたつにつれ、スクラムプロセスにしたがうのはやり過ぎになってきたのです。また変わるときがきたのです...
Adrian Howard氏はマネージャによって作られたアジャイルとスクラムについて次のように答えた。
2000年になって、アジャイルは人気が出ました。多くのチームを改善するのに役立ったからです。やがて人気の悪影響が現れてきました。猫も杓子も、間違ったやり方でアジャイルをはじめたり、すでにやっていたことにアジャイルという名前を付けはじめたのです。ほとんどすべてのアジャイルメソッドは開発者に由来します。なかでもXPは開発者由来のプロセスであり、開発者にとってどうすればうまくいくかを観察した結果できたものです。Ditto CockburnのCrystalメソッドでは、スプリント期間中にマネジメントを入れないため、スクラムは非常にうまく機能しました。（これは失敗の一因にもなりますが、それはまた別の議論です）
Sirktree氏はスクラムの利点と効率について、次のように考えている。
アジャイルやスクラムの真の利点は何だろう、と私はたびたび自問します。ミーティングは貴重な時間を無駄にすることがあります。開発者に「今週やらなくてはならない仕事はこれだけです」と期待させることで、開発者を非効率にしてはいないでしょうか？ たくさんのことをスケジュールするというオーバーヘッドは、実際の進捗の邪魔になってはいないでしょうか？
現在やっているプロジェクトのひとつでは「公式な」スプリント計画をしていませんが、結果的にたくさんの仕事ができました。しかし、これはプロセスのクライアントへの可視化を犠牲にし、ごく短期間で立ち上げなくてはならないというストレスをかなり高めます。
James O'Sullivan氏は、Scrumbutは必ずしも悪いことではないという興味深い回答を投稿した。
必ず本にある通りにスクラムをやらなくてはならないのか、何年も議論されてきました。ある意味、これは正しいと思いますが、すべてがそうだとは思いません。ここで言っているのは、スクラムを不完全に導入することではありません。チームはその準備ができたら、スクラムの先へと進化できるということです。ただし「その準備ができたら」というところが重要です。
はじめてスクラムを導入するときには、本にある通りに全てやることを強くおすすめします。助けてくれる熟練したスクラムマスターも雇いましょう。スクラムはシンプルなフレームワークですが、だれかを3日間のコースに派遣すればエキスパートになって戻ってくると思っているなら、どう見ても考えが甘すぎます。アジャイルコーチを雇って、新たに養成したスクラムマスターと一緒に仕事をさせてもよいでしょう。これは非常に重要です。独りよがりではいけません。もしアジャイルに真剣に取り組むなら、どうか真剣に考えて、相応の人を雇って教えを乞うてください。
スクラムはアジャイルの旅路の出発点であることを忘れてはいけません。終着点ではありませんし、成功する唯一の方法でもありません。
またDave Rooney氏はこう注意した。
私はプラクティスについて「実用主義的な」チームをかなりたくさん見てきました。彼らは簡単なプラクティスだけを選んでやります。しばらくはスタンドアップミーティングをして、3週間のサイクルで仕事をするかもしれませんが、彼らはふりかえりや真の職能横断チーム、ビジネス面から優先順位付けしたバックログなどから恩恵を得ることはありません。たいていの場合、しばらくするとプラクティスを全部やめてしまいます。アジャイルに約束されていた利点を、ひとつも体験できないためです。当然ですよね。
さて、スクラムはアジャイルの補助輪なのだろうか、いくつかのプラクティスを落とすことで、チームはスクラムの価値を損うのだろうか？ もし前者であるなら、その土台ができたとき、チームはどうなっているのだろうか？