If you’ve documented software over the last five years, you’ve no doubt heard a bit (or a lot) about “Agile” software development. (If not, this Wikipedia page will get you started.) In contrast to more traditional models of development that emphasize sticking to a set plan and following a linear process until the entire project is completed, Agile favors iterative development and regular re-evaluation of the product to assess whether it’s successfully meeting its requirements.
While most software developers are becoming well-versed in Agile methodologies and understand how to navigate them successfully, the writers who work with these developers may be less sure about how the documentation process fits in.
With more traditional models, writers are often blessed with spec sheets and design documents early on. Even better, these documents usually remain accurate through the life of the project, since the requirements and scope are fixed. In Agile development environments, the process is more fluid. This is good for software because projects don’t march unwaveringly in the wrong direction, but it can be hard for a writer to keep up with the changes. Often the solution is for writers to attend every software team meeting (and there are lots), listen for interesting things, ask questions, and start writing when it looks like things are finally getting nailed down. It can be practically time-consuming to attend these meetings and mentally discomfiting to feel like the plan is always subject to change.
I’m lucky to have recently joined a large company that’s given a lot of thought to the writer’s role in Agile development. I’m also glad I found “A Writer’s Guide to Surviving Agile Software Development.” As I’ve struggled to adopt Agile, I return to this guide time and again to find useful bits of wisdom.
As someone who’s only been doing this for a few months, here’s some of the day-to-day advice for survival that has brought me (relative) sanity so far:
Skip meetings that don’t add value to the documentation. For example, it might not be necessary for writers to attend code review meetings between developers and quality engineers.
Ask your team to clarify anything that is unclear to you at the daily scrum meetings. That’s what these meetings are for.
Learn to feel comfortable writing documentation for products you can’t test yet. You’re more likely to meet deadlines by writing fiction than by waiting to write nonfiction for a finished product.
Learn to revise any fiction before it ships to customers. Insert revision reminders in documents and add revision reminders to your calendar.
Learn what to ignore
Take what you can from Agile and ignore the rest. Agile focuses on software development, not writing. For example, attending daily scrums only twice a week may be enough. Agile means self-organizing; it’s okay if different teams work in slightly different ways.
I’m still figuring out my processes and how I can be the most successful, so this last point offers some relief: it’s a methodology, yes, but it’s all about being flexible, adjusting as you go and, ultimately, creating the best product for your customers.
Due to web issues, we lost information on who authored this piece. If this is your work, please let us know and we will give you publishing credit.