Re: Agile Environment Opinions Wanted

Subject: Re: Agile Environment Opinions Wanted
From: Kathleen MacDowell <kathleen -dot- eamd -at- gmail -dot- com>
To: Editor in Chief <editorialstandards -at- gmail -dot- com>
Date: Thu, 10 Oct 2013 17:06:13 -0500

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..." :-) "


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.

Learn more:


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @

Agile Environment Opinions Wanted: From: Lippincott, Richard
Re: Agile Environment Opinions Wanted: From: Editor in Chief
Re: Agile Environment Opinions Wanted: From: Kathleen MacDowell
Re: Agile Environment Opinions Wanted: From: Editor in Chief

Previous by Author: Re: Agile Environment Opinions Wanted
Next by Author: Re: Agile Environment Opinions Wanted
Previous by Thread: Re: Agile Environment Opinions Wanted
Next by Thread: Re: Agile Environment Opinions Wanted

What this post helpful? Share it with friends and colleagues:

Sponsored Ads