Given – When – Then ….. Seems deceptively simple. BDD was undoubtedly one of the most difficult approaches we had difficulty implementing. For me it was key – it wasn’t about the syntax, BDD is about:
- Getting different disciplines talking and communicating using a common accessible language. Pushing out the enemy – ambiguous statements and subjective interpretation. Building the right thing, preventing wasted effort on development and testing of the wrong thing.
- Building quality and testing into the incoming stream of project requirements
- Embedding rigour and testing into the most important part of the process – Incoming Requirements
Note: If you have part of your team writing BDD, you are not BDD. There is a difference between syntax and being ‘BDD’. BDD Syntax will only give a few of the potential benefits.
Point 2 is key. Quality built in. All too often, the product is developed and then handed over to another role who then had to ‘figure out how to test’. Embedding BDD into the start of the lifecycle enables testing from the onset. Automated testing becomes a lot easier to achieve with this.
So why was this so hard ….? Getting universal buy in, BDD can not be done in isolation. That meant having PO’s, Developers and Testers engaged and their competing requirements synchronised. As this was ‘something new’ this took months.
We had taken our project from Stage 1 Scrum (reactive) to Stage 4 (proactive). This was the last big ticket identified for improvement. Being at a fairly mature Scrum level had also counterintuitively created a number of problems:
- The teams had delivered against the roadmap and had hit every delivery date, there was no longer any external pressure or focus to improve delivery capability
- The bottlenecks had been moved to outside the immediate team. Stories could no longer be created ‘fast enough, or to a quality that was good enough to accept’. Stories had become the blocker.
The team had to some extent become a victim it’s own success. They were no longer a bottleneck. Other external factors had become impediments.
BDD is also what I would term an non-obvious improvement. There isn’t an immediate and obvious benefit. It’s so obvious, it’s not obvious – until its taken away. This is compounded when you have a process in place that is delivering to a good enough standard.
Habits, Ways of Working and Practices
This also really brought home to me ‘habits’. People build habits, everything you do becomes a habit if it involves repetition. Breaking an individual habit is hard. Breaking a teams habit is harder. Particularly when it involved more than one discipline. Moving teams to better practices involved much more time and effort than it would have done if started from scratch.
So to summarise why BDD was hard, it was because:
- You have to bring a team onboard, not indivuduals
- Its about the approach, not the syntax
- Breaking habits and current ways of working is tough