Why Agile might be good for technical writers after all

Many tech writers find the whole idea of working in an Agile programming environment a bit scary. There are no specs, for heaven’s sake! However, there are surely some advantages to being a tech writer on an Agile team, if the whole team has really embraced the philosophy (and not just the terminology) of the Agile approach.

Two key points in ensuring a successful scrum from the tech writers point of view are having a set of agreed deliverables, and breaking assignments down into small tasks that can be estimated and tracked. At the end of each sprint, the developers are supposed to have “shippable code”. You need to agree in advance what constitutes the equivalent of “shippable code” for you. Is it a fully functioning help system, or is it just half a dozen new topics relating to what has just been developed? Are you responsible only for user-facing documentation, or are you expected to contribute elsewhere (such as system documentation, or internal, procedural documentation) as well? (Even though the Agile Manifesto famously prefers “working software over comprehensive documentation” many companies still expect to see both!)

With respect to technical writing tasks, there is no easy formula for estimating the time for each one. Even if you say something like “8 hours per help topic” you may not know how many topics are involved until a good way into the sprint. You need to learn from your own experience, and keep notes that you can learn from. The most important evidence for estimating for the next sprint is knowing that the last time you were faced with a similar task you estimated it would take you one day but in fact it took two days because of this or that factor.

Despite these superficial difficulties, being part of an Agile team has the advantage of making you and your work far more visible, which is good, but along with greater visibility comes greater responsibility, and to be taken seriously you have to approach your work seriously too.

Instead of sidelining the work of technical writers an Agile approach to product development places technical writers firmly as equal team members. This is good news. Taking part in daily scrum meetings, and in sprint planning and review meetings, (and all the other meetings) means you get to hear first-hand about the new features or the fixes that the developers are working on. (Never forget that you aren’t writing for the developers on your team, because you always need to write for your readers.) But learning about the product features is only half the story.

Everyone has a turn to speak at the daily scrum. That means that for about 90 seconds every day everyone in the team is listening to you – and for many tech writers that is much, much more time being listened to than they are used to. Use that time to tell people what you are working on, what you plan to do before the next meeting, and, most importantly, tell people about any “impediments” (anything stopping you doing your work). You see, in Agile, any problems that a team member has are the team’s problems.

The job of the Scrum Master in an Agile team is to help get rid of any impediments that are interfering with the work of anyone in the team. If you can’t get your work done because developers won’t find time to speak to you, then their behavior is becoming an impediment to your tasks, and you need to ask the Scrum Master to help you sort things out. In many cases the Scrum Master used to be the development manager or the development team lead, and anecdotal evidence suggests that some managers may find it a challenge to adjust to their new role of facilitating rather than directing.

I’d be interested in hearing what other people’s experience of working with Agile development teams has been.