Recently I have delivered BDD training at a company using the Spotify model. Although I don’t have too much first-hand experience with it, I was made think about how BDD would fit into the Spotify squad metaphor.

Every metaphor is wrong in some way, but for me a good metaphor is helpful to make better decisions in some situations. Is the squad a good metaphor? I am not a military-person, so the term definitely sounds weird to me, but if I think about a squad like a team cooperating for a single goal, then it might work. The members of the squad are responsible for each other, they don’t leave anyone behind. They have different skills, but everyone has a basic understanding of everything (T-shape), so they can help out each other if necessary. They keep training themselves but they also get training as a part of their job. These things sound good and I think they would be useful for a software team as well (maybe any team even).

But how does BDD would fit into the squad metaphor?

Probably the easiest is to imagine BDD discovery in a squad. In BDD discovery, the details of a user story that the team is going to implement are discussed with the involvement of the business representatives (like the Product Owner). This can be done for example using Example Mapping or with any other structured conversation. In this discussion the PO explains the goal and also those criteria that have to be satisfied in order to declare the story as done (acceptance criteria, rules). These rules are discussed and modified, if necessary, by the team. The goal is that the team understands these rules as much as possible, because clarifying questions during the implementation might cause delay or can even risk the acceptance of the story. We discuss these details by collecting illustrative examples. These are concrete, imagined usages of the application that show how it is supposed to behave once it will be implemented. As these examples are concrete, it is easier to imagine the situation they describe for anyone. Also by looking at these concrete examples, it is easier to find special cases that require further clarification. The examples are collected by the team together, so in the end they will represent our common understanding of the problem.

The squads complete missions. Every mission requires a detailed preparation. The preparation starts earlier, by defining the goals and analyzing the possible benefits and risks, but the squad encounters them on the briefing. The briefing is led by a lead/superior, who explains the goals, the expected outcomes and the risks. The squad members can ask and can also make suggestions, and they make a plan. With the briefing they have two primary objectives. 1) Everyone in the team has to understand the plan, because it can happen that people need to help out or replace each other during the mission. 2) They also want to try to be prepared for as many unexpected circumstances as possible. They achieve these objectives by trying to model and simulate the mission. They discuss through how the mission will be performed with very concrete details, illustrated on a map or even with live simulation. They also discuss alternative cases as well, which can be used in case something does not happen in a way how they have assumed. These simulations are done by the entire team, and everyone knows what the other members supposed to do, so that they can replace each other if necessary.

I think the similarities between BDD discovery and a squad briefing are clear. Both try to achieve a shared understanding and to discover as many unknown details as possible. In both cases concrete examples are used to help the members better imagine the situation.

And what would be the BDD scenarios in a squad mission? This is a harder question. Maybe they are portable cameras or alarm systems that the squad members deploy at areas they have cleared out, that can protect them against bad surprises. But maybe this is the point where the analogy starts to break…