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.
Subject:Re: Getting that info From:Charlotte Branth Claussen <charlotteclaussen -at- gmail -dot- com> To:William Sherman <bsherman77 -at- embarqmail -dot- com> Date:Tue, 5 Mar 2013 10:28:12 +0100
William, I know, and I did not take it like that. I agree completely that
an interest in exploring the software yourself is part of making a good
techwriter. Also, like Anne says, it gives a lot more respect among the
developers that you actually put an effort into learning.
Regarding scrum, I believe there is many ways of doing it, none exactly
like it is described in whatever you read. Hopefully, any workplace will
implement scrum in the form and degree that suits the workplace and the
tasks at hand.
To me it sounds strange that scrum is a job requirement, unless they are
looking for a scrummaster or lead developer. But it can be important in the
sense that you would only fit in, if you work well in an environment with
daily standup meetings, collaboration with a team, and planning in so
called sprints. What I particulaly like about scrum is that everything is
visible, both to your team and to your manager.
/Charlotte
2013/3/4 William Sherman <bsherman77 -at- embarqmail -dot- com>
> I understand that completely, and didn't mean to make it sound like
> anything less than doing it all yourself was less than acceptable. I've
> been places that you simply didn't have access to the equipment or
> applications. While I talked about logging time on a simulator, I worked
> one job we had full visual access to a simulator, and zero access to it
> running. Now how can you document anything as to how it works when all you
> can do is look at it sitting? You can't touch it, turn it on, run it, see
> it run, or anything. Yet you have to document all of that.
>
> You do just like you do, trust the part of the team that does have access
> to get what you need.
>
> Your mention of scrum team is interesting as lately, I have had a few job
> calls that used "scrum team" as a job requirement, not as a nice way to get
> a team to run. As such, I looked up scrum teams to find what I could, and
> came to the conclusion that while I have never been officially in one or
> worked where they were used, I have been on several projects that ran that
> way. It is too bad that the communications within a team has dropped such
> that they now have to have a process such as scrum to get people to work
> how they should, and used to, work.
>
> Worse is that job recruiters are using it as a job requirement, since they
> obviously do not know what it is.
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EPUB Webinar: Join STC Vice President Nicky Bleiel as she discusses tips for creating EPUB, the file format used for e-readers, tablets, smartphones, and more.
