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.
I think that even in an unfair system like you describe, it's possible to
stand up for yourself. Your recorded-in-the-story/task comments when you
hand off can reflect that the docs you have produced (a section in a
chapter, a piece of Help... whatever) are as "ready-for-test" as is the
work of that developer.
You can comment that the version that you were given (of what the developer
made) was incomplete, or non-functional, etc. In fact, that's how I'd say
it even if I received nothing. Non-delivery is pretty low-functioning...
:-)
Similarly, you can comment that the work you did early in the sprint was
obviated when the developer delivered a module at the last minute that
didn't match what had been discussed/agreed back when you were writing. In
fact, if it's not too big for the system, you could paste in the before and
after versions as part of comments, to illustrate just how useless the
early info was, and how much of your time was wasted on it.
People here are a pretty good bunch, so deliberate shafting is almost
non-existent, but oversight happens. My favorite tactic when the relevant
e-mail thread finally lands in my inbox is to highlight how late in the
thread I was finally added to it. That usually quells any complaints that I
should have had plenty of time. "Oh.... you didn't even hear about this
until yesterday at 3pm... uh.... sorry."
Being in all the scrums usually prevents that kind of thing, as they see
your face, or hear you on GoToMeeting, and you hear them and can ask to be
included on new discussions that spring up. "Is there an e-mail thread on
this? Can you CC: me, please? Thanks."
If you hand off to a testing group, you can enlist their help. They will
certainly push back if the product is not in fit state to be tested against
your doc.
If they aren't being helpful, they'll still have to reject your story or
task, giving reasons - where it failed to match the product version that
they are testing, etc. - so you just accept that as your company would
accept "Deficiencies" from an auditor. You have some defined time period in
which to address the noted deficiency and resubmit.
You could also present a draft with "TBD" in a few places.
Anyway, that sounds good, but the reality is "...ass.... alligators...
swamp..." :-)
All part of the joy of working for a living.
On Thu, Oct 10, 2013 at 4:47 PM, Kathleen MacDowell <kathleen -dot- eamd -at- gmail -dot- com
> wrote:
> @ Editor in Chief: it sounds like your implementation is fairly
> long-standing and that the mgmt was flexible enough to adapt to team needs
> (e.g., Fri work). Some aspects you mentioned are interesting to know about,
> such as making backlogged items into stories; I left the company before
> they got to that point, if they ever would have.
>
> Other aspects you mentioned are going to vary by the team and company,
> such as:
>
> --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.
>
> In my teams, there was no excuse, except for the developer, who could
> completely miss sprint ending w/out a word said.
>
> ---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.
>
> Agreed
>
> Kathleen
>
>
>
--
__o
_`\<,_
(*)/ (*)
Don't go away. We'll be right back.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
