I want my SDD (not) - Agile technical writing

One of the first questions I get from writers facing Agile is, "so if we don't have functional specs or software design documents, how can we (as writers) plan/write doc plans/user information plans/etc?" While it's true that the Agile methodologies favor working software over comprehensive planning documents, like functional specs and software design documents (SDDs), you still have plenty of options for gathering the information that you need.

Release planning: On the development side, the managers and tech leads always attend, as well as some of the developers. If the writer assigned to the project cannot attend, then the applicable Tech Pubs manager or lead writer should attend. These meetings don't get down to the nitty-gritty of the release, but they provide an overview of the release and the release theme. The meetings that I've attended always yield a list of critical features that must be completed for the product to be releasable, as well as high-level plans for each iteration.

Iteration planning: Most iterations (or sprints) at BMC Software last two weeks. On the first day, all stakeholders (developers, QA, writers, and perhaps an architect) meet to devise a plan for the remainder of the iteration. Writers should make attending these meetings a high priority. Although you could skip the meeting and rely on the final iteration plan, you'd miss the discussions that led to the finalized plans. Planning discussions also provide you an opportunity to ask questions and raise issues that could affect the documentation or the product.

Story cards: During iteration planning, the work is divided into cards. Each card represents a feature that will be completed during the iteration.

Acceptance criteria: Each card contains criteria that the developer uses to determine when development is finished. The QA engineer uses that information to verify that the feature works as expected. Writers can also use acceptance criteria to determine the sort of documentation tasks that must be completed for the card.

Use cases: Your project managers (the owners for the product), often write use cases, which shape the features and requirements for the release. Use cases provide valuable information about the purpose of the feature and the motivation of the user to use the feature. Sometimes this is as close as you come to interviewing the user of your product.

Wikis: Most development teams use wikis or another collaboration tool to post design information. Writers can view and contribute to this information.

After a few iterations (or maybe a release or two), you'll wonder why you cared about the SDDs or specs that rarely resembled the final product.