At #CukeUp today, there’s going to be a panel on defining BDD, again.
BDD is hard to define, for good reason.
First, because to do so would be to say “This is BDD” and “This is not BDD”. When you’ve got a mini-methodology that’s derived from a dozen other methods and philosophies, how do you draw the boundary? When you’re looking at which practices work well with BDD (Three Amigos, Continuous Integration and Deployment, Self-Organising Teams, for instance), how do you stop the practices which fit most contexts from being adopted as part of the whole?
I’m doing BDD with teams which aren’t software, by talking through examples of how their work might affect the world. Does that mean it’s not really BDD any more, because it can’t be automated? I’m talking to people over chat windows and sending them scenarios so they can be checked, because we’re never in the same room. Is that BDD? I’m writing scenarios for my own code, on my own, talking to a rubber duck. Is that it? I’m still using scenarios in conversation to explore and define requirements, with all the patterns that I’ve learnt from the BDD world. I’m still trying to write software that matters. It still feels like BDD to me. I can’t even say that BDD’s about “writing software that matters” any more, because I’ve been using scenarios to explore life for a while now.
I expect in a few years the body of knowledge we call “BDD” will also include adoption patterns, non-software contexts, and a whole bunch of other things that we’re looking at but which haven’t really been explored in depth. BDD is also the community; it’s the people who are learning about this and reporting their learning and asking questions, and the common questions and puzzles are also part of BDD, and they keep changing as our understanding grows and the knowledge becomes easier to access and other methods like Scrum and Kanban are adopted and enable BDD to thrive in different places.
Rather than thinking of BDD as some set of well-defined practices, I think of it as an anchor term. If you look up anything around BDD, you’re likely to find conversation, collaboration, scenarios and examples at its core, together with suggestions for how to automate them. If you look further, you’ll find Three Amigos and Outside-In and the Given / When / Then syntax and Cucumber and Selenium and JBehave and Capybara and SpecFlow and a host of other tools. Further still we have Cynefin and Domain Driven Design and NLP, which come with their own bodies of knowledge and are anchor terms for those, and part of their teaching overlaps part of what I teach, as part of BDD, and that’s OK.
That’s why, when I’m asked to define BDD, I say something like, “Using examples in conversation to illustrate behaviour.” It’s where all this started, for me. That’s the anchor. It’s where everything else comes from, but it doesn’t define the boundaries. There are no boundaries. The knowledge, and the understanding, and especially the community that we call “BDD” will keep on growing.
One day it will be big enough that there will be new names for bits of it, and maybe those new names will be considered part of BDD, and maybe they won’t. And when that happens, that should be OK, too.
NB: I reckon the only reason that other methods are defined more precisely is so they could be taught consistently at scale, especially where certification is involved. Give me excellence, diversity and evolution over consistency any day. I’m pretty sure I can sell them more easily… and so can everyone else.
I like your anchor – “Using examples in conversation to illustrate behaviour.”
I’m working with a group of students who have very limited experience writing code, and they want to make an app. We started talking about examples (rather than frameworks or tools), and I was so amazed how much we learned with just a few conversations about the desired behavior. I think that’s BDD 🙂
Reblogged this on Nikola Zdunić and commented:
I quote liked this blog from Liz Keogh. Agile culture, more generally, is and will continue to creep into all things humans do. We mustn’t forget the Lean folks, they really laid the path over several decades. They are like martyrs for a better world order. We still have some way to go and adjusting mindsets takes some time.
Pingback: Five Blogs – 1 April 2015 | 5blogs
Perhaps we can define BDD in ‘modular practices’ and we either practice one, few or all of them. One modular practice could be around having conversations, another about illustrating behaviour using examples’, another about gluing scenarios to an application under construction? If I’m in a software project I could be applying all the modular practices. If I’m in a non-software project I could be practicing the first two.
I think we can define BDD but people are afraid to do it and want it to be left mystic??? 😉
Paul Rayner’s article on the same topic talks about centred versus bounded communities. I agree with him completely. It’s not about leaving things “mystic”; it’s about being inclusive of people who want to improve, no matter what they’re starting with. Most of the core BDDers I know (myself, Dan North, Chris Matts, Matt Wynne, Aslak Hellesøy and others) spend a lot of time sharing our knowledge and ideas freely. Exclusivity and “mysticism” is not in our agendas.
Having said that, heaven help you if you’re trying to do BDD without conversation or without examples. I consider both of those to be core practices, even if the only conversation is with a pixie or a rubber duck.
Pingback: BDD工具Cucumber并不是一种测试工具 - 合智社区
Liz – do you still do workshops for teams wanting to adopt BDD?
Absolutely; emailing you to find out more.
Pingback: Le Manifeste du BDD – Excellence Agile
Pingback: Development processes (Toolbox #6) - The Geeky Gecko