Because cloning is not an option - Agile technical writing

If you're a writer assigned to one project, you're the lucky one and you can quit reading now. However, if you're like most writers, you're an active member of two or more projects--perhaps as many as four or five. If you're like me, the ScrumMasters of two or three of your teams schedule their iteration planning meetings for the same time.

Those of us who have been involved with Agile development agree that iteration planning is essential and you should do everything reasonable to attend. Because cloning is above and beyond reasonable expectations, you might try some of the tactics that have worked for me. When you're on multiple teams, you learn that each team has its own personality and some tactics work better with some teams than others.

Plan ahead

Most of the Agile development teams learned early on that preplanning was essential for a successful day of iteration planning. My teams use Rally to manage their iterations. I take advantage of their prepanning efforts to plan the documentation effort. On the Friday before iteration planning, I start checking out the development plans to see what might need documentation. On the day of iteration planning (but before iteration planning begins), I recheck my Rally projects and add the documentation tasks. I then print out a summary report from each Rally project and take those reports with me. I use the preplanned activities to determine which iteration planning meeting to attend. If necessary, I'll move among the meetings. Regardless of how long I can stay (or whether or not I attend) a planning meeting, my tasks (or many of them) are already in Rally.

Have someone watch your back

My QA teammates are pretty good at knowing what development tasks require documentation. Generally speaking, they understand that any development that affects the UI is a good candidate for documentation. When I'm not there, they'll have the ScrumMaster add cards or tasks for me. They sometimes miss development changes that affect conceptual notions about the product, but they're correct more often than not.

Documentation in the acceptance criteria

I've discussed this idea with one of my teams, although it hasn't been implemented yet. When the project team is discussing what determines when the "card" is done, have then add a bullet for the documentation. I encourage teams to start including documentation in the list of criteria that determines "doneness." Documenting features isn't something that affects just the writer. Developers (and sometimes QA) need to allocate some of their time to assist with the documentation effort.

Touch base at the end of the day

I've learned this the hard way--writers must review their tasks with the ScrumMaster or a development lead. More than once I've been deceived by the meaning of development cards. What seemed like an "under the covers" development task was actually a user-facing task that needed documentation. Let your leads or ScrumMasters know that you'll be calling them. If necessary, set up a recurring meeting request.

Corner 'em

Once or twice during a release, we hop on a bus and travel to the Austin office (from Houston) for iteration planning. During the last trip, the ScrumMaster of one team sat in front of me, while the lead for another sat behind me. With these guys basically captive, I pulled out my Rally summary reports and reviewed the development plans for the iteration. With developers also on the bus, we were able to address a couple of my questions. Even though I wasn't going to be able to attend these two planning meetings, I still was able to have my own mini-iteration planning.