Return to Answer

1. In a team reluctant to adopt BDD, there likely are no "arguments" that you can use to "convert" your colleagues into full-scale adoption.
    
   I think the best you can do is to convince them to give it a try ("smoke test", "dry run", "pilot project") - especially if you make it perfectly clear that you'll drop the idea if testing results are negative.
2. Your approach for finding anecdotal evidence fits perfectly to the idea of convincing team to give it a try. For that, I'd simply search the web for something like "Behavior Driven Development success story" and pick what feels easier to use to me.
3. There are couple counter arguments I can think of that could suggest that your wish to convert the team efforts to BDD might be in error.
    
   None of these are particularly constructive, especially from the point of view of a "change advocate" but unfortunately you'll likely have to deal with exactly this kind rhetoric (BTDTGTTS):
    

• you can't guarantee that overall team productivity will improve
• you can't guarantee that efforts invested into adopting BDD will give substantial ROI
• team was doing sufficiently well without BDD, risk of changing current approach is not justified
• Google (or Microsoft, or IBM - just fill in the name of whatever "respectable" software vendor) are going just fine without BDD, which "proves" that BDD is not necessary

Per my experience, least painful way to address counter arguments like listed above was by performing a limited controlled test run for a proposed change.

"Limited testing" status essentially invalidates three of four arguments above, except for one about "respectable vendor", which could be countered by providing anecdotal evidence of success story (anecdotal evidence won't probably work for a "big bang change" but for limited testing it is good enough).

If the change is indeed worthwhile and test run is arranged properly, you will notice a positive shift in team and management attitude, making transition to full-scale change smooth and painless.

Another benefit of limited test run is that it lets you clarify and adjust target process detail without causing too much trouble and with lower risk of "reputation damage" to the idea. Every time I participated in such test runs, I was pleasantly surprised to find out how smooth it was to switch to full-scale adoption having most important details set and clarified in test run.

1. In a team reluctant to adopt BDD, there likely are no "arguments" that you can use to "convert" your colleagues into full-scale adoption.
    
   I think the best you can do is to convince them to give it a try ("smoke test", "dry run", "pilot project") - especially if you make it perfectly clear that you'll drop the idea if testing results are negative.
2. Your approach for finding anecdotal evidence fits perfectly to the idea of convincing team to give it a try. For that, I'd simply search the web for something like "Behavior Driven Development success story" and pick what feels easier to use to me.
3. There are couple counter arguments I can think of that could suggest that your wish to convert the team efforts to BDD might be in error.
    
   None of these are particularly constructive, especially from the point of view of a "change advocate" but unfortunately you'll likely have to deal with exactly this kind rhetoric (BTDTGTTS):
    

• you can't guarantee that overall team productivity will improve
• you can't guarantee that efforts invested into adopting BDD will give substantial ROI
• team was doing sufficiently well without BDD, risk of changing current approach is not justified
• Google (or Microsoft, or IBM - just fill in the name of whatever "respectable" software vendor) are going just fine without BDD, which "proves" that BDD is not necessary
• non-BDD approaches weren't given a fair chance in comparative testing
• BDD might be generally OK but for this and that module / project it is not applicable

Per my experience, least painful way to address counter arguments like listed above was by performing a limited controlled test run for a proposed change.

"Limited testing" status essentially invalidates three of four arguments above, except for one about "respectable vendor", which could be countered by providing anecdotal evidence of success story (anecdotal evidence won't probably work for a "big bang change" but for limited testing it is good enough).

If the change is indeed worthwhile and test run is arranged properly, you will notice a positive shift in team and management attitude, making transition to full-scale change smooth and painless.

Another benefit of limited test run is that it lets you clarify and adjust target process detail without causing too much trouble and with lower risk of "reputation damage" to the idea. Every time I participated in such test runs, I was pleasantly surprised to find out how smooth it was to switch to full-scale adoption having most important details set and clarified in test run.

1. In a team reluctant to adopt BDD, there likely are no "arguments" that you can use to "convert" your colleagues into full-scale adoption.
    
   I think the best you can do is to convince them to give it a try ("smoke test", "dry run", "pilot project") - especially if you make it perfectly clear that you'll drop the idea if testing results are negative.
2. Your approach for finding anecdotal evidence fits perfectly to the idea of convincing team to give it a try. For that, I'd simply search the web for something like "Behavior Driven Development success story" and pick what feels easier to use to me.
3. There are couple counter arguments I can think of that could suggest that your wish to convert the team efforts to BDD might be in error.
    
   None of these are particularly constructive, especially from the point of view of a "change advocate" but unfortunately you'll likely have to deal with exactly this kind rhetoric (BTDTGTTS):
    

• you can't guarantee that overall team productivity will improve
• you can't guarantee that efforts invested into adopting BDD will give substantial ROI
• team was doing sufficiently well without BDD, risk of changing current approach is not justified
• Google (or Microsoft, or IBM - just fill in the name of whatever "respectable" software vendor) are going just fine without BDD, which "proves" that BDD is not necessary

Per my experience, least painful way to address counter arguments like listed above was by performing a limited controlled test run for a proposed change.

"Limited testing" status essentially invalidates three of four arguments above, except for one about "respectable vendor", which could be countered by providing anecdotal evidence of success story (anecdotal evidence won't probably work for a "big bang change" but for limited testing it is good enough).

If the change is indeed worthwhile and test run is arranged properly, you will notice a positive shift in team and management attitude, making transition to full-scale change smooth and painless.

Another benefit of limited test run is that it lets you clarify and adjust target process detail without causing too much trouble and with lower risk of "reputation damage" to the idea. Every time I participated in such test runs, I was pleasantly surprised to find out how smooth it was to switch to full-scale adoption having most important details set and clarified in test run.

1. In a team reluctant to adopt BDD, there likely are no "arguments" that you can use to "convert" your colleagues into full-scale adoption.
    
   I think the best you can do is to convince them to give it a try ("smoke test", "dry run", "pilot project") - especially if you make it perfectly clear that you'll drop the idea if testing results are negative.
2. Your approach for finding anecdotal evidence fits perfectly to the idea of convincing team to give it a try. For that, I'd simply search the web for something like "Behavior Driven Development success story" and pick what feels easier to use to me.
3. There are couple counter arguments I can think of that could suggest that your wish to convert the team efforts to BDD might be in error.
    
   None of these are particularly constructive, especially from the point of view of a "change advocate" but unfortunately you'll likely have to deal with exactly this kind rhetoric (BTDTGTTS):
    

• you can't guarantee that overall team productivity will improve
• you can't guarantee that efforts invested into adopting BDD will give substantial ROI
• team was doing sufficiently well without BDD, risk of changing current approach is not justified
• Google (or Microsoft, or IBM - just fill in the name of whatever "respectable" software vendor) are going just fine without BDD, which "proves" that BDD is not necessary

Per my experience, least painful way to address counter arguments like listed above was by performing a limited controlled test run for a proposed change.

"Limited testing" status essentially invalidates three of four arguments above, except for one about "respectable vendor", which could be countered by providing anecdotal evidence of success story (anecdotal evidence won't probably work for a "big bang change" but for limited testing it is good enough).

If the change is indeed worthwhile and test run is arranged properly, you will notice a positive shift in team and management attitude, making transition to full-scale change smooth and painless.

Another benefit of limited test run is that it lets you clarify and adjust target process detail without causing too much trouble and with lower risk of "reputation damage" to the idea. Every time I participated in such test runs, I was pleasantly surprised to find out how smooth it was to switch to full-scale adoption having most important details set and clarified in test run.

1. In a team reluctant to adopt BDD, there likely are no "arguments" that you can use to "convert" your colleagues into full-scale adoption.
    
   I think the best you can do is to convince them to give it a try ("smoke test", "dry run", "pilot project") - especially if you make it perfectly clear that you'll drop the idea if testing results are negative.
2. Your approach for finding anecdotal evidence fits perfectly to the idea of convincing team to give it a try. For that, I'd simply search the web for something like "Behavior Driven Development success story" and pick what feels easier to use to me.
3. There are couple counter arguments I can think of that could suggest that your wish to convert the team efforts to BDD might be in error.
    
   None of these are particularly constructive, especially from the point of view of a "change advocate" but unfortunately you'll likely have to deal with exactly this kind rhetoric (BTDTGTTS):
    

• you can't guarantee that overall team productivity will improve
• you can't guarantee that efforts invested into adopting BDD will give substantial ROI
• team was doing sufficiently well without BDD, risk of changing current approach is not justified
• Google (or Microsoft, or IBM - just fill in the name of whatever "respectable" software vendor) are going just fine without BDD, which "proves" that BDD is not necessary

Per my experience, least painful way to address counter arguments like listed above was by performing a limited controlled test run for a proposed change.

"Limited testing" status essentially invalidates three of four arguments above, except for one about "respectable vendor", which could be countered by providing anecdotal evidence of success story (anecdotal evidence won't probably work for a "big change" but for limited testing it is good enough).

If the change is indeed worthwhile and test run is arranged properly, you will notice a positive shift in team and management attitude, making transition to full-scale change smooth and painless.

Another benefit of limited test run is that it lets you clarify and adjust target process detail without causing too much trouble and with lower risk of "reputation damage" to the idea. Every time I participated in such test runs, I was pleasantly surprised to find out how smooth it was to switch to full-scale adoption having most important details set and clarified in test run.

1. In a team reluctant to adopt BDD, there likely are no "arguments" that you can use to "convert" your colleagues into full-scale adoption.
    
   I think the best you can do is to convince them to give it a try ("smoke test", "dry run", "pilot project") - especially if you make it perfectly clear that you'll drop the idea if testing results are negative.
2. Your approach for finding anecdotal evidence fits perfectly to the idea of convincing team to give it a try. For that, I'd simply search the web for something like "Behavior Driven Development success story" and pick what feels easier to use to me.
3. There are couple counter arguments I can think of that could suggest that your wish to convert the team efforts to BDD might be in error.
    
   None of these are particularly constructive, especially from the point of view of a "change advocate" but unfortunately you'll likely have to deal with exactly this kind rhetoric (BTDTGTTS):
    

• you can't guarantee that overall team productivity will improve
• you can't guarantee that efforts invested into adopting BDD will give substantial ROI
• team was doing sufficiently well without BDD, risk of changing current approach is not justified
• Google (or Microsoft, or IBM - just fill in the name of whatever "respectable" software vendor) are going just fine without BDD, which "proves" that BDD is not necessary

Per my experience, least painful way to address counter arguments like listed above was by performing a limited controlled test run for a proposed change.

"Limited testing" status essentially invalidates three of four arguments above, except for one about "respectable vendor", which could be countered by providing anecdotal evidence of success story (anecdotal evidence won't probably work for a "big bang change" but for limited testing it is good enough).

If the change is indeed worthwhile and test run is arranged properly, you will notice a positive shift in team and management attitude, making transition to full-scale change smooth and painless.

Another benefit of limited test run is that it lets you clarify and adjust target process detail without causing too much trouble and with lower risk of "reputation damage" to the idea. Every time I participated in such test runs, I was pleasantly surprised to find out how smooth it was to switch to full-scale adoption having most important details set and clarified in test run.