I couldn’t get people interested in acceptance tests. On Mike Cohn’s suggestion, I just picked a story, went to the developer working on a story, and asked, “Could we pair up writing a test on this story?” Developers would see how easy it is. In the next sprint I picked a different story and a different person. We right away found a bug, where he didn’t really understand the requirement. So the developers immediately saw the value.

When a team has a good understanding of TDD, making the case for executable speciications is easy: Explain them as tests for business functionality.

How to begin changing the team culture

For the most part, implementing Speciication by Example involves a cultural change— getting people to think about collaborating on requirements and changing the way business people, developers, and testers contribute to speciications. Here are some helpful ideas for changing your team culture.

Avoid “agile” terminology

When: Working in an environment that’s resistant to change

Agile software development methods are plagued with terminology and buzzwords.

Scrums, stand-ups, user stories, backlogs, masters, pair programming, and other terms like these are easily misunderstood and cause confusion. To some, they can even be overwhelming and scary. Anxiety caused by jargon is one of the biggest reasons why people push back and resist any change to their process—or passively wait for it to fail. In my experience, many business users ind it hard to understand technical terms used by the development team, making it hard for them to grasp ideas related to process improvement and engage with the team.

Don’t refer to user stories, acceptance tests, or executable speciications—implement Speciication by Example without offering deinitions. This will provide people who want to oppose you with less ammunition. Explain Speciication by Example as the process of gathering examples to clarify requirements, deriving tests, and automating them. Everything else will be left to discovery.