Comments on: Five Skills for Managing Documentation Projects in an Agile Environment http://www.gryphonmountain.net/2009/11/five-skills-for-managing-documentation-projects-in-an-agile-environment/ Technical Communication and Other Writing Topics, by Ben Minson Wed, 11 Jan 2012 04:05:49 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Ben http://www.gryphonmountain.net/2009/11/five-skills-for-managing-documentation-projects-in-an-agile-environment/#comment-422 Ben Mon, 23 Nov 2009 16:35:04 +0000 http://www.gryphonmountain.net/?p=785#comment-422 Thanks for the comments. @Bill: I think that communicating with the customer often and well could be skill #6, and just like with the product, you show the customer and make sure you're on the right track so that any course corrections are small. @Larry: I think the other side of what you said is that if you're writing in small pieces and then the plan changes, you may not have to throw away as much previous work. Thanks for the comments.

@Bill: I think that communicating with the customer often and well could be skill #6, and just like with the product, you show the customer and make sure you’re on the right track so that any course corrections are small.

@Larry: I think the other side of what you said is that if you’re writing in small pieces and then the plan changes, you may not have to throw away as much previous work.

]]> By: Larry Kunz http://www.gryphonmountain.net/2009/11/five-skills-for-managing-documentation-projects-in-an-agile-environment/#comment-421 Larry Kunz Fri, 20 Nov 2009 18:58:20 +0000 http://www.gryphonmountain.net/?p=785#comment-421 Good ideas, Ben. There's another reason for topic-based writing. In addition to scope creep, plan changes can mean that the team has to throw out a whole bunch of documentation they've already written. If the team has been using topic-based writing, they'll probably still be able to use some of the topics rather than having to start over from scratch. And yes, "topic-based writing" is the right term -- not necessarily "DITA." DITA is a great set of tools for doing topic-based writing. But not all topic-based (or modular, or reuseable) writing has to be DITA. Good ideas, Ben.

There’s another reason for topic-based writing. In addition to scope creep, plan changes can mean that the team has to throw out a whole bunch of documentation they’ve already written. If the team has been using topic-based writing, they’ll probably still be able to use some of the topics rather than having to start over from scratch.

And yes, “topic-based writing” is the right term — not necessarily “DITA.” DITA is a great set of tools for doing topic-based writing. But not all topic-based (or modular, or reuseable) writing has to be DITA.

]]> By: Bill Albing http://www.gryphonmountain.net/2009/11/five-skills-for-managing-documentation-projects-in-an-agile-environment/#comment-420 Bill Albing Fri, 20 Nov 2009 14:34:53 +0000 http://www.gryphonmountain.net/?p=785#comment-420 I agree - small chunks or topics is better. In fact, when in Agile-land, do as the Agile-ers do. If they are developing small chunks of functionality, then only develop the documentation needed for that. I don't think tech writers or anyone creating user documentation should work in a way that is different from the others on the project: if the team is using Agile principles, then you should too. If the team is doing traditional project management (with planning and estimating up front) then you should do that too. A big part of Agile is communication and collaboration with the customer -- develop a little and then show the customer. So with the docs, develop a little and get some feedback about what they like or don't like, and then go from there. I agree – small chunks or topics is better. In fact, when in Agile-land, do as the Agile-ers do. If they are developing small chunks of functionality, then only develop the documentation needed for that. I don’t think tech writers or anyone creating user documentation should work in a way that is different from the others on the project: if the team is using Agile principles, then you should too. If the team is doing traditional project management (with planning and estimating up front) then you should do that too. A big part of Agile is communication and collaboration with the customer — develop a little and then show the customer. So with the docs, develop a little and get some feedback about what they like or don’t like, and then go from there.

]]>