When to embrace Behaviour Driven Development?
Behaviour Driven Development (BDD) is a collaborative and disciplined technique to help us build the right product. In the last decade BDD has had her own bit of glory and criticism. Many teams in the recent past have reaped benefits from this technical practice, while some teams complain that are yet to find any value. This talk focuses on answering two questions; Why BDD might not always be the right choice? What are the ideal conditions when teams should adopt it?
Preface about the talk
Behaviour driven development has been a buzz word in the recent years and many teams are adopting it. The core of BDD is the collaboration angle that enables teams to build the right product. As a side effect BDD gives you a very essential output, which is an automated acceptance test suite. BDD team members work together in identifying different scenarios elaborated in the form of examples. High performing teams ensure through working agreements to only pull those features in which scenarios are well defined. These scenarios define the acceptance criteria of the feature. The scenario identification process involves full team participation and in these meeting its essential that the three amigos i.e. the entire development team, QA engineers and product owner should participate. Along with the three amigos any other members who can constructively contribute in scenario identification are also welcomed.
During these interactions technology facing members get a better understanding of business and vice-versa. It has also been observed that identifying and discussing scenarios helps the team in analysing and studying the feature in much detail. Many teams benefit from this practice as it helps them shape their product , saying so few teams are yet to find value in investing time and effort towards these meetings and ceremonies . One should keep in mind that for BDD to be effective we require full team participation.
In this talk I am making an assumption that these teams who are not finding much value in adopting BDD, were practicing it in fullest of its spirits and not just documenting scenarios for creating an automated test suite. This talk doesn’t discuss on how to effectively practice BDD, as it’s out of scope. This talk will throw some light on why BDD might not always be the best fit for all type of product development.
Outline/structure of the Session
- Introduction - 5 min
- Problem space and solution space -5 min
- The Gap -5 min
- Complexity -5 min
- When to use Behaviour Driven Development -10 min
- How to measure complexity -5 min
- Conclusion 3 min
- QA -5 min
- Participants will be able to judge when to adopt Behavior driven development and when not to .
- The participants will get introduced to the BDD adoption matrix which will aid in decision making
- They will also understand, Why BDD might not always be the right choice preferred / practice in software development.
Developer , tester , Product owner ,Scrum Master ,Leadership