Tuesday, May 19, 2009


This is the tale of Yet Another Meeting(tm). But it's a good one!

During the development and release cycle, we hold a meeting that we call the blockers meeting, and it's been a really helpful tool.

This is a meeting to discuss new knowledge about the software to be released, and to go over progress on the items that are currently blocking the release. "Blockers" are anything that would cause you to not choose to ship the product. A blocker can be an unfinished feature, a bug, a regression in test coverage, a performance change, hardware supply chain problems, etc.

We do this meeting quite often:
  • during the initial development cycle, once a week
  • between feature freeze and code freeze, three times a week
  • after code freeze and before release, daily (weekdays only!)
I know it sounds like a lot. Bear with me, it's not that bad.

You need the people who are materially affecting the release here. For us that's the dev leads, the QA lead, someone from support, and someone from product management. If the release has a customer beta we also include someone from the sales engineering team.

Agenda and Duration
This meeting happens often, so it had darn well better be quick. We have work to do! We do this:
  • All new items discovered (5-10 minutes). We're here to decide whether they should be blockers or not; that's all. In addition, it's okay to propose an alternative route that may affect whether this is a blocker (e.g., "Let's document our way around this."). This is not the place to talk about how we're going to fix them.
  • All items we couldn't decide on before (7-10 minutes). Sometimes we have an issue we don't understand well enough to say whether it will block a release. We revisit those and figure out what we need to know to determine whether it's a blocker, and hopefully move it at this point.
  • Update on any in-queue items (5-10 minutes). We don't go through every issue, but anyone who wants to bring up an issue can here. Usually this is for something that's transitioning state (e.g., "We fixed this and are handing it to QA"). Sometimes it's a request for help with the problem. A few times changed understanding will change whether it's a blocker or not, and that's discussed here.
Total elapsed time is 30 minutes or less. We usually run about 15 minutes, and sometimes toward the end we'll have nothing new to discuss, so we wind up with 0.5 minute meetings ("Hi, I've got nothing. Anyone else? ... Cool. Have a good one!").

Sounds a lot like a standup, and it is, really (yes, we stand up). It's just a standup with a special release-oriented purpose. And it's amazing how much insight we get just from having to stand up often and say, "here's what we've found and here's what we're doing about it". It's a great way to prevent problems from festering in a corner, and to make sure that everyone is working with as much information as possible. Give it a shot!

No comments:

Post a Comment