TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: I'm now blogging about Agile & TW From:quills -at- airmail -dot- net To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Thu, 03 Dec 2009 09:35:59 -0600
Again, this depends upon those in charge understanding and including
everone in the 15-minute daily meetings. It's hard to participate when
you aren't told where and when those meetings occur. Or if they don't
actually occur except on an ad hoc, whimisical basis.
If I sound skeptical, it's because of bad experiences.
Scott
On 12/3/09 7:48 AM, Chris Despopoulos wrote:
> RE the following statement:
>
> There are also bad ways to integrate documentation into the process,
> so that writers waste a lot of time in irrelevant meetings and dealing
> with impossible deadlines.
>
> In Agile you are a professional, and a relatively free agent. If you waste time in irrelevant meetings, then you're not doing your job critically. The only required meeting is the daily stand-up where you meet for 15 minutes *only* and if you're not a pig you keep your mouth shut. Other meetings may be spawned out of this, and you might be invited to some. It's up to you to decide whether to invite yourself when invitations are not extended, and turn down invitations that are irrelevant. YOU are the documentation professional on the team. How documentation gets integrated is largely up to you.
>
> That said, the impossible deadlines are a real issue, for three reasons. First, management has trouble assigning a writer to only one SCRUM team. SCRUM openly states that 100% participation on a team is paramount, but Doc and QA rarely get that luxury. I have LOTS to say about that! The second problem is maintenance... As the product grows, your previous work often changes, and at the same time you have new stuff to write. There can be a tipping point where the volume of changes outstrips the new stuff. You have to anticipate maintenance, and include it in the estimates. Finally, the code doesn't usually freeze until the last week of the sprint, or later. I'm sure you can see the problem... There are creative ways around this, and I have experienced overall success.
>
> I would say the biggest problem is doc management, where undervaluing the writer's contribution leads to later integration, and assignment to many different teams. As usual, it's a matter of education.
>
> cud
>
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Are you looking for one documentation tool that does it all? Author,
build, test, and publish your Help files with just one easy-to-use tool.
Try the latest Doc-To-Help 2009 v3 risk-free for 30-days at: http://www.doctohelp.com/
Help & Manual 5: The all-in-one help authoring tool. True single- sourcing --
generate 8 different formats and as many different versions as you need
from just one project. Fast and intuitive. http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
