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.
As other people lovingly point out... "it depends".
If you are running at 110%, just to keep abreast of your current workload,
Agile methodology will be either:
- your salvation
or
- your damnation.
If the PTB are just making chin music, then it'll simply mean additional
busy-work for you, and no help for your situation.
If the PTB are serious about Agile, then this is a golden opportunity for
you.
In simple terms, your life has changed.
In Agile, everything is a story, assigned to sprints, given priority,
tracked in scrums.
The flip-side of that is that anything NOT in story form does not exist.
Anything in story form that has not been prioritized and assigned to a
sprint can exist only in a backlog. It is not being pursued.
If an Agile story is only in backlog, then, though it does "exist" for
purposes of Agile, it doesn't exist for anybody but PLM. It's their job to
get it into a sprint - thereby making it real to everybody else.
The bad news is that you will have to attend all the relevant scrums,
possibly for multiple projects that are happening simultaneously. You da
writer, not some developer who has one project at a time...
The other bad news is that ANYthing you are doing right now, anything you
believe you need to work on next, or "soon", you MUST now put into your
Agile system (we use Jira) as a story. Someday, the PLM and developers
will be making DOC stories for you, but in the early days, and to migrate
from waterfall (or whatever other medodology), you are the one who will
need to put ALL your pending and near-future activity into stories, 'cuz
nobody else will. And they MUST be in stories.
I can't stress this enough. I don't care if you worked 25 hours yesterday,
and churned out a hundred pages of text and updates. You accomplished
NOTHING... I repeat... you accomplished absolutely zero useful work for the
employer, if it was not:
a. captured in the form of a story
b. accepted, prioritized and assigned by PLM or your scrum master
c. progressed through the Agile sequence, commented, etc. to
the point that it was out of your hands.
Got that? If it's not recorded and acknowledged in your Agile system, then
you didn't do it. Your employer won't care that you can wave a finished
document at them. It needs to be in the system to exist.
If you have a great relationship with your current manager, it will remain
good, but it will thin out, drastically.
The new important person in your [work] life will be your scrum master.
S/he is who you have to satisfy, and to whom you report every little glitch
and impediment. And you do that publicly, daily, in scrums.
Like gets complicated if you have more than one scrum master. But you get
to enlist them in the negotiations, so it's not all bad.
The good news is that scrums are just a few minutes per day, each.
The other good news is that a proper Agile system (again, we use Jira, you
deal with whatever formal system your company adopts) records everything
that happens to a story, and timestamps it. So, nobody can spring a
s***load of work on you at the last minute and ask why you didn't do it.
Your workload is public, as is the priority that PLM and others assigned to
it, and WHEN they assigned it, and WHEN somebody revised the priority, and
so on.
What I'm saying is that you should soon have help, because it will be
obvious (if you get everything into stories) how much of a workload there
is, and how much of it is not fitting into current sprints.
If PLM, or somebody, makes a story that says something vague and amorphous
like "update the docs", you reply by making sub-stories or tasks that list
everything you think will be involved in accomplishing that big story.
Moreover, you can keep doing that as the scope reveals itself.
Every story that you create, be sure to assign to PLM (but make yourself a
watcher, just so you don't lose sight...). It can come back to you, only
when PLM assigns priority and moves it into a sprint. If somebody assigns
a story or task to you WITHOUT it being in a current or future sprint, push
back. Stuff it into the backlog with a comment that you'll take a look at
the work involved as soon as it gets prioritized and assigned to a sprint.
You get to push back by commenting the active stories and tasks, indicating
anything that is blocking you.
Lack of info? Leave a comment that there's no current doc from
engineering, and the guy with it all in his head is on vacation.
Lack of equipment?
Lack of working prototype hardware? Software? Firmware?
Leave a comment that says you can create some draft, or placeholder
material in the docs, but will need to re-visit and re-work when the
product firms up.
Agile is a fish-bowl, and you need to embrace that and run with it.
Participation is how you protect yourself and advance your cause.
If you are in multiple sprints simultaneously, you use the comments and the
workflows to make it obvious to everybody that you are not (like most
developers) "owned" by a single scrum-master, and that your time is spread
much more thinly.
That's how the people at director level are going to see that you need
another body.
They'll see that important work is not being done because there aren't
enough writer resources to go around. But you need to make obvious that you
are producing on however many fronts exist at your employer.
When you are "done" with a story or a task under a story, it should go to
a review process, or to the same test and verification people who test code
and hardware.
Depending on the system your company uses, the Eng-Test and Verification
people might be responsible for making their own test-cases, or you might.
If it's you, you get to record the time you take to develop those
test-cases for testing your resolved doc stories and tasks.
Here, we have declared meeting-free Friday. Not even scrums can happen on
Friday. People have a whole day to do actual work, without interruption.
That's been a big help, and keeps everybody sane (not to mention,
productive). You should push for that.
A feature of many Agile systems is demos by each team or developer near the
end of each sprint. We used to do them on Fridays, but now, the last scrum
before a demo is on Thursday, the dev or the team has all of Friday to
prep, and then the demos are on Monday. That includes demo-ing new docs
or changes to docs.
On Wed, Oct 9, 2013 at 3:14 PM, Lippincott, Richard <RLippincott -at- as-e -dot- com>wrote:
> I know this is an elementary question, but up until recently I've been
> glossing over Agile topics as they haven't applied to my work situation.
> Apparently we're moving to an Agile work environment, and we're doing it
> soon.
>
> (We switched to Agile as a configuration control system about six months
> ago, at that time the standard response to my repeated question "Are we
> using the methodology?" was "No, we're just using it for configuration
> control, that's all. I learned that we're adopting the process about a half
> hour ago when I went to a meeting on a program, and noticed up on a wall
> were all sorts of yellow sticky notes arranged as "Sprint 1," "Sprint 2,"
> and so forth. "Oh yeah, we're adopting the process" said the program
> manager in the meeting.)
>
> I'm a lone writer, currently working at about 110% of capacity, managing
> the operator and field service manuals on about a dozen different complex
> products, and it's not unusual that I've got three or four different
> projects/product manuals in work at any given moment.
>
> Is my life about to get easier because of this, or is it likely I'm about
> to get overwhelmed by the pace of changes?
>
> Thanks...
>
> Rick Lippincott, Technical Writer
> American Science and Engineering, Inc. | www.as-e.com
> 829 Middlesex Turnpike | Billerica, MA 01821 USA | Fax +1-978-262-8702
> Office +1-978-262-8807 | rlippincott -at- as-e -dot- com
>
>
>
>
--
__o
_`\<,_
(*)/ (*)
Don't go away. We'll be right back.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
