Johanna Rothman, in in her product development blog talks about when a spec should freeze. She basically said "specs never freeze, people communicate about what they want all the time".
What caught my eye was one commenter that said "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". That's kind of true, but the problem is not with the lack of spec freeze.
What caught my eye was one commenter that said "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". That's kind of true, but the problem is not with the lack of spec freeze.
There are two reasons we would like to freeze the spec: either we're working with several groups that don't belong to the same team (ie, hardware and software team), and the spec is the point of communication between them, or we work with just one team but want the team to be very sure what we want delivered. The former is material for another post, so I'll focus on the later reason.
One thing about freezing specs is very unusual: it is one of the very uncommon points where all the actors involved agree that must be done. Why? Because it adds an illusion of predictability (we know what is going to be delivered way in advance), and is a shield to deflect blame. This blame deflection eagerness can make the act of changing the spec a very expensive process. The irony is that by protecting themselves, they are increasing the chances of failure.
In my experience, assuming that the team is able to deliver whatever is on the spec, the problems is not the act changing of the spec that brings the problem, but the lack of focus when changing it and the unwillingness to change the schedule.
If the team has the golden pair of good Product Owner and Project Manager, both will make sure that the changes to the spec are really needed and will negotiate any change in the scope.
If all the actors trust each other, and all the changes to specs and schedule are visible to everyone, there is no need to freeze the spec.
I have seen all scenarios: I had an spec that was "open" for about 6 months. It grew in scope. We even rewrote complete parts of already implemented the functionalities (early stories) because the business side discovered that they got it wrong the first time. And it was ok. The business side was deligthed with the end result.
On the other (darker) side, I had a spec frozen that covered a 3 month development. We required 2 more requirements after that (frozen, of course) to get to what the business needed. It took us 6 months, we delivered what was on the spec, by the letter. But the business was not deligthed.
And finally, I witnessed (as an outsider, thanks God) specs changing weekly, in an uncontrolled way, adding scope and changing functions that where implemented the week before in a radical way... without changing the schedule.
In short, trust each other. Then you won't need a spec freeze, only a "we have enough to start working" flag on the spec.
One thing about freezing specs is very unusual: it is one of the very uncommon points where all the actors involved agree that must be done. Why? Because it adds an illusion of predictability (we know what is going to be delivered way in advance), and is a shield to deflect blame. This blame deflection eagerness can make the act of changing the spec a very expensive process. The irony is that by protecting themselves, they are increasing the chances of failure.
In my experience, assuming that the team is able to deliver whatever is on the spec, the problems is not the act changing of the spec that brings the problem, but the lack of focus when changing it and the unwillingness to change the schedule.
If the team has the golden pair of good Product Owner and Project Manager, both will make sure that the changes to the spec are really needed and will negotiate any change in the scope.
If all the actors trust each other, and all the changes to specs and schedule are visible to everyone, there is no need to freeze the spec.
I have seen all scenarios: I had an spec that was "open" for about 6 months. It grew in scope. We even rewrote complete parts of already implemented the functionalities (early stories) because the business side discovered that they got it wrong the first time. And it was ok. The business side was deligthed with the end result.
On the other (darker) side, I had a spec frozen that covered a 3 month development. We required 2 more requirements after that (frozen, of course) to get to what the business needed. It took us 6 months, we delivered what was on the spec, by the letter. But the business was not deligthed.
And finally, I witnessed (as an outsider, thanks God) specs changing weekly, in an uncontrolled way, adding scope and changing functions that where implemented the week before in a radical way... without changing the schedule.
In short, trust each other. Then you won't need a spec freeze, only a "we have enough to start working" flag on the spec.
