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.
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.
