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, 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!
I am constantly updating Rally. We not only have our scrum team meetings, we
have Scrum of Scrums every day. Sprint reviews, retros, and planning take an
entire day.
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-
