Effective delivery with short iterations or in constant low requires removing as many expected obstacles as possible so that unexpected issues can be addressed. Adam Geras puts this more eloquently: “Quality is about being prepared for the usual so you have time to tackle the unusual.” Living documentation simply makes common problems go away.

Speciication by Example is the solution: a means for dealing with the usual so that we have more time to deal with the unusual within the few days or weeks of a software delivery cycle. Living documentation is now a requirement for success.

In this chapter, we’ll look at how to begin changing process and team culture so you can implement Speciication by Example. We’ll review three team case studies that represent different ways to integrate collaboration on speciications into iterations and low development. Finally, I present useful ideas for itting this process into development environments that require sign-off and traceability on requirements.

How to begin changing the process

Starting a process change is never easy, especially if you’re trying to fundamentally change how team members collaborate. To get over the initial resistance and build a case for further changes, most teams started by implementing a practice that improved product quality or saved time over the short term. The most common starting points were these:

•If there’s already a process change going on, use it to implement key ideas of Speciication by Example.

•Use the ideas of Speciication by Example as inspiration for improving product quality.

•Implement functional test automation, for teams that don’t have automated functional tests.

•Introduce automated executable speciications, for teams that have test automation separate from development.

•Use test-driven development (TDD) as a stepping-stone, for teams that practice it.

All of these starting points will produce beneits in the short term and lead to further improvements.