> Saving Agile with BDD and Cucumber
First value of Agile Manifesto:
"Individuals and interactions over processes and tools"
First value of Agile Manifesto:
"Individuals and interactions over processes and tools"
> "Individuals and interactions over processes and tools"
Right. That means processes and tools should serve individuals by supporting their interactions, rather than individuals and their interactions being reformed to fit preconceived processes and tools. That doesn't mean that processes and tools are irrelevant, or that sharing experiences and ideas about how particular processes and tools can serve individuals in their interactions is contrary to Agile.
(In terms of promotion of processes and tools, it really has nothing directly to do with whether or even how those things should be promoted: it does have a lot to do with how -- and who on -- teams should evaluate processes and tools that are being promoted, though.)
Having not yet read this interview (did you?), I'm willing to give the benefit of the doubt that he identifies some problems with Agile teams that COULD be solved with BDD and Cucumber (for teams that want and choose this approach)
It's just a special case of the general problem with tools that aim to be easy for non-programmers to use while doing the same things as programming languages. It's always a leaky abstraction.
I've found it very useful, where there's ambiguity about how a particular feature works, to write a Gherkin spec that describes it. It's easy to understand, and can be agreed upon or even edited by my colleagues who aren't developers, but remain part of a CI process.
YMMV, but this remains one of the lazier dismissals of BDD.