I added a third paragraph that might help with some insight as to why I feel this way.
Going the BDD (or TDD) route first can help you in many ways... They include: finding unintended bugs, ensuring code works the way you want always, helps convey code intentions to other devs, etc, etc.
If you found it was taking too much time, I would suggest you slow down a bit and really focus on BDD for a few weeks, you only get faster by practicing.
We do enterprise software without the enterprise bureaucracy - so adding in agile just takes it back that way.
Ultimately I dont recommend anyone forces themselves into agile/TDD/BDD methodologies. They are systems designed by people to fit their working practices and preferred approach - its impossible to force yourself efficiently into the exact same mindset as someone else...
The best approach is to pick and choose techniques and practices that fit your flow and develop your own way of working. You'll find it's vastly more efficient.
(we have a couple of teams who finish contract work for other companies who's agile techniques just screwed the timetables/delivery :) so I've seen the difference in action)
I added a third paragraph that might help with some insight as to why I feel this way.
Going the BDD (or TDD) route first can help you in many ways... They include: finding unintended bugs, ensuring code works the way you want always, helps convey code intentions to other devs, etc, etc.
If you found it was taking too much time, I would suggest you slow down a bit and really focus on BDD for a few weeks, you only get faster by practicing.