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.
Well again, maybe you aren't being allowed to do SCRUM. There's no doubt that
bad situations exist, and they really do suck. You might as well say that
communism sucks because communist regimes practice torture. Or democracy sucks
for the same reason. It isn't the ideology that sucks, it's the specific
regime.
If I had a 300 page task on my plate, SCRUM would give me the following
guidelines:
* First, just say no. Don't accept it because it can't be done, if that's how
you feel about it.
* If you accept it, provide a realistic estimate. Industry averages are around
4 pages an hour.
That would be 75 hours. Or let's say 100 pages a week at 25 hours each
week. Maybe that's
not unrealistic after all? If you're 100% on that project, and the team has
something solid
for you to work against, maybe you can do it. If you have two 300-page
tasks, then something
has to give... State your available hours up front. And I would suggest
you don't fall into the trap
of estimating 8 hours a day -- nobody really works 8 hours a day on the
specific task. We're not
machines -- if machines could do the work, we'd be unemployed already.
* Establish what to consider DONE for that task. Is BETA alright? Or must it
be GA? Work that out, and
set up the tasks that correspond to your milestones. And again, provide
realistic estimates.
* Along with your estimate, you have to identify dependencies and possible
blockers. Be up front
with this in the planning meeting. "I need specs for these features, or
working product." or "I can't
document this product until you give me a lab machine with X, Y, and Z on
it." Whatever you need,
get it on the table at the planing meeting. It's not unusual for that to
become a task for somebody else...
For example, if you need a review by the end of week 3, say so. And don't
rest until the review is made
into specific tasks for specific people with specific (and realistic) time
estimates attached. Maybe your
dependencies will result in dropping a story from the sprint... So be it.
It's all about setting realistic
expectations.
* In the standup meetings, if you have a blocker, say so. And
state the actual risk -- "I need to document FOO, but the FOO design is
still changing significantly.
I can't document anything else because all my remaining features rely on
FOO. Each day that I
have to wait adds 8 hours to my estimate." That's what the standups are
for.
cud
________________________________
From: "quills -at- airmail -dot- net" <quills -at- airmail -dot- net>
To: Chris Despopoulos <despopoulos_chriss -at- yahoo -dot- com>
Cc: techwr-l -at- lists -dot- techwr-l -dot- com
Sent: Sun, September 19, 2010 12:11:21 AM
Subject: Re: Scrum sucks!
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-
