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: Making Agile work with remote resources From:Sally Derrick <sjd1201 -at- gmail -dot- com> To:Alison Wyld <alison -dot- wyld -at- wyld-home -dot- net> Date:Tue, 12 Jun 2012 08:33:55 -0500
In my experience, working remotely is generally hard for a tech
writer regardless of the development methodology. It's always hard to hear
on the phone. There are always key discussions at the coffee pot that
don't get relayed in emails. Whether or not the team keeps the
writer involved and informed depends on the manager (and how persistent the
writer is), but in my experience it's a little harder to ignore the writer
in agile.
I just finished working with one of the best agile teams. Granted I was
local but, damn, I miss them now. I was a full member of the team with
input to design discussion, heavy input on the UI, training internal users,
helping to troubleshoot issues. All of it. Now, I'm lucky if the new
manager remembers to ask for my status in the now marathon team status
meeting.
Alyison, I would not suggest a separate doc-related user story unless the
story is strictly a documentation effort (create an index, evaluate a new
HAT, work with printer on production sched, etc). If the dev team has a
story to create a new feature, the documentation for that feature should be
a task of the dev user story. The story is not complete until all tasks
are done. This helps keep you involved. As the team reviews progress of
the stories, every day they see that doc task and any progress updates
you've posted. If they have a side meeting about how to do something, they
are more likely to grab/call the people listed on the story.
The writer should definitely be attending the daily standup/scrum.
There is an Agile Writers group on LinkedIn that might offer more advice.
Sally
On Fri, Jun 8, 2012 at 6:00 AM, Alison Wyld <alison -dot- wyld -at- wyld-home -dot- net>wrote:
> I've done some archive searching and googling, but haven't found anything
> that addresses this precise situation.
>
> I work (slightly less that half time) as the onsite interface person for an
> off-site, off-shore writing team. (Located in the same time-zone as our
> client). The team has access to the client's corporate network, so can
> connect to in-house tools, use email, and also the in-house "chat" tool.
> Developer teams tend to be multi-site and multi timezone, and much work is
> done on the phone and via video conf. The reason for offshoring was of
> course financial. Most projects are run in a fairly traditional way and
> after a few years of experience, we've got things more or less working
> smoothly... with heavy reliance on specification documents and so on, plus
> over the phone briefings.
>
> One of the teams we work with is made up of people who are all located on
> my local site. They have decided to move to an Agile model, and want me to
> tell them how we can make this work with a remote writing team. All the
> reading I've been doing talks about co-locating the writer, integrating
> them completely into the team etc. But this isn't an option for us. Does
> anyone have any experience with this sort of scenario ? I'm local, but only
> assigned to work <half time for this client, which works out at about 4
> hours per week for this particular project . I guess I could spend my 4
> hours attending their meetings and then summarizing to the remote writer -
> but I'm thinking that isn't going to be very efficient. So maybe getting
> the writer to dial in would be better ?
>
> They are talking about having sprints that are 3 weeks long. in an ideal
> world I guess that every appropriate User Story would have a corresponding
> Doc-related User story - but 3 weeks doesn't feel like much elapsed time to
> develop anything.
>
> Oh yes, budgets mean that the writer assigned to this team is unlikely to
> be able to work on it more than half time - she will also be responsible
> for another major project, in a more traditional model, at the same time.
> Which means we can't use up too great a percentage of her time with
> meetings.
>
> Options that are not open to me: move resource on site, get more budget for
> more resource, change the model from Agile back to Waterfall.
>
> On the plus side, the writer is bright and up for a challenge. We are also
> already in DITA, and I'm figuring that modularity is going to be the key to
> this. Our network access might also be a plus.
>
> Any experience out there on how to make the remote-working nature of a
> situation like this work ? Right now I feel a bit like I'm being told to
> draw a triangle but make sure it has 5 sides.
>
> I will of course summarize back.
>
> Many thanks
>
> Alison Wyld
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Create and publish documentation through multiple channels with
> Doc-To-Help. Choose your authoring formats and get any output you may need.
>
> Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
>
>http://bit.ly/doc-to-help
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as sjd1201 -at- gmail -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwhirl.com/email-discussion-groups/ for more resources and
> info.
>
> Looking for articles on Technical Communications? Head over to our online
> magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions? Search our public
> email archives @ http://techwr-l.com/archives
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.
Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
