Reclaiming BDD

<rant>

For the love of all things, let’s set something straight. Scaled Agile Framework doesn’t own the term BDD. Nor does Geeks for Geeks.

Nor do I.

So no matter what your favorite ill-trained AI sidekick might tell you, BDD isn’t Agile, and no number of claims otherwise can alter this.

Wait — isn’t Agile? Does that mean it’s not part of Agile? It’s Anti-Agile? They’re mutually exclusive? WTF are you saying here, Steve?!!

Bear with me…

Look at the manifesto. Is there anything in there about Expected Behaviors? Code paths? Collecting observed behaviors to verify alignment? Unless there’s some single-source-of-truth, living-document version of the manifesto that recently got retrospected and someone just committed a GitHub change to and I didn’t get the notification, then no.

Behavioral Driven Development is about stating expectations of what the friggin thing you’re building is supposed to do. And often it speaks to what it’s not supposed to do — when and under what conditions it’s perfectly reasonable to reject input and throw an error.

Why is this important? Because the definition of a bug is when observed behavior doesn’t align with expected behavior. It’s that simple. Thus, if you don’t have a statement of expectation along a given code path, the sky’s the limit on what the system’s allowed to do, but you can’t claim to have a bug on that path!

Here’s a joke to illustrate this point. Maybe you’ve heard this one.

A test engineer: Walks into a bar, runs into a bar, hops into a bar, skips jumps….all good
The test engineer then orders: a beer, a BEER, a beet, a bear, a bee, 2 beers, NaN beers, -1 beer, 4;drop table beer;beers, NULL beers
The test engineer pushes the bartender, ignored the bartender, punches the bartender
The bartender fulfills the orders that he can fulfill and refuses the others. The tester writes up his results and signs off on the release
A live user walks into the bar and asks where the toilet is. The bar explodes and everyone dies.

FEATURE

Rene Descartes weighs in…

Let’s remember what Agile is and is not. A good place to start are the values and principles, some of which are great and others of which are showing their age (or lack of vision). Don’t get me wrong, this is a wonderful document and these folks were and are amazing for having the foresight they did. But the manifesto itself should be retrospected a bit imho. But I digress.

Agile Values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile Principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Businesspeople and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity — the art of maximizing the amount of work not done — is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I don’t see the term Behavior in there anywhere. Nor do I see Driven or Development. In fact, I’ve been told to my face that mandating a statement of expected behavior is violently anti-Agile — that teams should “figure it out for themselves” if they need that or not.

Unbelievable.

Consider this graphic. Classic Cartesian coordinates! See? Rene’s in the mix here!

I see Agile (and Scrum and most of what folks talk about in terms of what does or does not get bug-free code out the door) talking only about that X-Axis. The Manifesto was a huge step forward here. It proposed, if you read between the lines, that this tube isn’t unidirectional — that there are eddys and backflows in it where people can have face to face conversations and pivot without having to get completely to the end of that pipeline.

MASSIVE step forward. Wow, we can change what we’re building before we even ship it! And what’s more, we OUGHT to be doing this regularly. No more Edsels! Huzzah!

Great progress — on the X axis. Nothing in there about Y and Z.

If I were king of the world, I’d define BDD thus:

Along all code paths through a solution, requirements for that code path must include a statement of expected behavior AND must define the payload and underlying system data states necessary to force that code path. Wait, too wordy. Let me restate it with enhanced grammar:

FOREACH code path, WHEN client provides (trigger event, possibly with data), WITH system in (data state), THEN system responds with (behavior).

BDD *requires* identifying code paths. It *requires* verifying statements of expectation on those code paths. And, once the system is built and in its ultimate environment, it *requires* collecting observations on each of those code paths to verify alignment with expectation.

This is Y axis stuff. It’s about the quality of what’s moving through that pipeline — which is sooooo crucial to getting good stuff out the door. If your features and stories are crap, ladies and gents, we’re building a sewer pipe. And among the minimum quality bar elements for those artifacts is a clear, unambiguous and ideally non-prose statement of how the end solution is supposed to behave.

while (1) printf(“Must have statement of expected behavior on all code paths.”);

Y’all are gonna get sick of me saying that if you already aren’t.

What about Z?

I’ve already harped a lot on the deficiencies of prose — using big blocks of human language to convey ideas. And I’ve written articles already on how to overcome this through diagrams and other structured artifacts. Requiring those as part of the Y-axis quality bar is a good practice, to my thinking. But defining really good practices here — all Z axis stuff.

This is another gap area in the manifesto, to my thinking.

“…the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”.

What about other teams? Why so isolated?

I’m sorry — if I had a hypothetical team, A, which was sustainably delivering bug-free code at 3x the velocity of their peers, as a manager, I’d damned well mandate that the other teams learn what Team A’s doing and emulate it. Maybe move a couple devs or POs from A to cross train the others, or maybe have the less efficient teams take internship turns sitting in on A’s day-to-day functioning.

I’d also task Team A to figure out why and how they’re doing what they’re doing. Especially if their turnover is substantially lower than the less efficient teams.

None of this is spoke to by the manifesto. It’s part of that Z axis — cross-pollenating ideas, work-patterns and best practices so that each team isn’t in a silo figuring things out for themselves.

All very critical parts of getting bug-free code out the door at maximum sustained velocity.

Is BDD Agile? That’s like asking “Is an energy drink Catholic?” It’s a nonsense question. Apples and llamas.

BDD is a Y-axis notion about quality of artifacts and what to do with them. It’s equally applicable to any type of pipeline, even waterfall. I’ve personally been involved (even led, back in the day) two very large projects during my career using waterfall which delivered perfect functionality the first time through — because we had clear expectations of behavior.

Apples.

Agile’s an X-axis notion and yes, it’s nearly always better than waterfall.

Llamas.

Nobody owns BDD and I’m not (yet) king of the world.

Now let’s all get down off our soapboxes and go ship good code, shall we?

</rant>

PS: Regarding whether Agile projects do or don’t fail more often than others, consider this: Those failures probably didn’t pay attention to the Y or Z axis.