BDD: Before You Begin (Part 2/2)

If you’re a programmer starting to practise BDD, then you probably felt the impulse to dive straight into the various technology tools. If you follow this impulse, then you risk missing out on the single most powerful benefit of BDD: greater shared understanding of the features. I encourage you to start somewhere else.

Before you change all your test automation to SpecFlow, before you set up any hooks into your continuous build system, before you refactor your system to provide better APIs “just under the skin” for your feature tests to talk to… start by changing the way that you discuss features with your product owner and other stakeholders. When you talk to them, confirm your understanding by talking in examples. That’s enough to make a huge difference!

What does it mean to talk in examples? Let your product owner explain in their own words what they expect from this new feature. Let them use their own words; let them ramble on for minutes if they need to. They are often thinking through the feature while they’re describing it to you. Don’t interrupt them. Don’t worry too much about all the fine details just yet. Listen carefully and think about how you would judge whether the feature were working correctly as running software. Think of one example, any example, and then describe that example to the product owner in the plainest, most everyday language that you can.

“… OK, let’s see how well I understand you… so if I look to my right, pull that lever over there, then type 16 into that text field, then when I look at this LED over here, it should turn red. Yes? No?”

Your product owner will likely answer with a relatively quick Yes or No, but if you’re lucky, you’ll get the magic phrase: Yes, that’s it! (pause) Well… (pause) not exactly.

The Magic Behind the Magic Phrase

It might seem strange to want to be wrong, but the first great benefit of BDD comes from uncovering the differences between the picture in your head and the picture in their head. This doesn’t solve all your problems, but it solves a big, common, and important one!

When you talk to the product owner about features, it can feel quite reassuring to consistently agree. Every time the product owner says “Yep!” you might feel like you’ve taken another step towards a successful outcome. Unfortunately, agreeing too easily too often almost always signals one of two risks:

• Although you collectively agree on the broad strokes, you are not examining the features carefully enough to look for areas of disagreement. We might call this shallow agreement and it kills projects.
• You each interpret various words differently and so you agree on the words, but not on your respective interpretations. You might think of this as a special case of the preceding risk.

In the second case, you’re each “agreeing” to something different and in the first case, you’re not even looking to see where you might disagree! Both lead to continued failure in the form of unjustified optimism when you start building the feature and crushing disappointment when you finish.

When the product owner says “…not exactly…”—and especially when they pause for a few seconds before saying it—the next words out of their mouth usually describe some important detail that you need in order to build the right thing. Maybe several important details. And you’ll have more of those important details before you start building the feature, rather than discovering them after days or weeks of hard work, 30% of which you would throw away. The magic behind the magic phrase lies in uncovering clear areas of disagreement before you try to build any part of the feature at all. You don’t find every problem before you start, but you almost certainly find the obvious ones and you find more of them than you might have expected. This is one of the benefits that BDD is meant to provide.

If you want to turn these agreed-upon examples into automated tests, then do it, but remember that the conversation provides most of the value, so I encourage you to focus your energy there, rather than getting SpecFlow running as part of your continuous build.

Start Here, But Don’t Stop!

Talking in examples provides the average programmer with a way to not merely start “doing BDD”, but truly benefiting from the technique. More than that, this trick takes advantage of the typical programmer-y mind: programmers already need to think in examples as part of their programming work, so many of them have already developed the impulse to do this. I find that most programmers merely need a little push to do this when talking with “business people”. After all, an example is really only a test aimed at less-geeky people! Talking in examples has several advantages:

• You don’t need anyone’s permission to start doing it; you simply start.
• As you practise talking in examples, you improve at writing tests and as you practise writing tests, you improve at talking in examples. (Win-win spiral!)
• You don’t need to push it, but instead you can start gradually and do it more as you feel the benefits. There is no need to declare on Monday that “I shall now talk to you nice product owners in examples”. You try it without any extra ceremony and if it helps, then you do more of it until maybe one day it merely becomes “how we talk to each other”.
• Talking in examples acts as an icebreaker, in case you don’t have a strong personal relationship with the product owner. It provides a reason to talk more and more often with the product owner, which can lead to building trust over time. Customers often welcome my little discussions about features, because they feel confident that I want to understand them better.
• As you uncover areas of disagreement and fix them, you deliver something closer to what the product owner expects, which further builds trust over time.

These last two points matter most to me: building trust between the programmers and the product owner represents a key ingredient in successfully building software systems incrementally. Low trust tends to lead towards large, up-front specification documents that nobody understands. Litigation often follows. High trust leads to shorter feedback cycles, shorter feedback cycles drive down the cost of failure, and a lower cost of failure orients us towards simply correcting disagreements rather than feeling bad about them. When the feedback cycles shorten, “That’s not what I meant!” changes from a cry of annoyance to a cry of celebration. Congratulations! We saw the hole before we fell into it! We figured out that we were wrong before we tried to build it! This is one of the primary benefits that BDD is meant to provide.

In spite of all this, talking in examples is not magic. Even if you start talking in examples today and even if you stick with it for several months, you haven’t solved all your product problems and you haven’t “mastered” BDD. There’s more to learn: introducing real options thinking, hunting the value, improving the link between marketing and choosing features… but if you’re a programmer with the feeling that BDD could help you, then put SpecFlow down, stop thinking about Azure Pipelines (just yet), pick up your pen and paper, and try talking in examples. Just start there. Once it feels effortless to talk in examples, you’ll notice that something else has become the bottleneck in trying to build the right thing. It almost certainly won’t be that SpecFlow is slowing down your blue/green deployment pipeline. Let yourself improve one thing at a time.

J. B. Rainsberger works as an Agile Coach, but actually Agile and actually a Coach. He travels the world (most years) sharing what he’s learned about programming, managing his workload, and designing his lifestyle. He spends much of his professional time helping programmers do better work with less stress, but he also consults with and trains for companies. He helps clients cut through the confusion about Agile to its essence, so that they can realize the benefits that the modern Agile movement has been trying so hard to offer. He offers self-study training and coaches both individuals and teams in whatever they need to perform better. He lives in Atlantic Canada with his wife, Sarah.

Blog links:

• The Code Whisperer Blog for content mostly about programming
• J.B. Rainsberger’s Blog for content about everything else

References

J. B. Rainsberger, “Three Steps to a Useful Minimal Feature”. An example of talking in examples. Sure, I was talking with myself, but the examples gave my internal dialog structure that helped me in a variety of ways. It describes one style for writing scenarios/examples that programmers generally find easy to adapt to Gherkin syntax.

Mozaic Works, “BDD in Practice with Liz Keogh”. Adi Bolboaca interviews Liz Keogh, starting with BDD, but moving on to greater topics. Don’t break your brain! If you really need to focus on only talking in examples for now, then put this video into your “Watch Later” list, but do come back to it.

Markus Gärtner, “Shallow Disagreements”. Along with shallow agreements, we might also have shallow disagreements. The first of these describes appearing to agree without confirming that we are using the same words to mean the same things; we might find ourselves appearing to disagree for similar reasons. I find it wise to check!