BDD by example
tl;dr: Send us your examples of real world BDD. Read on to find out why.
The panel ¶
“What is BDD?”
“How can I tell if I’m ‘doing BDD right’? Or wrong? Is there even such a thing?”
“Where should I start?”
“Is this or that practise considered part of BDD?”
“What are the mandatory ”core“ practises of BDD?”
These and similar questions were the topic of the closing panel at the recent CukeUp conference in London.
I’ll be honest, I was expecting to be the curmudgeon saying things like “How hard can this be?” and “Aren’t we just pandering to people who want the illusion of certainty, and shouldn’t they know better?” Instead I found myself in the middle of a stimulating and nuanced discussion, during which I had a couple of aha moments which led me to write this post.
During the discussion I introduced the idea of boundary markers, which are ways some religious groups mark themselves out as special or exclusive. Eating or not eating certain kinds of foods, wearing specific clothing, carrying out particular rituals, possessing arcane knowledge, are all ways to distinguish those inside the camp from those outside.
The lovely Paul Rayner, whom I discovered is a preacher as well as a BDD practitioner, joined the panel—which operated more as a fishbowl—and explained that the term came from an anthropologist who studies missionaries, and who documented two contrasting ways missionaries attempt to establish faith communities.
Briefly, a community defines itself by either its centre or its boundary. A Centred Community is based on core principles or values. You can identify with the community by how closely your behaviour reflects its values, so it necessarily has fuzzy edges. A Bounded Community uses those boundary markers I mentioned earlier to identify inclusion, so membership is binary. You are either doing all the things or you aren’t. Paul has written a really nice article about bounded and centred communities and I recommend you read that if you want the full story.
On boundaries and centres ¶
In my experience boundaries seem to correlate with commercial or political interests, where centres seem to correlate with an affinity for the community’s values.
As an example, Kent Beck originally described XP as “helping business people and technical people communicate with one another”, and sometimes as “making software development safe for programmers”. I remember the zealotry that emerged shortly after he published XP Explained. If you weren’t following the Twelve Practises (later Thirteen Practises) then you weren’t doing “Pure” XP, whatever that means.
Yet XP is an explicitly value-based method. At its core are the principles of Simplicity, Communication, Feedback, Courage and Respect. All the practises Kent describes in XP Explained are just the supporting information, sharing what he and Ward Cunningham and the rest of the team did at Chrysler. However it’s easier to make money from consulting or training if you have explicit practises to sell, so it suited the commercial interests to bring those to the forefront.
Scrum has it even worse. Certification is the epitome of boundary marking, and selling certification is a great way to gain both money and status. The official line is that Scrum is based on principles from Lean Operations, in particular the principle of inspect-and-adapt. In reality all the Scrum I see is prescriptive, inflexible, practise-based, in fact more like inspect-and-criticise, all of which suggests a boundary. Are you doing Stand-ups? Are you following the Stand-up Formula? What about Sprint Planning with an omniscient Product Owner, Backlog Grooming, Sprint Commitments/Forecasts? Story Point Estimation? Then I’m sorry, but you aren’t doing Scrum. Then the fault line splits and you get the Scrum Alliance and the Scrum Empire, or whatever it’s called, where one has Certified Scrum Masters and the other has Professional Scrum Masters. What’s a CIO to do?
On principles and practises ¶
The absence of a clear boundary is a double-edged sword. Whilst it can make people nervous, it can also be a rich source of new techniques. The absence of a boundary around BDD has meant certain practises have emerged and become commonplace over the years. I came across the Three Amigos method of exploring features by way of agile testing gurus Janet Gregory and Lisa Crispin, although it originated with George Dinwiddie. Three Amigos was never part of my original description of BDD, but in the right circumstances it looks like a great way to collaborate.
Occasionally I facilitate Discovery Workshops where I bring together people from different backgrounds and use creative exercises like persona modelling, communication maps, storyboards, or building a product-in-a-box. Sometimes we weave in aspects of Jeff Patten’s Story Mapping or Gojko Adzic’s Impact Mapping. The Three Amigos session seems like a more opinionated version of that: let’s put just a developer, analyst and tester together and see what happens as they look at the problem from each other’s perspective.
Three Amigos isn’t a mandatory part of BDD, but it does feel “close” to the core of what I intended. Chris Matts recently wrote an article about the principle of Inclusion as a generalised case of the practise. I would go further and say that Inclusion in this sense is just another example of Deliberate Discovery, so it’s principles all the way down, probably until you get to “Collaborate to create business impact” or something equally nebulous.
Agile by example ¶
So my first aha moment was realising the BDD community was value-based and centred rather than practise-based and bounded. Then Gáspár Nagy joined the panel and made a startling—to me, at least—observation.
No-one ever defined “agile”!
The agile manifesto doesn’t contain a definition of “agile”. Instead it provides a number of examples: People and interactions are more important than processes and tools, working software trumps comprehensive documentation, etc. No-one explains why, it’s all supposed to be kind of obvious. Better ways and all that.
Now I’ve been citing those value statements since they were first published, and it never occurred to me until that moment that they are just examples of some deeper, undisclosed values. Pretty ironic for the someone who talks about building software by using examples.
BDD by example ¶
I watched what happened to the Scrum and XP communities and their respective practitioners. Kent Beck wrote several books about XP, yet he deliberately chose not to monetise it via certification or subscriptions. I admire that so I deliberately chose not to try to monetise BDD by creating an institute or selling certification. Unfortunately this means people who hear about BDD and want to investigate it don’t know where to start; people who want to offer training don’t know what to include. There are some great books out there but they can’t be all things for all audiences.
So what are the values that underpin BDD? I am convinced that the right way to define BDD is in terms of a centred rather than bounded community, and since I am someone who thinks in examples I made a suggestion to the folks at CukeUp that I would like to extend to you.
I want to build a community-curated resource for everyone interested in BDD.
It should be example-based, with various “trails” for different personas: Claire the Curious Tourist, Tony the Toe-dipper, Sunil the Scaler-upper, Ceri the Coach, Nigel the Nervous Adopter, Sally the Skeptical Sponsor, and no doubt many others. It will contain experience reports, recipes for the most common practises, suggestions for advanced or experimental techniques along with appropriate caveats, links to articles, books, training, consulting, probably initially vetted by me but over time peer-approved by the community. More than that I don’t know yet. I want the personas and examples to shape the solution, otherwise it wouldn’t be BDD, would it?
I’ve registered the domain bddbyexample.org, which is currently pointing to this blog post, but which will eventually host this choose-your-own-adventure into the world of BDD. Oh, and it will have killer search. Finding things is important.
We want you to send us your examples of BDD in practise, BDD in the wild, examples of examples and examples of scenarios, BDD mutations, adaptations, exaptations.
Here are some sample questions to whet your appetite. If any of them resonate with you, please send us an example, a story, a link or anything else you think we will find useful.
- What kinds of problem are you solving or product are you building?
- How are you engaging with your stakeholders?
- How are you identifying those stakeholders in the first place?
- Are you in a context where you don’t have access to key information? What are you doing to compensate?
- What techniques do you use for discovery?
- How do you explore your blind spots? What do you do to surface second-order ignorance, where you don’t know what you don’t know?
- How do you surface examples? Who is involved?
- How do you document examples? Do you use Given/When/Then “Gherkin” syntax? Tables? Free prose? Drawings? Something else?
- How much do you automate? What do you do about the other stuff?
- Can you tell us a story about how BDD has helped you?
- Or where it failed and why you think that was?
- What other methods and techniques are you using with BDD? Are you using Cynefin, any of Impact, Story, Delivery or Skills Mapping?
- How about Systems Thinking, Theory of Constraints or the various limited WiP methods like Kanban?
Please email us at firstname.lastname@example.org with your examples of any of the above, your ideas for other personas for the website, or anything else you think might be relevant. Let us know if you want the example to remain anonymous, or if not how we should refer to you and/or your organisation on the site. Tom Stuart has volunteered to be our interim Responsible Adult, collecting all the submissions and reporting on progress.
Also please get in touch if you are interested in helping with curating, building or otherwise being involved in this project. I’ll be taking the role of executive producer, encouraging and shaping from the sides but trying not to be the delivery bottleneck for anything.
We will report progress and conduct open discussions on the BDD Google Group.
Thanks to Chris Matts, Rachel Davies, Nat Pryce, Gáspár Nagy, Paul Rayner, Konstantin Kudryashov and the other participants for taking part in the CukeUp Panel, Tom Stuart for coming up with the idea and herding the cats, and SkillsMatter and the CukeUp conference for hosting us.