BDD Before The Tools

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 team ends up producing the wrong thing (which is now hard to change, because automation also cements it in place).
  • The team often stop having conversations altogether, as the business or BAs start writing scenarios down ahead of time and passing them to the devs, losing the ability to spot any misunderstandings.
  • Innovation is stifled and the scenarios start to become used as “contracts” for what the devs produce, creating an “us and them” culture, undoing all the good work of Agile, and pushing risk towards the end of the project.
  • Any schisms which were there before are hugely magnified, and the team are now starting to head down a Waterfall path, only with lots and lots of scenarios instead of lots and lots of paper
  • Sprint planning meetings take 4 hours.

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 for details!

This entry was posted in bdd, complexity, stakeholders. Bookmark the permalink.

6 Responses to BDD Before The Tools

  1. sarah says:

    Liz, check out this talk by New Relic. They are one of our customers and are doing a lot with BDD & Cucumber

  2. sarahfos says:

    Liz, Check out this slideshare by New Relic. They are one of our customers and doing a lot with BDD and Cucumber.

    • Liz says:

      I like that presentation very much! Particularly, making the code change to encompass the complexities of the scenarios, rather than changing the language of the scenarios.

  3. Pingback: Using BDD with Legacy Systems | Liz Keogh, lunivore

  4. Pingback: Resources on BDD (Behavior-Driven Development) | XP123

  5. Pingback: More Agile Testing > Test Automation – Test Retreat

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s