Comments on: “When Does the Spec Freeze?”

By: Antony

Antony — Thu, 09 Jun 2011 15:43:03 +0000

Please, tell me what does “to freeze a spec mean”? What is the “spec”?

By: www.webbiru.com

www.webbiru.com — Thu, 03 Dec 2009 16:53:02 +0000

Managing Product Development » “When Does the Spec Freeze?”…

Managing Product Development » “When Does the Spec Freeze?”…

By: Dwayne Phillips

Dwayne Phillips — Sat, 10 Oct 2009 00:04:33 +0000

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.

By: Markus Gärtner

Markus Gärtner — Tue, 06 Oct 2009 21:06:29 +0000

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.

By: Rafael Alvarez

Rafael Alvarez — Tue, 06 Oct 2009 14:52:34 +0000

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.

By: johanna

johanna — Mon, 05 Oct 2009 19:43:09 +0000

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.

By: Josh

Josh — Mon, 05 Oct 2009 19:12:07 +0000

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.

By: Andrew Buck

Andrew Buck — Mon, 05 Oct 2009 18:52:46 +0000

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!