If you ask most playwrights what they think about reviewers, you'd best duck and cover. Ask most technical writers the same thing, and you'll get the same reaction.

For better or worse, many technical writers think of reviews as a necessary evil. Even if you can get the reviewers' attention, which isn't always easy, extracting comments that are relevant and useful can be extremely hard.

How does the review process change when the project team adopts the Agile methodology, or when user-generated content is involved? For the most part, it becomes easier and more effective.

On an Agile project, scheduling the reviews might at first glance seem to be harder. An iteration or a sprint is a tightly scheduled set of activities, and the review has to fit precisely into the schedule.

Fortunately, though, each review involves only a small set of topics. Additionally, there are only a few reviewers -- usually just the members of the scrum team. So, instead of dropping a large documentation set onto a large group of reviewers and waiting a long time for feedback, the review is focused and quick. Because the reviewers' minds are focused on the same small set of product features that are covered in the review, their comments are useful and on point.

The same goes for user-generated content because the scope of the review is so small. It might be harder to identify the right SME or SMEs, but the reviews can be done quickly and can be scheduled at the SMEs' convenience.

So it's all good, right? Well, yes, for the most part it is. However, the project manager still needs to consider a few other things:

• On an Agile project, make sure that the scrum master understands the importance of documentation reviews and makes time for them.
  
• With smaller, more targeted reviews, it's easy to lose sight of the big picture. So it might pay to enlist one or two trusted SMEs to step back and take a look at how the whole documentation package holds together.
  
• It's also easy to overlook legacy documentation. Make sure that doesn't happen.
  
• Because there are more reviews, and because they have to be scheduled to fit precisely into the sprints, you have to keep careful track of them. When will each review occur? Who are the reviewers? How long do the reviewers have to comment? Most important, do they know what the schedule is and what's expected of them?

What other best practices can you share?