企業がソフトウェア開発へのアジャイル導入を望む理由として挙げられるのが，提供までの期間の短縮だ。InfoQの記事(evidence of success of agile projects) で取り上げた Columbus Agile Productivity Benchmark Project など，アジャイルプロジェクトの開発短縮を示す調査結果も発表されている。開発速度を向上するためには，アジャイルをどのように使えばいいのだろうか？
Matthew Heusser氏の "Who says agile development can't be faster? " と題したブログ記事には，氏が Agile Testing Days カンファレンスで行った議論の内容が公開されている。
2012年11月にドイツのポツダムで開催されたAgile Testing Daysにおいて，"Agile Testing: A Practical Guide" 著者のLisa Crispin，Janet Gregory両氏は，"アジャイルとは迅速さである" というのは誤りだ，という大胆な主張をしました。
カンファレンス後にJanet Gregory氏が，その発言の意味について氏に説明してくれた。
アジャイルで重要なのは速さじゃない，と彼女は言いました。副産物としてそうなのかも知れないが，今この瞬間はそうではない，と言うのです。(...) アジャイルに移行することで，少なくとも一時的には遅くなるはず – それも，１週間や２週間ではなく，場合によっては１年や２年になるかも知れません。
これに対して氏は，アジャイルを使えば速くなると考える理由をいくつか挙げて反論する。そのひとつとして説明しているのが，なすべきことを行って実行する価値のない要件を省くことが時間の節約につながる，と言う点であり，もうひとつが "古い手法はどれも速くない" という理由だ。
(...) アジャイルを始めて１年でまだ成果を上げていないチームと，それができている従来手法のチームとを比較するのが，そもそも間違っています。１年では，従来手法のチームでも何の成果も上げられないでしょう。12個半の要件を片付けて，やりかけの仕事が残るくらいがせいぜいです。
両氏の意見に同意できない理由を述べた上で氏は，アジャイルがチームを迅速にすると思う理由を説明して，このブログ記事を結論付けている。
ひとつの疑問が残ります: アジャイルは速いのでしょうか？両氏はそれを大した問題ではない，と主張するかも知れません。短期的に純粋なスピードに注目することは作業のショートカットにつながり，長期的に見れば苦痛とパフォーマンス低下をもたらすことになる，と言うのです。しかし私は，無駄を取り除くことに注力して速度を向上し，プロセスを改善することは可能だと信じています。
Chris Turner氏は Making agile go fast と題するブログ記事で，アジャイルプロジェクトのパフォーマンスが上がらない理由について考察している。氏はそこで頻繁に見られる４つの原因を指摘し，それらに対処する方法を紹介する。
- 不適切なメンバ – エンジニアとしての規律に従えない，あるいは物事を複雑にしようとするような人たちを，チームから除外すること。
- プロセスの優先 – オープンなコミュニケーション，自己組織化，権限を持ったチームを確立すること。
- 誤った技術の適用 – チームに技術決定権を与えるとともに，デリバリの障害となる技術選択の破棄を許可すること。
- 複雑過ぎるアーキテクチャ – リファクタによってソフトウェアを可能な限りシンプルに保つこと。
Neil Killick氏は自身のブログ記事 "sustainable pace - the Fastest way to deliver software" で，アジャイルチームにスピードアップを求めるとソフトウェア開発が遅れるのはどのような場合か，ということを解説している。そこで取り上げているのは，２週間のSprintで平均10ストーリの作業能力を持ったアジャイルチームが，作業するストーリ数の拡大を求められる，という話だ。
今このチームに対して，Sprint毎にただ１つのストーリをこなすように依頼したとします。(…) 断言はできないにせよ，その１ストーリは間違いなく実施される，と予想することは不自然ではないでしょう。それも極めて高い品質であることは，おそらく間違いありません。
(...) では，Sprint毎に処理するストーリの数を2つにしてみましょう。チームがその２ストーリを完了できることはまず間違いないのですが，確率としては，１ストーリを依頼したときに比べればわずかに小さくなっているはずです。つまり私たちは，予測可能性を少し失ったのです。
では次に，契約納期に向けて悪戦苦闘していて，”スピードアップ”を強いられているような状況を仮定してみましょう。そんな状態のチームに，予想処理数を10ストーリから12ストーリにするように依頼します (つまりキャパシティを越えた訳です)。それとも14にしましょうか？(...) チームの作業を "もっと速く" するように依頼する (もっとひどい場合は「言い渡す」)ことによって，ソフトウェア提供の予測性が下がるとともに，おそらくはその品質も低くなるのです。
氏のアドバイスは，チームが一定のペースを守って仕事することを認める，というものだ。
(...) チームに対して，彼らのキャパシティにおいて高品質のソフトウェアを提供できる，適切なバランスを見つけることを認めれば，成功のサイクルが完成するのです。