振る舞い駆動開発(BDD)のプラクティスは，一般的に推奨されているプラクティスに反することが少なくない。Joe Colantonio氏は共通する6つの問題を指摘した上で，氏自身の経験やBDDの思想的リーダとの議論を交えながら，これらを改善する方法について解説している。
BDDが実装に拘束されないこと。GUIボタンのように実装の詳細を含めてしまうと，メンテナンスは困難になる。ユーザの振る舞いの“How”ではなく，“What”に注目すること。シナリオを命令的ではなく，より叙述的に書くのもひとつの方法だ。BDDに実装の詳細が含まれてしまう理由のひとつは，チームがコラボレーションツールとしてではなく，テスト自動化のフレームワークとしてBDDを理解しようとしている点にある，というのが氏の考えだ。
自動化はBDDの副産物であって目的ではない。これについて氏は，ビジネスやユーザ側の人々とのコラボレーションが失敗するのは，BDDツールをテスト自動化に使うアンチパターンの時である，というSeb Rose氏の発言を引用する。2008年にBDDツールのCucumberを開発したAslak Hellesøy氏は，Cucumberが何よりもまず，チームメンバ全員の共通理解を目的としたコラボレーションツールであることを強調している。Cucumberのフィーチャ(feature)は，それを実装するコードより先に書かれなくてはならない。BDDを取り上げた書籍の例に従って作業するならば，回帰テストは副産物であって，テストはアクティビティではないのだ。
会話が何よりも重要である。Colantonio氏の考えるBDDのメリットとは，誤った仮定や誤解を回避し，コードを記述する前に潜在的なバグを発見するチャンスを手に入れることだ。要件を書き留めることよりも会話を重視することを，新たな事実と受け止めるチームもあるかも知れない。しかし氏は，BDDおよびアジャイルに移行中のチームに対して，シナリオを要件として扱うべきではない，と指摘する。
シナリオは要件ではない。関連性はあるが，シナリオの集まりの一形態が要件なのだ。Colantonio氏は，シナリオを要件として扱うことによってさまざまな問題が発生することを指摘するとともに，Gojko Adzic氏が“Specification by Example”などの著書で説明しているような，プロダクトオーナとの議論から小さなサンプルを作り上げるBDD的手法の方を推奨する。
UIテストに固執しないこと。 シナリオはユーザの視点から書かれているが，それは必ずしも，機能テストをUI経由で実施しなければならないという理由にはならない，とColantonio氏は指摘する。アプリケーションUIの内部をコンポーネント単位でテストした方が，実行も速いし，脆性も少ないのだ。Konstantin Kudryashov氏は今年初めの記事で，BDDをドメイン駆動設計(DDD)とともに用いることによって，UIをターゲットとするシナリオの数を削減できる，と論じた。最初にドメインの動作を証明することで，追加が必要なのはUIクリティカルなシナリオのみになる。
スクラムの実施が，必ずしもアジャイルの実践を意味する訳ではない。スクラムを行うことで，アジャイルを実践していると考えるチームは多いが，Colantonio氏は，これが必ずしも事実ではないと考えている。コードを書いた後でユニットテストを記述したり，あるいは別チームなどが受け入れテストや統合テストを後付けで作成したりするのは，チームがアジャイルアプローチを実践できていないことの兆候だ。