Elevator Pitch
BDD was introduced as a great development in delivery. Using it we would have closer team collaboration and the right requirements turned into delivered components. What could go wrong? Plenty! From team dogma to bad practices, BDD is more abused than used for delivery. How can we fix this?
Description
Intro
Poor old BDD, it had so much riding on it and so many promised made on it’s behalf. It was presented as the great hope of a delivery system. Using it we were supposed to get closer team collaboration, the right requirements turned into the right user stories turned into the right acceptance criteria turned into the right features turned into the right scenarios turned into delivered components and passing steps. Put like this - what could go wrong?
As it turns out…
There are lots that can go wrong. If your methods of collecting your user requirements are not complete enough, if you do not have the right people engaged from your team, if you do not have the collaborative culture needed to work in this way (for starters) you are on a hiding to nothing trying to work in BDD especially in complex, enterprise or high transactional environments.
The right team engagement
Let’s start with the 3 amigos as an example.
“The 3 amigos” (said a scrum master of projects past) “If we have the 3 amigos working together, we have the heart of BDD assembled” (2016). Grand, hearts are good. The only thing is that a heart needs blood to pump around, a chest to house it and a body to transport it about. Examined in this context, the mantra of “all we need are the 3 amigos for BDD”, is problematic. It does not tell the full story of what is needed for BDD to work.
Angie Jones has previously written about doing BDD as a solo activity because of a lack of willing or knowledgeable collaborators. I have seen testers and developers attempt to do the same for the very same reasons. On simple systems, there is no harm in doing this as the core functions of the system can be easily understood by everyone.
Unfortunately, on more complex systems with more functions and integrations than a single person could reasonably master in order to work in this way, it is too much to take on as one person.
If you believe the 3 amigos are all that is needed for BDD or you have abandoned the collaboration element of BDD for complex systems, then all you are doing is Badly Done Delivery. Yet, if team members cannot get buy-in to work in this way from those who are supposed to support their team, what options are they left with?
Some light that is NOT the train at the end of the tunnel
Let me help you NOT do that by taking you through what can go wrong with BDD, how to fix it in time or how to make the decision to walk away rather than trying to refactor the wheel into a triangle.
This is my simple BDD success formula:
BDD = communication and collaboration of: {planning and timing} + {users, delivery team} + {feature file(s), tool(s), scenarios, steps/code}
(As an aside - BDD != {the 3 amigos}, != {a tool}, !={feature files})
I have over a decade of experience of seeing teams try to introduce BDD. I was part of the drive to introduce it as a way of working into 4 companies. As a result, I have a lot of success and failure factors to talk about. Taking my simple BDD success formula (above) - I will go through each component mentioned in detail to show you what they look like when they are all working in harmony with each other to the point where I will get a simple coded BDD scenario passing a ‘check’ to show the journey from feature to test.
Some takeaways from this talk
How to start BDD as a joined up journey where everyone expected to deliver knows how to play their part.
How to assemble your amigos in a self-organising team.
What the proper user engagement for BDD looks like.
How you will know if you are producing the right artefacts.
How you will know if you are using the right tools.
How to have a whole team understanding of why you are working in this way.
How to continually refine this method of delivery.
How to fix it if something goes wrong.
Notes
Besides a screen and a microphone, I have no tech needs to deliver this talk above and beyond those of most speakers.
I am Irish, educated in Cork, living in London. For conferances outside of London, I will require that travel and accomodation are covered. As part of my travel, I will look up and offer to talk at local free events if the timelines work out.
I have over a decade of experience of seeing teams try to introduce BDD. I was part of the drive to introduce it as a way of working into 4 companies. As a result, I have a lot of success and failure factors to talk about. Taking my simple BDD success formula (above) - I will go through each component mentioned in detail to show you what they look like when they are all working in harmony with each other to the point where I will get a simple coded BDD scenario passing a ‘check’ to show the journey from feature to test.