Re: Scrum sucks!

Subject: Re: Scrum sucks!
From: quills -at- airmail -dot- net
To: Chris Despopoulos <despopoulos_chriss -at- yahoo -dot- com>
Date: Sat, 18 Sep 2010 23:11:21 -0500

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.


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.

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:

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Please move off-topic discussions to the Chat list, at:


RE: Scrum sucks!: From: Chris Despopoulos

Previous by Author: Re: Scrum sucks!
Next by Author: Re: What sort of experience would be better?
Previous by Thread: RE: Scrum sucks!
Next by Thread: Re: Scrum sucks!

What this post helpful? Share it with friends and colleagues:

Sponsored Ads