Content Writing in an Agile Development Environment
Yes, you can be a content writer in an Agile development environment! In fact, the benefits far outweigh the initial transition pains.
Anyone who's been in the software industry for more than five years can attest that development processes come and go. I think the Agile, Scrum process can be the most beneficial to all teams. Over the years, I’ve created content for software through a variety of request tools or processes: waterfall, cascade, specification sheets, service requests, and my favorite documentation-by-discovery. (This is the “oh, look they’ve added something new” process.)
Content writers have a larger responsibility than just putting words to paper. The nature of our work allows us to be the first user to come in contact with an interface. We are the voice of consistency across an application. We keep non-words from being published on screen – most of the time. We are the first testers and can discover when something is not happening logically. On a Scrum team, involving us in design meetings saves programming and QA rework later.
This is not to say that we do not need to ‘catch up’ occasionally because the number of features being programmed is large. However, being involved up front gives us an edge when the work is ready. There is no blind-siding and because we have been in on the ground level, we might even get a jump on the overview content.
I have read many forum discussions saying that Agile just doesn’t work for writers. We still end up at the end. I disagree. There are certainly growing pains. You must have buy-in from all team members that you are all working together toward the same goal: to create the best end-product for your users. You have to realize your worth and ensure that the rest of team understands the value you bring to the process. You must enlist the support of your Scrum master and not be willing to let poor process slide by other team members. Our end content is what support and customers use first to understand new features (or old features for that matter), it’s vital to get the information you need to make that content complete. You have tools, such as Version1, at your disposal. Let those types of tools work for you. If you’re truly stuck on a new feature and you’re waiting for lynch pin type information, move your task to Impeded. Not to make a statement, but because you’re a part of the team, too! This means that you have to be agile, too. Product owners, programmers, and QA are all involved alongside you and there can be changes that happen after you’ve finished documenting something. Be flexible enough to know that happens and you can update content when needed. It’s all part of being on the team.
Recently, a programmer asked our Scrum master if she should finish the documentation notification form (something we implemented recently) before she moved on to the show-stopper issue that arose that morning. The Scrum master immediately replied, “Get Dawn what she needs first.” (Yes, secretly, I nearly did a jig.) The reality is that the team recognized getting me the information was important and needed to be done before moving on.
I do not want to imply that my job is any more important than anyone else’s. We are equal. We’re a team. My job is as important as another’s. You can write content in an Agile environment…and you can contribute in many, important ways. Take ownership of that value and make it work for the good of the entire product.
Posted by Dawn Miller, Sr. Content Writer, Epicor