RE: Agile working with offsite teams

["Sarah Blake" <Sarah -dot- Blake -at- microfocus -dot- com>]

Thanks for sharing, Leonard. I am indeed the only remote team member,
and the team's existing author will be remaining onsite for the next few
months to ensure a smooth handover, so hopefully that should at least
help alleviate any teething troubles.

Sending out 'not-quite-minutes' after scrum conference calls is a good
idea given one aspect of the situation that I failed to mention; I
believe the existing author is the only native English speaker of the
team, and I don't currently know a word of their language, so a
/written/ reference may be vital to avoid misunderstandings.

Sarah Blake
Senior Technical Author
Micro Focus

(Achieving the impossible since 1976...)

> -----Original Message-----
> From: Leonard C. Porrello [mailto:Leonard -dot- Porrello -at- SoleraTec -dot- com]
> Sent: 04 September 2008 15:57
> To: Sarah Blake; techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: RE: Agile working with offsite teams
> 
> Sounds like a difficult situation, but you might be able to make it
> work.
> 
> A company I worked for previously used Agile for a $24 million
pharmacy
> management application project, and we used teleconferencing to
> facilitate daily scrums comprising team members in several locations
> around the country. Since several team members were remote, we had a
> "scribe" (usually me) capture all of the details of the scrums. These
> were sent to scrum members daily and went into Lotus Notes for future
> reference. The practice of capturing minutes is somewhat contrary to
the
> spirit of Agile, but doing so helped ensure that everyone (including
> primarily visual learners) shared the same understanding--or that, at
> least, was the theory. We used NetMeeting when graphics or
> demonstrations were required.
> 
> I have to add that the project failed and the company is no longer in
> business. Trying to use Agile with a team was scattered to the four
> corners of the earth contributed no small part to that failure. Agile
> was a very poor methodology choice for that project.
> 
> It might not be so bad if only you (the writer) are remote and are a
> good auditory learner.
> 
> Leonard
> 
> -----Original Message-----
> From:
techwr-l-bounces+leonard -dot- porrello=soleratec -dot- com -at- lists -dot- techwr-l -dot- com
>
[mailto:techwr-l-bounces+leonard -dot- porrello=soleratec -dot- com -at- lists -dot- techwr-l -dot- c
> om] On Behalf Of Sarah Blake
> Sent: Thursday, September 04, 2008 7:09 AM
> To: techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: Agile working with offsite teams
> 
> Hi all,
> 
> 
> 
> I've recently begun a new job, at which I've been given the
> responsibility of handling the documentation for a set of products
that
> are developed by a team overseas.
> 
> 
> 
> Now, this isn't a situation that's entirely new to me - in the past
I've
> worked on a number of projects that have required international
> communication - but this has a far larger scope than what I've done
> before, and will require a more intensive level of communication (the
> overseas team are also hoping to migrate to SCRUM over the coming
> months).
> 
> 
> 
> So given that I'm essentially going to have to put a communication
> strategy in place from scratch, and given that the dev team have no
> experience in working with an overseas writer, and given that my
> knowledge of SCRUM is so far entirely theoretical, I'm hoping to be
able
> to use the experience of this list as a guide; can anyone offer any
> suggestions, warnings, or similar experiences from which I might
learn?
> 
> Sarah Blake
> Senior Technical Author
> Micro Focus
> 
> 
> 
> This message has been scanned for viruses by MailController -
> www.MailController.altohiway.com

Please consider the environment before printing this e-mail.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/ for more resources and info.