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.
All good points, E-I-C, I didn't mean to imply that it isn't important to
document exactly what happens. That just happened to be a funky situation,
and I'm glad that I left when I did. In hindsight, I learned some things,
so that's positive :-)
"
Anyway, that sounds good, but the reality is "...ass.... alligators...
swamp..." :-) "
Indeed
On Thu, Oct 10, 2013 at 4:33 PM, Editor in Chief <
editorialstandards -at- gmail -dot- com> wrote:
> Getting on to a year and a half of agile, here.
>
> 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.
>
>
--
Kathleen MacDowell
kathleen -dot- eamd -at- gmail -dot- com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
