Monday, 25 July 2011

ATDD is like a fight in the playground.

Does anybody else find that ATDD is like a fight in the school playground?

I've had limited experience with ATDD but from what I've seen you have to be there from story creation (picking a fight) or at least you have to be very nearby (standing near the fighters and therefore at the front of the crowd) otherwise you'll miss it all (because you're stuck at the back of the crowd).

I've found that everybody is willing to get involved with writing the examples but not always together.

If you're not at the front or involved in the fight directly then you have to fight your way through to get involved.

I've found that sometimes before Dev or Test get near a story the AT's are already written. This might be because of a easy to use DSL or having BA's that can code.

Either way it means that the sharing of knowledge and shared understanding of the requirement that happens when people get together to write the AT's is missed out.

It also means there's no discussion. Why would you discuss what is already there and waiting?

It also means that the AT's are written to one person's perception rather than the team.

Which means there is potential for things to be wrong.

I've also found that sometimes Dev's are so eager to code (like kids to candy) that they write the AT's and are off coding and Testers have no idea what's in the AT's and may have to edit and/or add to them.

So how to you handle that? Is there a way? Unless you're monitoring what everybody is doing I don't think there is, all you can try and do is open up communication and ask to be involved in the AT writing and keep asking otherwise you'll be forgotten.

I think ideally the AT's should be written together and Dev's start coding, Test have a longer, deeper think and add more AT's and BA's have a longer, deeper think about whether things are heading the right way.

Sound crazy? What's your experience?


  1. I don't believe ATDD is meant to be a fight at all.

    My understanding is that ATDD/Specification by Example are meant to revolve around story workshops early on in a project.

    An engineer, tester and a product owner (product manager) assemble to discuss the details of a story. The goal of the workshop is to achieve shared understanding through concrete examples of the story between the stakeholder, developer and tester.

    The stakeholder/product owner makes the ultimate decision in this meeting. The role of the developer and tester are to provide their unique expertise in either identifying risks or implementation issues prior to starting development.

    Executable specifications in a domain specific language (or otherwise), concrete examples, and acceptance criteria are all fantastic byproducts of the shared understanding attained in this workshop.

    If your product managers are harboring a waterfall at the top of their process and developing specifications in isolation, there will be resistance to change in that workshop. If a product manager spends 3 months writing detailed specifications they will not be excited at the prospect of throwing any of it away.

    Ultimately, in a product owner-driven group the final decision belongs to the stakeholder/product owner. If the tester and dev vehemently desire a criteria and the stakeholder disagrees the discussion should move on to the next step.

    These are my .02 cents on ATDD fights. :-)

  2., thanks for the comments. I think I should clarify, I don't think it's meant to be done that way it's just how I've experienced it, if you're not there, you miss out.

  3. Interesting analogy Tony.

    How about taking the fight out of the school playground, and putting it in Madison Square Gardens?

    Instead of hoping people hear about the fight through the grapevine, put out huge billboards and advertising to attract viewers.

    You won't need to fight your way to the front of the crowd, because there will be adequate seating for everyone.

    The boxers will be accompanied by their coach and entourage, so they won't have to make all the decisions by themselves.

    There will be a referee to make sure everyone is playing fair and by the rules.

    Judges will keep scorecards, so that when the fight is over, we will remember who won and why.

    Once the spectacle is over and the dust has settled, there will be no "Heavyweight champion of the world" titles given out, but at least everyone can say they saw a clash they would never forget, and will be talking about for weeks on end.

    (roughly modelled on specification workshops

  4. Hi Tony,

    I am sorry to say, that it sounds like you had an awful experience. But as stated in the comments I dont think its what ATDD is meant to be.

    So I would start on the other end, before picking the next fights.

    Who initiated using ATDD in the first place? Is there any value someone expects from it? Compare to previous approaches, is this better or worse?

    Or even so, what are your organizations values around quality? If that is not a clear thing, I would suggest starting there. Since if the ATs are not taken seriously anyway by the developers, then its of no use actually that testers or BAs write them anyway.

    There are no easy answers, more than I can say hope you have better experiences in the future.

  5. Hi Sigge,

    Perhaps 'fight' wasn't the right to use, 'rush' might have been better.

    It wasn't a bad experience at all.

    What I meant was that eveybody was so eager to get moving that sometimes we needed to stop and collect ourselves together and then move on together.

    Instead, it was a situation that whoever was available wrote the tests which meant that the discussions were missed.