In 2001, a group of software consultants got together for a weekend in Snowbird. Each had developed their own software development methodology in response to the challenges that their clients were experiencing with traditional waterfall approaches. They were looking for common themes, so they could present a unified story to the market. The result was the Agile Manifesto.
Since then, agile methodologies have been widely adopted throughout the software development world with Scrum being the major player. Scrum describes several ceremonies — backlog refinement, planning, standup, review — that have become almost universal. Their goal is to improve communication, predictability, and quality. However, many organizations adopt Scrum but fail to realize the promised benefits.
Part of the problem is that the goals are not precise enough. Teams don’t just need communication; they need meaningful collaboration. Organizations may want predictability, but in a world of rapidly changing priorities, the focus needs to be on frequent feedback based on small increments. Even with world-class collaboration and frequent feedback, we will only achieve our quality goals if all members of the delivery team adopt appropriate technical discipline. Scrum is notable for its silence on all things technical.
What is BDD?
Behavior Driven Development (BDD) was first described by Dan North in 2006. It follows directly from the Agile Manifesto’s advice to value “individuals and interactions over processes and tools.” BDD is best thought of as a collection of tried and tested techniques that facilitate interactions between team members. BDD is not a rigid process — and it’s certainly not a tool!
BDD can best be thought of as comprising three practices – Discovery, Formulation, and Automation. Each practice is applied iteratively to each user story, once the story has been prioritized for delivery. The Discovery practice results in shared understanding; Formulation results in business-readable specification; and Automation results in living documentation.
Shared understanding
Communication is hard. Even if the product owner has a very clear understanding of the required behavior of the software, it can be difficult to transmit this to the delivery team using only user stories. Even if that were possible, there are often technical trade-offs that would change the product owner’s decisions, so one-directional communication is usually insufficient.
The reality is that many organizations begin development before a shared understanding of the desired behavior has been reached, which inevitably leads to “accidental discovery” of the requirements as development proceeds. This, in turn, gives rise to rework, increased costs, and reduced satisfaction.
BDD insists on deliberate discovery before development begins. Deliberate discovery is a collaborative activity founded on the insight that “learning is the constraint.” Representatives from product, development, and test work together to challenge their understanding of the requirements — quite literally testing them. The best technique that we have discovered to facilitate this activity is called Example Mapping.
As well as generating a shared understanding, Example Mapping has several beneficial side effects:
- Poorly understood requirements are spotted early
- Complex requirements can be identified, split, and delivered in smaller increments
- Concrete examples generated can be used later as test cases
Business-readable specification
The shared understanding that results from deliberate discovery is fragile. All stakeholders will not have been involved. Requirements change. Team members come and go. To lock in the value, we need to capture that understanding in a format that is accessible to all stakeholders.
We formulate the concrete examples generated during deliberate discovery into a specification. We use business-readable terminology so that the specification makes sense to all stakeholders. This is important work, uncovering terms that mean different things to different people. There are several beneficial outcomes:
- a “ubiquitous language,” rooted in the business domain that eliminates ambiguity
- a single, shared source of truth that doesn’t have to go through error-prone translations as it gets passed from discipline to discipline
- a massive reduction in defects and the rework that would otherwise follow
- a specification that is valuable for the whole lifetime of the product
Living documentation
If there’s one thing that’s worse than not having any documentation, it’s having unreliable documentation. Many tools exist to allow teams to automate their business-readable specification. The specification automatically tests the software, alerting the team if the specification does not accurately reflect the behavior of the software. This may indicate that there is a defect in the software, or that the specification is now out of date. Either way, it signals the team that there is some inconsistency that needs to be fixed.
A specification automated in this way is called living documentation. It constantly reports on its correctness, and if the team pays attention to the report, it can be relied upon to accurately describe the behavior of the software.
Living documentation can also be thought of as a suite of automated tests. This should never be the primary reason for following a BDD approach and always needs to be supplemented by other testing activities. However, the automated testing provided by living documentation is a valuable and attractive secondary outcome.
Saving your agile without changing your process
Agile adoption is all too often focused on processes, ignoring the obvious fact that success is founded on teams of people collaborating to deliver software that meets their customers’ needs. BDD, as described in this article, is a series of practices that fit well into iterative, agile development approaches.
You gain value from BDD by practicing Discovery on its own. Additional value is released if you then practice Formulation. Automating your business-readable specification generates even more value. If, however, you choose to ignore Discovery and Formulation, you will probably find yourself the sad owner of slow, brittle, incomprehensible test scripts which cost far more than any value they deliver.
By focusing on the collaborative nature of software development, BDD helps achieve the goals that are often missed by organizations adopting agile approaches — effective collaboration and small increments. And the best news is that your team can start today without major changes to your existing development process. 
