アジャイルソフトウェア開発チームは，開発した製品が十分な品質を持つことを保証しなくてはならない。一方でマネジメントからは，より多くの機能をより早くユーザに提供するために，ベロシティ(開発速度)の向上を同時に期待されることが少なくない。何人かの専門家が品質とベロシティの関連を検討し，その両方を向上するための方法を提案している。
Bob Galen氏は，開発速度を向上するという点におけるソフトウェア品質の重要性を，ブログ記事“Read my Lips - Agile isn’t Fast!”に書いている。
アジャイルは“品質競争”ですが，完全性や責任やバランスを競うならば，すばらしい“スピード競争”にもなり得ます。ただしそれ(スピード)は無償ではありません ...
もしうまくプレイできなければ，アジャイルを採用したことで，かえって以前のアプローチよりも遅くなってしまうかも知れないのです！
チームはそれぞれ，イテレーション内に作業を終えることに責任を持つ必要がある。それはつまり，終了の基準をすべて満足しなければならない，ということだ。
理ワークを認めるアジャイルチームが多すぎます – バグ修正や自動テストの充実，リファクタ，粗末な設計を次のスプリントに回しているのです。スプリント内に完了した作業と遅延作業を対比して把握する目的から，ほとんどのアジャイルツールでは，ストーリの分割が可能になっています。これがチームに誤ったメッセージを送っている，と私は思います。スプリントを越えた作業が許容されるという，誤解を与えているのです。
よく聞いてください (Read my Lips) - そうではなくて，すべてを完了-完了-完了，にするのです！
過度な開発速度を求めずに品質を重視すべきだ，と氏は説明する。
次回，アジャイルのスピードを誰かが話題にしていて，彼らの若い情熱がその限界を目指しているのを見かけたら，どうか彼らを止めてください。アジャイルは“スピード競争”ではないことを彼らに説明してください。そうではなく，“速度向上の可能性もある品質競争”であることを強調するのです。
Tim Ottinger氏は，アジャイルチームのベロシティに関する14の奇妙な法則について書き留めている。注目点のひとつは，品質とクオリティ間の関連性に関するものだ。
短期間で作業を終えるために品質を疎かにすることは珍しくありませんが，コードの品質が低ければ，すべてのスプリントのベロシティが低下してしまいます。
ブログ記事“Velocity is not a Goal or Target”ではStephen Haunts氏が，マネージャがチームのベロシティを目標にした場合の品質について説明している。
(...) 目標達成に向けて，より多くのポイントを提供するために，システムの品質を犠牲にすることになるでしょう。長期的にはチームの生産性を低下させ，技術的負債を生み出すことになります。開発するシステムやそのプロセス(継続的デリバリ，継続的インテグレーションなど)の品質，あるいはシステムを開発する人々の質を重視するべきです。
Blake Haswell氏が“What is Code Quality”で説明しているように，ソフトウェア開発者は，ベロシティと品質のバランスを保つ必要がある。
ベロシティ側に舵を切るように，外部から多くのプレッシャーを受けることも少なくありません。ですが品質に十分な注意を払わなければ，ベロシティが急激に低下して，プロジェクトは前のめりに倒れてしまいます。要件変更にいかに簡単に対応できるかは，プロジェクトのコード品質次第であることを考えれば，プロジェクトを維持するために，コードの品質に一定の時間を費やす必要があります。
コード品質の議論で用いるために，氏は品質的属性のリストを提供している。
- 理解が容易であること。 すべてのレベルにおいて，コードは理解容易でなければならない。理想を言うならばソフトウェアは，不備のないことが明確であるようにシンプルであるべきだ。
- テスト可能であること。 コードはテストが容易なように記述されるべきだ。
- 正確であること。 機能要件と非機能を満たす必要がある。
- 効率的であること。 システムリソース(メモリ，CPU，ネットワーク接続など)を効率的に利用する必要がある。
“The Symptoms of Low Internal Software Quality” と題したブログ記事では，筆者のHugo Baraúna氏が，ソフトウェアが変更によって“劣化”し，結果的に品質と開発速度が低下する状況について説明している。
あなたが新興企業の技術チームか製品開発チームを率いている，と想像してみてください。あなたはCTOです。製品の最初のバージョンはすでにローンチされて，成功を収めています。ビジネスモデルは認められ，今は成長段階にあります。すばらしい！ ですが，それにはコストが必要ですし，新たな課題も生まれます。
製品の初期バージョンは動作していますが，コードベースは今後必要になる形式になっていません。チームのベロシティは，今までのように良好ではなくなる可能性があります。コード品質に関する不満も変わっていません。CEOとプロダクトディレクタは新機能を要求していますし，現時点での予測ではビジネスニーズを満足できそうにありません。
その上で氏は，書き直しやリファクタの必要を判断するのに役立つ，品質低下を示す症状を一覧として挙げている。
- 何をやるにも難しい
- ベロシティの低下
- テストスイートの速度低下
- 解決できないバグ
- チームの意欲が低下している
- 知識の局所化
- 新たに参加する技術者の立ち上げ時間が長過ぎる
品質と開発速度のバランスを，読者はどのように取っているだろう?