RE: Making Agile work with remote resources

Subject: RE: Making Agile work with remote resources
From: Kat Kuvinka <katkuvinka -at- hotmail -dot- com>
To: <alison -dot- wyld -at- wyld-home -dot- net>, <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Mon, 11 Jun 2012 12:23:33 -0400


By all means, get the writer to dial in so she can get info first-hand and ask questions. If the sprint planning and execution goes well, I think you will both see that it is possible to
develop documentation for the work being done in that 3 weeks. It does not have to look like a complete manual. During a sprint I used to create "snippets" to cover the feature, and add a few lines to document what I though would come before and after this info in a user guide.

This will be challenging and luckily as you said the writer is up for it. She will hopefully come up with solutions of her own to the unique situation--this is part of the "fun" of agile. It is unfortunate that only half of her time will be devoted to this, so intially you might want to see if the doc can lag behind development for one sprint. That seems to work well for some teams.

Good luck and let us know what happns!

Kathee

>
> 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 archive -at- web -dot- techwr-l -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


Follow-Ups:

References:
Making Agile work with remote resources: From: Alison Wyld

Previous by Author: Re: Dilbert Today
Next by Author: RE: Making Agile work with remote resources
Previous by Thread: Re: Making Agile work with remote resources
Next by Thread: RE: Making Agile work with remote resources


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads