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: Agile working with offsite teams From:Peter Neilson <neilson -at- windstream -dot- net> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Thu, 04 Sep 2008 19:46:53 -0400
quills -at- airmail -dot- net wrote:
> Agile with off-site teams speaking different languages is an oxymoron
> in concepts.
>
> Agile REQUIRES good communication and unity to function successfully.
> Of course it also requires an understanding of the process by ALL
> parties.
This is correct. If the tech writer is in any way outside the loop, the
documentation (and the writer) will suffer. Being outside the loop can
be accomplished in several different ways, not all of which are obvious.
Pardon my cynicism, but here are a few I've observed:
1. The phone calls between developers do not include the tech writer.
2. The tech writer hears the phone calls, but cannot figure out the
design aspects (to be documented) from what is being said.
3. The writer hears, and even gets to participate in SCRUMS, phone calls
and meetings, but the "overseas" version of English is frustratingly
hard to follow. The writer feels that all team members are faking being
able to understand each other. (This is essentially quill's main point.)
4. The tech writer requests a precis of the agreed-upon design, so he'll
have something to start from. No one answers, or perhaps he's told,
"That'll arrive later. Don't worry about it."
5. The writer actually has a box that'll actually run the daily build,
but it's not quite up to snuff (because writers clearly don't need the
souped-up hardware that developers do), and it takes three hours to get
anything to happen, while developers are talking on the phone to each
other about things that happen in seconds or minutes. The developers are
already discussing the next topic while the writer is watching an
hourglass or a little circle of spinning dots.
6. The developers and the writer attend the on-site meeting, and
everyone watches the slides and the performance of the software on his
laptop. The writer has not been issued a laptop, and is not permitted to
bring one from outside.
7. The writer follows the bugzilla link for the project, and finds that
everything is strangely out of date. The items that were mentioned in
today's SCRUM do not show up. Eventually it turns out that the writer is
not on the actual project list, because the offsite IT department got
the wrong info, and the tech writer is grouped as part of marketing.
8. The writer cannot view the true code because only team members can
see it and (like in number 7) the writer isn't quite on the team, but
does not know that, because something that looks like the code does show
up in his view.
9. The writer actually is able to write, and goes to check his work into
the repository, but (for reasons like items 7 and 8) it seems to go
elsewhere or nowhere.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ComponentOne Doc-To-Help gives you everything you need to author and
publish quality Help, Web, and print content. Perfect for technical
authors, developers, and policy writers. Download a FREE trial. http://www.componentone.com/DocToHelp/
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
