When to embrace Behaviour Driven Development?

Abstract

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;  What are the ideal conditions when teams should adopt it? How to adopt it the right way ?

In this talk we come up with a BDD adoption matrix to help us answer the above questions. We also assert that for successful product development it is crucial to bridge the gap between the problem space and solution space, each of which has its own set of complexities. We conclude that Behavior Driven Development can be one of the effective techniques to bridge this gap especially if the problem space is complex. In case the problem space is simple it might be an over kill and teams might not find real value practicing BDD. We also observe that teams whose problem space is simple can continue to document scenarios and automate acceptance testing but they need not spend elaborate time and effort towards discussing and debating scenarios.

 

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 discuss on how to effectively adopt it ,the right way based on problem space complexity of the feature .

 
3 favorite thumb_down thumb_up 6 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Introduction - 5 min
  • Problem space and solution space -5 min
  • The Gap -5 min
  • Complexity -5 min
  • A Game  , to simulate different complexity and effects of BDD  : 40 min (this is Optional )
  • When to use Behaviour Driven Development -10 min
  • How to measure complexity -5 min
  • Conclusion 3 min
  • QA -5 min

Learning Outcome

Participants will get to  know  how they can custom fit BDD as a technique to their project context based on their problem space complexity

Target Audience

Developer , tester , Product owner ,Scrum Master ,Leadership

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Rohit Arora
    By Rohit Arora  ~  1 year ago
    reply Reply

    Hi Ranjith,

    The outline of the session that you have mentioned is for around 45 minutes but you have listed your talk as 90 minutes. Am I missing something?

     

    Thanks

    Rohit

    • Ranjith Tharayil
      By Ranjith Tharayil  ~  1 year ago
      reply Reply

      thank you for pointing it out , i have modified the structure .

  • Sergey Shishkin
    By Sergey Shishkin  ~  1 year ago
    reply Reply

    Hi Ranjith,

    Glad to see a proposal about BDD. I understand that "This talk doesn’t discuss on how to effectively practice BDD", which is a shame. I'm afraid participants' takeaways might be that BDD is not something for them (problem domain is not complex enough). I believe however, that in any problem domain there are one or two corners where BDD really shines. Even if just for the sake of improving relationships in the team.

    I encourage you to rewrite the talk in a way that anyone could benefit from it. Focus on its strengths and how to get started effectively.

    • Ranjith Tharayil
      By Ranjith Tharayil  ~  1 year ago
      reply Reply

      Thank you for reviewing my paper .

      This talk is based on a white paper I had written. The white paper is based on a study done on projects who had adopted BDD. Some projects benefited from BDD and some didn’t. When I did deeper analysis.

      • There were two reasons that we found for projects that didn’t benefit from adopting BDD
      1. Few projects were not practicing BDD intis fullest of spirits, they were just doing BDD like doing Agile.
      2. Other projects were practicing it in the fullest of spirits still they failed
        1. My analysis showed that their problem space was too simple
      • For projects that did well when studied I found that there problem space was complex. 

      This doesn’t mean that there is no benefit at all in adopting certain practises of BDD when problem space is simple. In all the below four cases we get the benefit of getting an automated test suite of acceptances test, but that is just the side effect of BDD. Teams whose problem space is simple can continue to document scenarios and automate acceptance testing but they need not spend elaborate time and effort towards discussing and debating scenarios .One thing to be noted is that just documenting few scenarios and automating it as test is not BDD.  If you don’t spend quality time to have the right conversations between the people of either spaces and capture these scenarios as examples BDD is not complete. This means that you need full team participation in these discussions and to make the best of  Return on Investment (ROI) spend on time and effort, it only makes sense if problem space is complex. This is why BDD can be an overkill when the problem space is simple and this is the reason why some teams complain that are yet to find any real value in adopting it.

       Since this paper is based on my study, I will be not be able to change my finding based on your review. I respect your opinion but that doesn’t change my findings and my view.

      • Sergey Shishkin
        By Sergey Shishkin  ~  1 year ago
        reply Reply

        Thanks for your reply. I understand you won't change the paper, but I think you still can improve the message of your talk by making it more constructive rather than categorical. In particular I'm suspicious of a categorical statement that BDD either has to be practices fully or has to be avoided on a project scale. I would rather attend a talk that claims to get me successfully started with BDD rather than discourage me from trying. But this is only my opinion of course.

        • Ranjith Tharayil
          By Ranjith Tharayil  ~  1 year ago
          reply Reply

          Thank you   you for your feedback , I have changed the learning  outcome  to "Participants will get to  know  how they can custom fit BDD as a technique to their projects context based on their problem space complexity"


  • Liked Ranjith Tharayil
    keyboard_arrow_down

    Ranjith Tharayil - Adapting BDD for software maintenance projects using the “dEep” model.

    45 Mins
    Talk
    Intermediate

    Behaviour driven development has been a tried and tested technique to help us build the right product. In the recent years many teams who are in green field development projects are adopting it and finding great success. The core of BDD is the collaboration angle that enables teams to build the right product. BDD team members work together in identifying different scenarios and elaborated them in the form of examples. During these discussions, technology facing members get a better understanding of business and vice-versa. It has also been observed that identifying, discussing and debating scenarios helps the team in analysing and studying the feature in much detail. Many teams benefit from this practice as it aids them shape their product.

    But when it comes to teams whose primary responsibility is to maintain previously built software system, BDD as a technique is something that they really don’t know how to utilize to make the best of it. This is because BDD’s primary focus is on driving the development of new features / stories, in case of enhancement projects this driving the development phase was history. Also we are considering a context in which these projects run-on lots of legacy code. This article discusses on how software maintenance projects can benefit from this second generation agile methodology. As you would all agree we will not able to use BDD as it is directly, we need to customize according to our needs to get the best of it. We discuss one such customisations called the “dEep” model.

    The “dEep” is a model that I have come up with for software maintenance projects teams that I coach to get the best of BDD.

     

    “dEep” model is just a template frame work for adapting BDD for software maintenance projects. It may need customization as per specific project context.

    By studying various Software enhancement projects I have categories the type of work into 4 different types  

    • Defects,  “d”.
    • Complex (problem space) enhancements, “E”.
    • Simple (problem space) enhancements, “e”.
    • Urgent production issues, “p”.

     Hence the word “dEep”

    The team during pre-grooming classifies work items into E, e and d. The classification of enhancements into Complex enhancements “E” and simple enhancements “e” is the trickiest aspect here. It is based on the complexity in problem space and not the size of the enhancements. This means that there could be a work item with was estimated as “XL” (T-shirt sizing )  could be classified as  simple enhancements “e” and another work item estimated as “L” could be  classified  Complex enhancements, “E” . The reason is because here we look into the complexity of problem space and not solution space. For more reading on problem space complexity and effects on it during BDD cycle kindly read my paper - Tharayil, Ranjith (15 February 2016). "When to embrace Behaviour Driven Development (BDD)?". SolutionsIQ.

    Each work items classified as  “d” ,”E” ,” e” ,”p”  follows different treatment wrt to the engineering practices like BDD, TDD, , Test first , Test last ,review etc which is based on context that is defined by the team . An example context is presented in my talk.

  • Liked Vinay Krishna
    keyboard_arrow_down

    Vinay Krishna - Built-in Quality through Vertical Slicing of User Story, BDD scenario writing and Test Pyramid

    Vinay Krishna
    Vinay Krishna
    Agile / DevOps Practitioner
    Self
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Developing product with Built-in quality is always desired outcome. Organizations follow various strategies for the same such as horizontal slicing, acceptance criteria and end-to-end automation testing. In this session I'm going to explain how it can be achieved through:

    Vertical slicing is a technique used to develop software by driving a thin vertical slice (cross-sectional slice through the layers), which is functionally coherent and demonstrable, then progressively widening it with consecutive slices

    BDD stands for Behavior Driven Development and BAs, Dev and testers collaborate and write scenarios to cover expected behavior of application

    Test Pyramid highlights that we should have more low-level tests (such unit tests) than high-level tests (end-to-end tests).

    I have used them effectively while coaching various teams. I'm going to share my experience supporting real time examples through this session.

  • Liked Ranjith Tharayil
    keyboard_arrow_down

    Ranjith Tharayil - Change Vector Tracking in emergent design

    45 Mins
    Talk
    Intermediate

    A reflective design approach to achieve software design agility by modelling change as a vector and tracking it to aid refactoring decisions.

     

    Preface about the talk

    Software design is a field that has always fascinated me and I have tried to be an obedient student trying to learn this art. Like any other design problem, software design is also a wicked problem. Horst Rittel and Melvin Webber defined a “wicked” problem as one that could be clearly defined only by solving it, or by solving part of it .This paradox implies, essentially, that you have to “solve” the problem once in order to clearly define it and then solve it again to create a solution that works.

    Hence you need an architect with magical powers to get your design correct in the first go .This is the core philosophy behind emergent design in which we do not think too much about future . As Uncle Bob sarcastically points out, your customers somehow knows your design and they will come up with a requirement that will break your assumptions and thus your design. In emergent design you embrace aggressive refactoring religiously and few teams rebelliously for the good. It has also been observed that during emergent design refactoring step more focus is towards class design than higher abstract architecture elements. This creates technical debt which can go unnoticed for a long time.

    In this talk I will be introducing a novel technique called change vector tracking that will address the above described problem. Change Vector Tracking is a reflective design approach to achieve software design agility by modelling change as a vector and tracking it through ceremonies like Change Vector Tracking meetings.

    Change vector tracking doesn’t prevent customers from coming up with requirements that would invalidate previous design assumptions, it helps us in monitoring these changes and aids in making informed decisions of where and when to redesign. It helps us keep a check on design debt which otherwise would be overseen and not addressed at the right time .Design debt is invisible to tools initially, only when it grows beyond a scale tools can catch it. Change vector tracking is a technique to capture this design debt in a very early stage. “A stitch in time saves nine”.