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.
@ 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
On Thu, Oct 10, 2013 at 3:31 PM, Editor in Chief <
editorialstandards -at- gmail -dot- com> wrote:
> Go grab a coffee - I'm going long.... :-)
>
>
>
> 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.
>
> Learn more: http://bit.ly/ZeOZeQ
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as kathleen -dot- eamd -at- gmail -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
>http://www.techwhirl.com/email-discussion-groups/ for more resources and
> info.
>
> Looking for articles on Technical Communications? Head over to our online
> magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions? Search our public
> email archives @ http://techwr-l.com/archives
>
--
Kathleen MacDowell
kathleen -dot- eamd -at- gmail -dot- com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
