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.
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.
-----Original Message-----
From: Jack DeLand
Sent: September-16-13 6:15 AM
To: 'David Farbey'; 'Robert Lauriston'
Cc: 'Chris Despopoulos'; techwr-l -at- lists -dot- techwr-l -dot- com
Subject: RE: SD Times: Tech Writers Should Be Pigs, Not Chickens
I agree and disagree with David and Chris. Yes, I think that Agile is best adopted wholesale, as an organizational change. (For a terrific book on organizational development, see Preferred Futuring by Dr. Larry Lippitt, but note that, as a former intern, I am biased. It's still terrific.)
But I have been on a dev team that successfully implemented Agile methods within an non-Agile org. In this case, it revolved around the scrum master, who was able to maintain a balance of expectations with management, and the project manager, who cleared the way. In my current situation, we have an org that is wholly Agile, and life is definitely easier. Again (IMO) it revolves around a very committed and very talented scrum master, but the management support goes all the way up the ladder to the man with the Carrera S. There is no way of subtracting or negating the human element, unless you want to go to robotics.
I have never been in a waterfall environment where dates did not slip.
Agile, to me, is a terrific improvement over traditional methods, if only because it gives voice and a real degree of control to the people who are actually creating the product as a way of working daily, not as a happy exception. This is key to the "preferred futuring" approach.
I would recommend scrumalliance.org to anyone interested in investigating Agile further. Again, as a graduate, I am biased. But I am also definitely committed. Oink.
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
