BDD/ATDD is all the rage these days.  The cynic in me took a cheap shot at it here.  But the optimist in me really REALLY thinks it sounds cool.  So I set off to try it….and failed twice.

First Fail:

I’m not involved in many greenfield projects so I attempted to convince my fellow colleagues to try BDD with their greenfield project.  I started with the usual emails, chock full of persuasive BDD links to videos and white papers.  Weeks went by with no response.  Next, we scheduled a meeting so I could pitch the idea to said project team.  To prepare, I read Markus Gartner’s “ATDD By Example” book, took my tester buddy, Alex Kell, out to lunch for an ATDD Q & A, and read a bunch of blog posts.

I opened my big meeting by saying, “You guys have an opportunity to do something extraordinary, something that has not been done in this company.  You can be leaders.”  (It played out nicely in my head before hand) I asked the project team to try BDD, I proposed it as a 4 to 6 month pilot, attempted to explain the value it would bring to the team, and suggested roles and responsibilities to start with. 

Throughout the meeting I encountered reserved reluctance.  At its low point, the discussion morphed into whether or not the team wanted to bother writing any unit tests (regardless of BDD).  At its high point, the team agreed to do their own research and try BDD on their prototype product.  The team’s tester walked away with my “ATDD By Example” book and I walked away with my fingers crossed.

Weeks later, I was matter-of-factly told by someone loosely connected to said project team, “Oh, they decided not to try BDD because the team is too new and the project is too important”.  It’s that second part that always makes me shake my head.

Second Fail:

By golly I’m going to try it myself!

One of my project teams just started a small web-based spin-off product, a feedback form.  I don’t normally have the luxury of testing web products and it seemed simple enough so I set out to try BDD on my own.  I choose SpecFlow and spent several hours setting up all the extensions and NuGet packages I needed for BDD.  I got the sample Gherkin test written and executing and then my test manager job took over, flinging me all kinds of higher priority work.  Three weeks later, the feedback form product is approaching code complete and I realize it just passed me by.



  1. Unknown said...

    Agree, agree, COMPLETELY agree. Thank you for bringing light to the complexity of implementing this process. Not only does team need to be educated, but motivated and not distracted and constantly encouraged, rewarded, etc. So much talk and energy go into implementing improved processes like this, only to fail. Anyone have the secret?

  2. Tadas said...

    I'm sorry, but can't help just laugh... Not because of the results or efforts- no way. It's just sooooo typical... And that's why "that has not been done in this company" is true for most of the companies.

    And to be honest- I'm inspired by your courage. Coureage to take responsibility, to blow such a wind of change. You're the man, despite the failiours.

    Well, good luck and I still hope to see a success story here!

  3. Icke_ said...

    Hm. Don't think this is a special BDD-related problem. You find this kind of problem (like the fact of getting passed by by your own project) can happen always.

    When we started doing scrum our lead developer told us "Okay guys, until you're done and ready and know what to do I'll be my own 1-person-team and already start with the developement"... *dough*

    So, I don't see your second fail as a fail of BDD/ATDD in general, but more like your "personal" fail. If you had your toolset ready and you wouldn't have to start over messing around with the tools instead of "just using" them, your outcome might have been much better ;-)

Copyright 2006| Blogger Templates by GeckoandFly modified and converted to Blogger Beta by Blogcrowds.
No part of the content or the blog may be reproduced without prior written permission.