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.
Where I'm currently employed, I am forced to inquire of the project
managers, "Just how bad do you want the documentation?" And I'm not
inquiring about the urgency that they need it.
When you are given 4 weeks to write, edit and develop a 300 page
document, you aren't really going to produce something that others would
call a quality document.
Scott
Chris Despopoulos wrote:
> Well, by definition, you aren't being allowed to do real SCRUM. You should be
> 100% on a single project. How many engineers are on 5 - 10 different sprints at
> the same time? This is a management problem I've posted about quite a bit. The
> mgmt theory is that tech writers aren't *real* contributors, so they can't be
> assigned 100% to any project. This POV stems from the fallacy that tech writers
> produce pages and nothing else. I know for a fact, because I've been there,
> that a writer *can* participate 100% from the start of a project, and always be
> busy. You just have to take on tasks that don't always say "Tech Writer" next
> to them. Remember this... Product development is, always has been, and always
> will be, an exercise in information management. YOU are an information
> professional. SCRUM is trying to break down artificial boundaries and job
> titles in the name of getting the job done.
>
>
> Now, back to the real world... Management will not in the near future ever hire
> one tech writer for every project if they indeed have multiple projects. That's
> just a fact. But there *is* a limit. If each standup meeting is 15 minutes,
> and you are a member of 12 projects, that's three hours a day in standup
> meetings! Then don't forget the cost of context switching. I actually did some
> research on this (unfortunately, paid for by an ex-employer so I can't use it
> for my own ends). Each SCRUM team tends to have its own culture... differences
> in how to manage the standups, how to divide tasks and stories, how each member
> identifies an issue, etc. That's a costly switch of context right there. Then
> there's the technical switch -- even if everybody is using the same framework,
> the details of what each team is accomplishing can outstrip your ability to keep
> up.
>
>
> Then there's the cost of doc maintenance. At some point, the cost of making
> changes to outdated content will outstrip your ability to create new content.
> I'm surprised nobody has brought that one up.
>
> So Management has to be made aware of these issues, and viscerally. That is to
> say, until management feels the pain, they will assume everything is OK with one
> writer supporting 30 developers, and spending 2 - 3 hours a day in STATUS
> meetings, let alone design meetings, release meetings, etc. And then don't
> forget that the Doc department will want meetings to keep everybody within the
> same standards.
>
>
> You have to quantify all that and get it into the planning software. Then, when
> the numbers say you're committed to 600 hours for a 30-day sprint (20 hours a
> day if you work weekends), go ask for a raise. More seriously, it's likely that
> the software won't allow one contributor to have that many hours in the sprint.
> But the point is, really estimate your time. Don't make estimates that fit,
> make estimates that really reflect the tasks. When you go to team A, let's say
> your estimates amount to 20 hours a week. Well, add in another task for 20
> hours a week in team B, another for 20 hours a week in team C... You get the
> idea. One way or another, you have to express your hard limit of availability
> to team A.
>
>
> If you're really talking about 7 teams, then you have less than 6 hours a week
> to devote to each team. And that doesn't account for going to the bathroom,
> upgrading your version of SnagIt, or trying out the new delivery model for your
> online docs. My biggest SCRUM project (yes, I had up to 5 teams at once from
> time to time) assumed 5 hours a day, giving each person 3 hours to do the kinds
> of things we all do to stay current in our profession, and current with the
> company culture. I think that's only fair -- "We're HUMAN Spok! We don't have
> our HEARTS where our LIVERS should be!"
>
> But I still maintain -- don't blame SCRUM. There is a disconnect between SCRUM
> methodology, realistic estimates, and management expectations. Otherwise known
> as a dysfunctional relationship. Ge thee to counseling.
>
>
> cud
>
> *****************************************
> ChrisD sez "don't blame scrum," but that is a good point, the overhead is a
> killer!
>
Create and publish documentation through multiple channels with Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, free for 30-days. http://www.doctohelp.com
LavaCon 2010 in San Diego Sept 29 - Oct 2 is now open for registration.
Use referral code TECHWR-L for $50 off conference tuition!
See program at: http://lavacon.org/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
