Another client approached me today about BDD and using tools like Cucumber to automate scenarios.

There are a few things I’d love to teams see develop as a focus before heading down the tools path. You may already be doing these things, and if you are, fantastic! You may find the tools helpful (and you may decide that you have enough benefits without them). Otherwise, these are things I would like to see in place first.

An eye on the big picture.

Who are the stakeholders? Who championed the project and who else has needs that have to be met to make that vision live? Answering this also helps teams come up with much smaller MVPs. It should help to define which scenarios are in and out of scope, and also tends to lead to better language and better appreciation of who to talk to to get hold of the scenarios in the first place. See Impact Mapping or Feature Injection, both of which are great for this. Also Tom Gilb’s work on “Evo”. And this blog post on capability planning.

The ability to question and explore.

I generally use two conversational patterns when talking through scenarios. Testers are extremely good at coming up with other scenarios we might have missed, stakeholders whose outcomes need to be considered, etc. Communication around the scenarios should not just be one-way.

The ability to spot and embrace uncertainty.

This is often the first thing that goes out of the window when people head down the tools path. If something has never been done before, it’s highly unlikely that the business will know exactly what they want. They might not be able to define all the scenarios. If the team hear that there’s uncertainty or conflict in requirements, rather than trying to nail it down, collaborate to try something out instead – spiking, prototyping, A/B testing, etc. The scenarios will emerge. This lets teams focus on risk.

(I’ll be talking on this extensively at Modern Management Methods (Lean Kanban UK) next week – please get in touch if you’d like my speaker discount code!)

Great relationships between people.

If people want to use BDD to understand how to help the business better, to help out the testers, or to help the developers code the right thing, then I want to see evidence that that desire to help genuinely exists. There are lots of small ways to help each other that don’t involve BDD. A focus on “stop starting, start finishing”, limiting WIP and helping each other finish off work and get feedback on it, is a good sign. A heavy focus on estimates, commitment and “sprint failures” is not.

If you have these things, go ahead and use the tools if you want to.

It normally takes a couple of weeks to a couple of months for teams to get the hang of the conversational side of BDD. During this period a lot of successful teams use the half-way house of just writing the scenarios down, perhaps on a wiki, where they’re easy to access and change. Some teams focus particularly on the scenarios which are unexpected or from which they learnt a lot, and that’s a good thing. I like to see devs writing the scenarios down if anyone does, as they can then play them back to the business afterwards, and it forces the conversations to happen.

Things I see when teams don’t have these and go down the tool route include:

The good news is that if you do go down the tool route and find this happening, it can be reversed fairly quickly by focusing on the conversations again.

In software development, tools should support your interactions, not define them.

If you’d like help adopting these ideas, I run a 1-day BDD course exclusively focused on the conversations, and a “BDD: Train the Trainers” course to help you run the same day in your organizations. The course is highly interactive and can be run remotely for up to 6 people, over 5 mornings or afternoons, depending on timezone. Reasonable remote support afterwards is included. Please contact me on liz at lunivore.com for details!