Adopting BDD is hard.

It’s not that the tools are difficult to use: they’re already great on many platforms and fast improving in others.

It’s not that the technology is unproven: there are many examples of successful projects implemented using BDD.

Adopting BDD is hard because people aren’t perfect.

Everyone has their own agenda, and their own priorities. The product managers must write stories. The project managers must deliver stories. The devs must add features as quickly as possible. The QA’s must find as many bugs as possible.

Wait, what?

What we measure defines us

Our ultimate goal is to deliver working software that does what a customer asks. But often individuals are judged on quite different metrics.

If a developer is implicitly judged on their ability to add features quickly then anything that causes them to slow down whilst they learn new testing skills will naturally fall to the bottom of their priority list.

If a QA’s personal goals are all about the number of test cases they check for, then they’re unlikely to be able to make the analyst switch and drive the quality of the project from the front.

If we’re not helping our team look good with a suggestion, then we are going to have to work much harder to win them over. If the team is the atomic unit of success then we stand much more of a chance of being heard.

I wish I was the project lead!

It’s common for team members to wish they could become the lead on their team, because then they’d be able to change things and do it properly! Right?

Let me burst the bubble: leads have no more intrinsic ability to drive adoption than the rest of us. In fact, it’s worse for them, because everything they suggest is viewed with added scrutiny as a potential fad.

Sure, a lead could try and mandate a switch to BDD, but that’s not going to work. Here’s a newsflash: the only people we can control are ourselves.

If leads try to control people in the switch to BDD, at worst they’ll get a flat out rebellion. At best, they’ll get “mannequin BDD”: a team that goes through the motions but loses its soul, and delivers none of the benefits. We’ve all seen how that worked out for mandatory large-scale Agile switchovers.

How to give BDD a chance

Adopting BDD is hard. To give it the best chance on your team, try the following:

  • Make your team look good. If we make our case in a way that devalues other team members (“look! BDD will mean we don’t need QA’s anymore!”) then it’s unlikely to garner wide acceptance. “Saving people’s time” is a good benefit, and eventually it will happen in practice, but “finding more bugs” and “shipping better software” focuses on making our team look good, rather than making them feel superfluous.

  • Prove it. Show your team that it works. They won’t want to invest their time in something that they can’t trust. If we are able to demonstrably prove success at a small scale on our own work, then our peers are more likely to attempt to learn it.

  • Get out of the way. Sometimes we’re working with people who are difficult to approach with new ideas if they haven’t thought of them themselves. In these cases, we’ll need to tread softly. We might not get to take the credit, and we might need to humbly reconcile ourselves to that. After all, we’re trying to introduce BDD to make our project better, not for personal praise and glory. Right?

Have you been through a BDD adoption process? How did you find it? What helped the practices take root in your team?