アジャイルソフトウエア開発はチームワークや共同作業、作業の適用可能性をプロジェクトのライフサイクル全体に渡って促進する。たいていの場合、市場に需要がある最小限の機能セットを持って市場に投入されるので、市場投入にかかる時間は短くなる。そして、新しい機能の実装が各イテレーションから滑り落ちて、製品はいつまでもベータであり続ける。
継続的統合や継続的生産のような実践は製品のライフサイクルに影響を与え、組織をより俊敏にする。Tim O'Rielly氏が言うには、
...オープンソースの格言、"はやめのリリース、しょっちゅうリリース"は、実際にはより過激な立場である、"永遠のベータ"へと変形しています。この立場では、製品はオープンに開発され新しい機能が、1ヶ月毎、1週間毎、場合によっては1日で組み込まれます。Gmail、Google Maps、Flickr、del.icio.usのようなサービスが長年の間"ベータ"というロゴを背負と思われているのは偶然ではありません。
Project smartはアジャイルの方法論と永遠のベータは手と手を取り合って進むと指摘する。
元の設計通りにしたがってナットとボルトが据え付けられているソフトウエアを提供する代わりに、単純できちんと動作するバージョンを提供することで顧客の要求を満たすことが最優先です。"永遠のベータ"という言葉はアジャイルの手法にも適用されます。ソフトウエアを"あったほうがいい"機能がすべて実装されるまで各イテレーションで改善していくのがアジャイルの手法だからです。
Mike Loukides氏は製品を永遠のベータ版にしておくと、多くの重圧から解放されるだけでなく、創造性が促進されると考えている。氏によれば、
最初“はやめのリリース、しょっちゅうリリース”という言葉で公式化された永遠のベータという考えは、長年に渡って多くのオープンソースプロジェクトの成功要因になっています。
OutSystemsのアジャイルへの移行に関するホワイトペーパーによれば、アジャイル技法の要は反復的で漸進的なフローであり、これは永遠のベータと共通点がある。顧客もアジャイルチームのメンバなので、各イテレーションで小さな機能を加えることでシステムを形作るという作業を支援してくれる。
しかし、全員が永遠のベータという考えを気に入っているわけではない。37signalsの'Getting Real'はベータというタグを過度に使うこと、長い間使うことに対して警告をしている。彼らの考えでは、ベータにしておくことが貧弱なアプリケーションの言い訳になり始める前に、企業はどのくらいの間ベータのままにしておく必要があるのかを真剣に決めるべきである。
Jeff Atwood氏は永遠のベータという考えがとても不穏なものになりつつあると指摘した。氏曰く、
永遠のベータという考えはひょっとしたら最も不穏なものかもしれません。多くのウェブサイトがベータのままですが、こういう傾向は繰り返しジョークを聞かされているみたいです。
Mat Scales氏も永遠のベータについてコメントしている。氏が言うには、永遠のべータとは開発者の自信の欠如の現れに過ぎない。永遠のべータは開発者が革新的であり続けているということを明確に示そうとしない。そして、永遠のべータはアプリケーションには潜在的な課題があるかもしれないが問題ないということを示す信号でもある。
小さくリリースを積み重ねることは顧客や開発者にとっては有効だが、チームはどのくらいの間ベータにしておきたいか考えるべきだ。弱点を隠すために製品をベータにしておくのなら、“永遠のベータ”という考えはすぐに支持を失うだろう。