"When Does the Spec Freeze?"

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.

8 Replies to “"When Does the Spec Freeze?"”

  1. There is always a point at which the spec must freeze; otherwise, either quality will suffer in some way, or the wrong functionality may not be delivered, or there won’t be a truly “Agile” process because you’ll be spending more time than required arguing over the content of the spec.

    The concept that most people miss is that there is a spec, there might be iterations to that spec, and somewhere in between there is a change management process that helps control product content, feature, and quality.

    Where it can all go off the rails is when you have a supposedly agile process that keeps changing spec and never delivering the product (where is the agility in that?) versus prudent feature-to-release definition that changes based on change control. Having managed a so-called agile process back to an actual delivery, I can say the latter works at controlling what was otherwise chaotic at its best.

    Cheers!

    1. Andrew, I have yet to work with a project truly doing agile that required specs. Even the regulated-industry projects, once the auditors got on board, did not require specs. They did, however, have tons of automated tests and explanations about what the tests tested and how. In that sense, they had specs. Clearly, your experience is different from mine.

  2. Maybe the question should be more focused to: When should the client stop requesting changes to the spec? It sounds like all the examples you gave were internally driven.

  3. In my experience, the problem is not the act changing of the spec, is the lack of control or focus when changing it.

    Or worse, the underlying lack of trust that requires the spec freeze in the first place.

  4. Your story shows to me that your colleague seems to confuse the specification document with the specification. What he actually has after the spec freeze is the document, not the specification at all.

  5. I once worked on a project where the spec had been frozen five years earlier – legitimately frozen. The team was trying to build a technical marvel, and they eventually succeeded. The project was troubled and people kept looking for a frequently changing spec (often a cause of project trouble). They never found any feature creep or changing spec. They all scratched their heads and wondered about this, but it was true.

  6. Pingback: www.webbiru.com

Leave a Reply