At a prospective client, a senior manager asked me, “In agile, when does the spec freeze?” I said it either didn’t, or did at the end of any iteration in which people wrote a spec. He had a puzzled look on his face, so I explained that if you discuss how to design or what done means for a feature with the people who are asking for the feature and with the other people who will be implementing it, you might not need a spec at all. If you do need a spec, then it will go into the backlog for a given iteration, and it’s as done as it will be by the end of that iteration.
He still looked confused. I asked him, “When does the spec freeze now?” He smiled, and pointed to his “Design freeze” gate on his process picture. “I bet you a coffee that you can ask any developer here and that they cannot point to one spec that didn’t change after that or any spec that was right at the end of the project.” He took the bet.
Over the next two days, he asked every developer he encountered. Some of them laughed at the question. “The specs are never right. They freeze, but they should change.” One project manager said, “I can’t remember a project where we actually froze a spec for more than a day or two.”
The manager was chagrined. “How will people know what they have to do?” I replied, “They talk to each other. Sometimes loudly. Sometimes they disagree violently. Sometimes they don’t understand what the product owner wants, and the product owner has to walk them through the request a bunch of times, refining what done means as they walk through the request. But they will do what the product owner wants. But you don’t ever have a spec that’s out of date. You may not have a spec. You should have a bunch of tests that tell you how the feature is supposed to work. Would you rather have working software or a spec?”
My colleague wants working software. He’s just quite suspicious about how he’s going to get it. He’s never seen design by verbal contract; he’s only seen design by written contract. He’s concerned.
The reason he’s considering agile is that he doesn’t get software that works the way he wants. He thought he had specs, and now he realizes he doesn’t have them either. We’ll see how my simulation convinces the technical staff of how they can build and test in small chunks, so that they do get working software.
