Agile projects

Give feedback early; give feedback often. Especially the early part.

When it comes to writing a paper or planning a campaign or picking a cause to focus on, a little bit of feedback at the beginning is worth hundreds of micro-edits or small optimizations later on. The topic that you write about can matter more than everything else in your whole article. If you complete a research paper about something unimportant, it doesn't much matter how well-written and well-researched the piece is (unless your goal is to establish prestige as a writer or build an audience that you can then direct toward your more important essays). If you pick an inefficient activism campaign, it doesn't much matter how well you carry it out (except for getting practice, personal experience, etc.).

Most of the time, feedback won't have the dramatic effect of reorienting the entire direction of a paper or campaign, but it may have smaller impacts, such as whether the author considers a given argument or whether the campaign undertakes measurement of its impact. A stitch in time saves nine, and it's easier (both physically and cognitively) to improve something at the beginning than near the end.

So why is it that people sometimes hesitate to share drafts, ideas, plans, etc. until they're almost completed? Maybe one reason is that slow feedback is sometimes more customary, and people fear that if they share totally incomplete drafts or brainstorms, people would judge them for not being thorough and polished and not having considered such-and-such objection. If this is the case, we should work to change the culture of feedback among the people we know, to make it clear that preliminary drafts are potentially better than polished products in terms of the benefit of giving feedback per unit time.

Another reason can be that when people comment on a rough draft, the author may already know that he needs to fix most of what the reviewer points out. But this can be largely allayed if the reviewer understands the stage where the project is. You don't (usually) give sentence-level edits on a paper outline. Also, the author could sketch out the areas that he knows are incomplete so that the reviewer won't comment on those.

The title of this post comes from agile software development, which is one area where the principles I described have been well recognized.