I’m currently working on a draft for a proposed new standard on developing user documentation in an agile environment. There is a lot of information out there about agile software development, but most of it is focused towards code developers, and possibly project managers. What I have noticed is there is very little advice out there for information developers, technical authors, and information architects like myself. I have also spent the last 18 months or so going through the somewhat painful experience of changing from a waterfall style development methodology to a more agile approach.
One of the things that really worried me about agile development when I was first introduced to it, in a two day education course, was the statement that ‘we prefer working software over comprehensive documentation’ from the agile manifesto. Now I know that what they mean is they prefer to make the software work rather than write detailed specifications about how it will work. The trouble is ‘user-documentation’ is often seen as secondary to the software product, and I was nervous that documentation in this case would be read as including user-documentation. I think it is a valid concern, and the lack of the role ‘technical writer’ or ‘information developer’ out there in the world of agile articles also worries me.
After some initial scepticism, I can see the value of it. And I also have a much better idea of how it can work, and also how it can fail to work. Because the emphasis in agile is on reducing life cycle documentation, then there is a risk that if the user-documentation development team are not a part of the agile process, either because they are not included, or because they are trying to hang on to the ‘old way’ of doing things, then they are going to lose out. Partly because they will struggle much harder to know what they should be writing, and partly because they will miss out on a new opportunity to actually work much closely with their team and gain the chance to either learn from or represent the users, and actually influence their product for the better.