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:"Pro TechWriter" <pro -dot- techwriter -at- gmail -dot- com> To:"Leonard C. Porrello" <Leonard -dot- Porrello -at- soleratec -dot- com> Date:Thu, 4 Sep 2008 11:25:04 -0500
I am following this thread with interest, as I am on an Agile team that is
distributed across several locations--and time zones. We have just started
daily scrums after several months without regular communication.
After reading Leonard's response, I am concerned. I am not an auditory
learner, so I have to write detailed notes at review time, which adds to the
level of difficulty.
On Thu, Sep 4, 2008 at 9:56 AM, Leonard C. Porrello <
Leonard -dot- Porrello -at- soleratec -dot- com> wrote:
> Sounds like a difficult situation, but you might be able to make it
> 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.
> -----Original Message-----
> From: techwr-l-bounces+leonard -dot- porrello=soleratec -dot- com -at- lists -dot- techwr-l -dot- com
> =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
> 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
> 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.
> 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 pro -dot- techwriter -at- gmail -dot- com -dot-
> To unsubscribe send a blank email to
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit
> 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.
"You can only become truly accomplished at something you love. Don't make
money your goal. Instead, pursue the things you love doing, and then do them
so well that people can't take their eyes off you."
- Dr. Maya Angelou
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-