Can BDD and Lean methodologies be used together?

Question

I was chatting with my product manager last week and he was bemoaning the lack of progress on our product. It's a fair criticism, too. So we got to talking about to describe the writing of requirements. I'm a big fan of BDD and using something like the Gherkin syntax to describe how the system should behave in terms of a user or actor.

He was pretty dismissive of BDD and said we should be using Lean methodologies like SBCE (set based concurrent engineering) and other stuff which I don't know a massive amount about given I've not read much on Lean practices so far.

Are these two methodologies mutually exclusive? If not BDD then there would need to be some other way of describing what the system should do. Does Lean have its own language for requirements?

Answer 1

To my understanding, Lean development intends to optimize the development process of your team, with the focus on balancing between quality, costs and time. It is an organizational method, which does not embrace a specific syntax, language or notation. BDD, however, has its focus on "building the right software", and getting the requirements right, by using a specific modeling and a specific form of testing - so BDD is a less an organizational, but more a technical approach. So if you want to take some notations, terms or testing methodology from BDD, this will not contradict Lean - BDD and Lean are somewhat orthogonal.

However, if you try introducing BDD and it turns out it will slow down your processes even more, don't be surprised when your manager in favor of a Lean development process might identify BDD as "waste" (in the Lean sense), and throws the BDD stuff out. So when you suggest BDD, be sure it aims at problems you really have in your team, and it is not just because you "are a big fan of BDD" - fanboyism is a big warning sign for most experienced managers. Since you did not tell us so far the reasons why the speed of progress does not meet your expectations, I cannot tell you if BDD is the right or wrong tool for your problem. But be careful not to attempt to use a technical solution for an organizational problem, that will most probably fail.

Answer 2

Most of our Lean knowledge comes from the work that Deming did at Toyota. There are two main ways in which I look at Lean:

• Lean Product Development
• Lean Production.

Lean Product Development is the equivalent to designing new cars, and is more like software development than production is. We're busy creating new things, not producing the same old thing again and again predictably. It's about minimizing work in progress, getting fast feedback and using those metrics to work out what to build.

Lean Production is more like a factory. The idea is to minimize variability to ensure high-quality. The only bit of software that's even vaguely like this is the build system, but even that's more like designing the factory along with the car. Particularly, Lean Six Sigma is about reducing the variability enormously, and is completely, totally inappropriate for SW dev.

The one thing they do both have in common is that minimization of work in progress. (It's a bit more complicated than this, but this is a light overview for you.)

I would be very careful, when looking at "Lean", regarding which of the techniques you apply. Fortunately SBCE is from the first, not the second, so your boss is mostly on the right page. Lean Start-Up approaches (which is where I'm guessing he read about SBCE) are also part of that group.

Lean and BDD are completely compatible; in fact, I recommend a Kanban System approach with BDD anyway. In shorthand, this translates to reducing the gap between the conversations around scenarios happening, and the actual work on those scenarios being done, while minimising the number of conversations which aren't being progressed to software (because you'll forget what you talked about over time).

SBCE is a method for running multiple concurrent experiments, which is useful when there's uncertainty around the work that needs to be done. BDD is really great at helping to work out which bits of work are uncertain, and which are well-understood or require expertise. The Specification-By-Example bit of BDD is only one part of BDD, though it's the part most people are familiar with, and that's probably why your boss is dismissing it (unnecessarily).

For more info, try this blog I wrote on using BDD as a sensemaking technique (finding those borders I just talked about), this one on estimating complexity, or watch any of my talks on BDD and Cynefin. Your boss may find the first blog I've linked reassuring as well.