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:Julie Stickler <jstickler -at- gmail -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Fri, 8 Jun 2012 10:34:59 -0400
In my experience doing Agile at four different jobs, the ones where it
was least successful were the jobs where the team was not co-located.
Agile is all about teamwork, and it is hard enough to build a good
Agile team when you're all in the same building. Having people in
different time zones adds a whole 'nother level of difficulty to the
task.
And Agile is already difficult for writers, since the model is NOT
designed with technical writers in mind. Since all of the Agile
evangelists, training, coaches, and blogs seem to either forget about
technical writers, or only mention them as an afterthought, it's all
to easy for a development team to neglect to fully integrate the
writers into the Agile team.
I'm currently struggling with a *ahem* less than optimal Agile
implementation, where our IT department has locked the writers out of
the engineering domain on the network, the ScrumMasters often forget
to invite us to meetings, and developers release code without
mentioning to the doc and training department that oh, by the way,
this is going live.
Which is not to say that Agile cannot be done well. At my last job it
was done extremely well, and I was a full member of the team, even
though I was a part-time contractor. I think it has a lot to do with
management and team buy-in to the idea of adopting Agile. If everyone
knows what the goals are, and works towards them as a team, then
things tend to go well. If it's unclear why the team is going Agile
(for example, if a manager decides it's the hot new thing so we should
be doing it) then it's harder to get everyone on board.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
