I had a bit of a chat with Eric about Shallow Kanban. The idea with Shallow Kanban is that you’re doing the basics – visualizing the workflow, improving collaboratively, limiting WIP, making policies explicit, etc. – but perhaps only some of them, or just doing it within your team and not looking more widely at your company, business and IT risk, and how you can contribute to the company’s overall goals. You might get considerable improvement, but there’s plenty left to do.

“It’s like people who say they’re doing BDD, but they just use Cucumber to automate scenarios without actually talking to anyone,” Eric said.

“That’s not Shallow BDD,” I replied. “That’s not BDD at all. In fact, if they do that, they’ll probably run into trouble. Shallow BDD is when you just have conversations around scenarios, and you’re not capturing the scenarios or trying to automate them. You’ll get considerable benefit from that, and there’s plenty more to look at, but it’s a good start.

“If you’re not having conversations though, you’re not doing BDD at all. You might be doing Acceptance Test Driven Development… but we always reckoned that if that was done well it would look like BDD, and if you’re not having conversations, you’re not even doing ATDD well.”

In this post, I’m going to call out two common anti-patterns I’ve seen with BDD adoption, and suggest some ways of deepening it that might help avoid them.

Anti-pattern 1: The BAs* get bored.

* By BA, I mean “someone who can analyse that aspect of the business” – might be a PO, domain expert, or user.

• The team starts by having conversations.
• The BAs write the conversations down. The devs automate the scenarios.
• The BAs get bored with having the conversations, so they start writing the scenarios in the tool ahead of time.
• The devs go back to misunderstanding the scenarios (less than before BDD, but more than when they were having conversations). They’re also now translating the steps that the BAs have written into ones that they already have, so they can automate them more easily.
• The BAs are also spending more time coming up with scenarios, so they don’t like it when the devs show them that something can’t be done easily.
• The devs take on work regardless of how easy it is. Conversations about alternatives never happen. It’s harder for the business to change their mind, because of all the scenarios.
• Innovation is stifled. Everyone is sure there must be a better way but can’t see how.

Anti-pattern 2: The Devs get bored.

• The team starts by having conversations.
• The devs write the scenarios down and automate them.
• The devs get bored with having the conversations and start writing scenarios themselves.
• This seems to be working! Planning meeting times have now gone down. There are fewer conversations.
• The BAs no longer care about the scenarios. They’re happy because the planning meeting times have gone down too.
• The devs deliver the wrong stuff. And it’s hard to change, because of all those scenarios they were writing.
• The BAs lose trust in the devs, and they don’t want to read any of the scenarios because the feature files are boring and lengthy.
• Delivery is stifled. Everyone is sure there must be a better way but can’t see how…
• …unless they get the BAs to write the scenarios again instead.

Deepening BDD: Don’t Be Bored, Stop Pretending

• Find the places where the conversations are least boring. Focus on those. They’ll probably be the places where things are new and interesting, and where lots of discoveries will be made.
• If the BAs are uncertain about outcomes of scenarios, that’s a good call to try something and see what happens, instead of forcing them to be certain (see video “When Outcomes Don’t Come Out“). Good teams will always be looking for different ways to achieve an outcome, or possible scenarios that might go wrong, especially if it’s something new. That’s really hard to do if you’ve already decided what the scenarios are up-front and you have no chance to talk about them.
• If the conversation is getting boring, the chances are it’s something that the devs have done before. In this situation, it’s OK to let the devs go code something. The chances of getting it wrong are small. The chance of spotting wrongness quickly is big. A question I ask a lot in this situation is, “Is there anything different about X this time, compared to how it’s normally done?” That brings the conversation back to anything interesting. If there’s nothing different, there’s probably a library that will do it. This boring stuff is *very unlikely to change*. It probably doesn’t need regression testing, except for maybe some unit tests to help with the internal design. It needs isolating as a service or a well-defined module. It might need monitoring. It doesn’t necessarily need automated scenarios. Logging in, user registration or email gateways are all good examples of this.
• If you write the scenarios down, don’t use an automation tool for the first pass. Use a wiki. I recommend that the devs do the writing, then immediately send it back to the BAs for review, to see if there’s anything they misunderstood or missed out.
• Remember that BDD isn’t about testing; it’s about examples of behaviour. If you’re going to automate, think about whether you have enough examples. For instance, use a couple of examples of validation, rather than all 32 possible failures for that screen. Unit test the rest.
• Remember the pyramid. A small number of full-stack scenarios, some integration tests, lots of unit tests. The longer your tests take to run, the fewer of them there should be.
• Refactor your feature files, then use that to refactor your code and architecture. If a more boring scenario’s behaviour is covered in a more interesting scenario, delete the boring one. If there are too many scenarios, consider which behaviour might be boring and see if you can refactor that code into a service or well-defined module. It’s boring because it’s not likely to change any more. Make it so that you don’t need to regression test it, and delete the scenarios or move them to that new service.
• Towards the end of a project, all the pieces left ought to be low-risk stuff that just needs finishing off to get the product shipped. If you’re in that space, you won’t need to talk through scenarios so much. That’s fine; you don’t have to do BDD – but if you do do it, have the conversations! And next time round, see if you can ship earlier by focusing on what’s different and interesting.
• If your conversations are effective, you’ll find that they steer the project, saving you work, calling out risk, and helping you to build and architect your software appropriately. If they’re not doing this, look to see if the conversations you’re having are truly effective. If it’s not the conversations, look to see if there’s some place in the process where people are pretending that conversations have been had – writing scenarios for the devs, or vice-versa. Eliminating that, either by having conversations, or making them unnecessary, might help.

If you’re not having conversations, you’re not doing BDD.

The shallowest form of BDD consists of just having conversations around scenarios – not capturing them, not automating them, but just having the conversations.

If you’re not having conversations, you’re not doing any kind of BDD.