Ask a technical communicator who has worked in software about Agile development and you’re likely to get one of two responses: “Hate it” or “Love it.” Any in-between reaction seems to be one of extreme wariness. I suspect that for some, the wariness is due to past experience with other development methodologies and the reality of day-to-day activities. Dev teams in environments where more traditional methodologies (e.g. “waterfall”) hold sway don’t always view the documentation and communication functions as critical success factors (I think that’s diplomatic enough). Based on recent discussion on the TechWhirl email discussion list, and two of our recently published articles, many tech writers face similar challenges in the brave new world of Agile. So we thought it was time to put some numbers around it, and thus we have today’s poll question: what are the technical communicator’s biggest pain points in working in an Agile environment?
Fiona Hanington related her personal experience on “Can I Be an Agile Technical Communicator When My Team Is Not?“, and Alyssa Fox recently published the first in her series on Agile and Tech Comm, “Writer Challenges in Agile and Traditional Development Teams.” Both of these informative pieces provided tips and advice to technical communicators who see the potential in Agile, but are stymied by the reality of how to get there. The current thread on the discussion list gives us a dose of reality in how folks are attempting to work in Agile, sometimes succeeding, and just as often not.
Much of our struggle to adapt to Agile paralells our challenges in being valued contributors in any product development environment It is a part of the classic change management challenge, and often part of adjusting to a customer-focused business approach. Sometimes the communicator on the team reflects the stereotype that developers seem to hang onto: the writer waiting to be spoonfed information that gets turned into documents that no one has time to review and no customer ever reads. And in some cases, what management allows to happen in the name of Agile, has no bearing on what the methodology is or what it can accomplish.
If any of this is sounding familiar, we definitely want to hear from you. According to the Agile manifesto, Agile teams value working software, communication, collaboration, and responsiveness over specs, project plans and client contracts. Is that how it happens in your world? Do you have to fight to get invited to meetings, or is your input as valued as the other members of your team? Does the writing happen during sprints, or are you still playing catch up right before release? Please vote in the poll, and then take a few minutes to give us insight on your real-life experiences, good or bad, with being the technical communicator in an Agile environment.
Loading ...
