At 02:28 PM 8/24/01 -0700, I wrote:
>Thus, the net effect would be as follows. Before we can release, we need
>to explicitly confirm that:
>
> - all level one ("must have") packages have met this standard
> - all level two ("should have") packages are either in or out
> - all level three ("nice to have") packages had fair warning to opt in
Folks who knew me back in the mid-nineties will recognize this as my
infamous "go / no go" walkaround check, where a designated group of folks
shared the responsibility for making their slice of the final release
decision.
As we got close, everyone produced and double-checked their portions of the
release candidate(s) in parallel. Each of the designated folks then had to
go on record by explicitly saying "go" or "no go", so we could focus on a
concrete set of "no go" reasons, clear them up rapidly, and get to "go" all
around.
If this sounds too formal, I could usually do the entire check in one
ten-minute walk around the building. The conversation at each stop would
usually be as short as:
me: "Go?"
you: "Go"
and then off to the next stop. Or, the slightly longer:
me: "Go?"
you: "No go. X and Y are still issues."
me: "How much longer? Need help?"
you: ...
By the end of the loop, we had all the "no go" issues in one place, knew who
was done or needed help, and farmed out the work accordingly. It usually
wasn't long before it was time to do another "go / no go" walkaround.
If this process sounds like it drags out too long, you radically
underestimate the peer pressure effect here. :-) With enough advance
warning, you really feel like a schmuck if problems with your work are the
last "no go" and the entire team is working to help you find a fix so the
release can go.
Paul
