In short: BDD at the coding level (AKA BDD-style TDD) is possible and valuable for any team: benefits include fewer bugs, more focused development activities and great technical documentation for your APIs in the form of well-written and well-structured unit tests. But it is at the requirements level that the real benefits of BDD become obvious: more relevant and more valuable features, a better shared understanding of the requirements, fewer misunderstood, misaligned or forgotten requirements, less waste, more efficient use of tester time, etc. These benefits hinge on collaborative discovery of the requirements, which is very hard to do in a prescriptive software development approach where the requirements are "completed" and "signed-off" before being handed to the development team for implementation. Similarly, the role of the tester is handicapped if she can only intervene at the end of the process, or to automate regression tests. So in essence, BDD without the ability to collaborate on requirements discovery is somewhat ham-stringed.
I think I'll just lie down here for a second. And ponder this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop