In one of my earlier posts, I briefly referred to the Release Meeting (it’s here if you missed it… http://wp.me/p1gsHK-f). I’ll take a bit of time here to discuss what release meetings are and what they, well, probably shouldn’t be.
After sitting through scores of Release Meetings in my career, I’ve become a bit jaded. I’ve even been heard to say “If you need to have a Release Meeting, you’re not ready to release.” Maybe I’ve just been in the wrong kind of Release Meetings… the kind that don’t go well…
Release Meetings are those “go/no-go” meetings that management (VP and above) likes to have on the day of or the day before the release date. These meetings are typically scheduled for an hour or two, and everyone (literally, sometimes) is invited. Many times, these meetings are unsupervised – i.e., no one really sets or controls the agenda. Often, the discussion degrades to a discussion about which bugs are open, which tests failed, and what customer will pull their business if they don’t receive the release NOW. On more than one occasion, (as ranking guy with “QA” in my title), I’ve been asked point blank “Are we ready to ship?” …everyone stares… “Yes” better be the only answer that comes out, right?
If you can relate to any of the above, I’m sorry. Let’s discuss alternatives that are probably a bit more healthy. These options are being employed more and more by organizations which understand how quality can permeate their entire process. The first option is to actually have the Release Meeting (gasp!). Not the option you thought was coming, right? Some form of release readiness meeting will always be required, but it can be constructive, moderated, and informative. In a scrum environment, this meeting might also be the Iteration Review – or at least follow a similar format.
For an excellent Release Meeting, someone in a leadership role associated with the team – PM, Scrum Master, Product Owner, Dev Manager, QA Manager, etc – should lead and moderate the discussion. The agenda should begin with a review of the requirements (or stories), which sets the tone for what was to be accomplished. In some cases, a business review may also be wrapped into the discussion. Depending on the audience and format, the middle of the meeting should include a demonstration of the features (or a discussion about the implementation), and a presentation of whatever metrics are deemed relevant and necessary. This could be bug metrics, test coverage measurements, unit test completion, etc. Note that the measureables may correspond to some sort of checklist or release criteria used by the team.
At this point in the meeting, everyone has a clear picture of precisely what was needed and what has been developed and tested. In some cases, the result may be obvious (Ship It!). In others, perhaps a smaller team needs to have further discussion. Either way, the meeting time was maximized by the agenda, and the follow-up discussions can be healthy. A decision made in this case is made from a position of knowledge.
Other alternatives to the formal Release Meeting include using a simplified Release Readiness Checklist – which would contain a set of metrics and acceptable values for those metrics. A sustaining organization, or a team working with 3rd Party or OEM vendors may implement this method. Another option might be to have a weekly “release update” meeting – or even a wiki tracking progress on a regular basis. Discussing the status and making it well known to the key stakeholders far in advance of the release date provides them (and you) with the maximum amount of flexibility to deliver the right software in the right timeframe.
But… if the Release Meeting is all about everyone looking at the QA guy and asking “Are we ready” – the only answer anyone wants to hear is “Yes”.