Re: SD Times: Tech Writers Should Be Pigs, Not Chickens

Subject: Re: SD Times: Tech Writers Should Be Pigs, Not Chickens
From: jackdeland -at- comcast -dot- net
To: Kevin McLauchlan <Kevin -dot- McLauchlan -at- safenet-inc -dot- com>
Date: Mon, 16 Sep 2013 14:14:37 +0000 (UTC)

I've found it much easier to keep pace with development in an Agile environment. Yes, there are changes at the end, but it doesn't ALL come crashing down at the end as in waterfall (at least for me), and I already have existing material to modify. I've found that Agile very much helps people communicate more and work better together. Perfect it ain't, but I wouldn't want to go back.

I am all in favor of making a big organizational change (i.e., top down). The scenario you describe sounds like higher management has nothing invested in making the change. That's where Agile and OD consultants come in. The good ones help the change happen and help implement means to keep people "on the path." If the change isn't embraced at the top, you get the same old same-old.

----- Original Message -----

From: "Kevin McLauchlan" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com>
To: "Jack DeLand" <jackdeland -at- comcast -dot- net>, "David Farbey" <dfarbey -at- yahoo -dot- co -dot- uk>, "Robert Lauriston" <robert -at- lauriston -dot- com>
Cc: "Chris Despopoulos" <despopoulos_chriss -at- yahoo -dot- com>, techwr-l -at- lists -dot- techwr-l -dot- com
Sent: Monday, September 16, 2013 9:50:50 AM
Subject: RE: SD Times: Tech Writers Should Be Pigs, Not Chickens


The triangle is immutable: Speed, quality, cost --- pick any two.

Higher management pushes to get the projects to come in once per quarter.
Engineering begins pushing back by taking out features. It's often not the development but the testing that's the bottleneck.
PLM dances as fast as they can, tweaking feature demands against timing demands, while trying to keep costs reasonable.

What ends up happening is that a five-feature project turns into a three feature project in the last couple of sprints, as it becomes obvious that some of the features are not ready for prime time, and there just isn't enough time to get the fixes into the candidate build (often fairly straightforward, once the problems are properly defined) and perform the full test suite again. So features that might be "ready to go" from the dev perspective get bumped to the next quarter's project.

Given that they are already done, it would seem to make for an easy follow-on project, but then PLM counts on that and adds stuff... or some big customer has a huge contract for which they need this-or-that feature in the product... and their industry standards or regulator have just imposed a new demand...

Engineering demands more testers to keep up with the load, and more developers to be able to quickly fix everything the testers find, while also developing new stuff...
Higher management pushes back against that added cost, but gives in partially so that the company can get the big purchase order when the big customer gets their big contract. So the PLMS and Engineering managers hold long sweaty meetings, in which they go back and forth about the miracles that engineering and testing should be able to perform, now that they have been approved 1/3 of the additional resources they said they needed. And of course the realities of staffing ensure that the actual head-counts will only come up to the new allotment after six months (two Agile projects) from now.


Except for the daily scrums, it looks a lot like the old days.

Oh, and the writers are still scrambling at the end to cover what the product _really_ does, as opposed to what everybody was saying it would do, until the crunch caused some changes and deferrals. Oh my.


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.

Learn more: http://bit.ly/ZeOZeQ

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions? Search our public email archives @ http://techwr-l.com/archives


Follow-Ups:

References:
Re: SD Times: Tech Writers Should Be Pigs, Not Chickens: From: Chris Despopoulos
Re: SD Times: Tech Writers Should Be Pigs, Not Chickens: From: Robert Lauriston
Re: SD Times: Tech Writers Should Be Pigs, Not Chickens: From: David Farbey
RE: SD Times: Tech Writers Should Be Pigs, Not Chickens: From: Jack DeLand
RE: SD Times: Tech Writers Should Be Pigs, Not Chickens: From: McLauchlan, Kevin

Previous by Author: Re: The content in your doc is all over the place
Next by Author: Re: SD Times: Tech Writers Should Be Pigs, Not Chickens
Previous by Thread: RE: SD Times: Tech Writers Should Be Pigs, Not Chickens
Next by Thread: RE: SD Times: Tech Writers Should Be Pigs, Not Chickens


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

Sponsored Ads


Sponsored Ads