I've been using TDD/BDD at work for the last 12 years, I also teach and mentor teams on this subject. I've found that misconceptions and errors in this field are shared, and that most of us make the same mistakes.
Give me 45 minutes of your time, and I'll try to address the most common problems, hoping to improve your TDD/BDD situation as much as possible.
I'll try to solve: Long running tests problem, by bringing back the correct shape of test-pyramid with power of Hexagonal Architecture (Ports & Adapters) with practical examples in Spring. Miscommunication and lost art of requirement gathering, by focusing on readability, introducing just enough of Domain Specific Language, and sorting out what is important with the power of Spock. Difficult test setup and environment requirements, by using command and conquer, modularity, monitoring. And hopefully more.
Most teams that do not write tests first do it, because it's hard for them. I'll try to show you, how to make it easy. Real life examples included.
If you are not using TDD/BDD, this might also interest you - you'll know how to start the right way.