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.
In the interest of breaking the latest protracted list-silence...
I dunno about you, but the only time I write explicitly about a new feature, AS a feature, is in the Customer Release Notes.
In the main docs or Help, I write about new/changed commands and command options, describe and provide procedures for tasks made possible by a new feature, and how to enable new capabilities, and so on. If I have to indicate, at all, the fact that something is new, it's only to lay out how it must be configured/used to either co-exist with existing features, or replace them. "You must stop doing that before you can start doing this..." or "If your existing framistani used frabbleglop authentication and your application requires continuity, then your adoption of the frimmel-himmel is constrained to a subset of ...."
In our less-than-ideally-Agile Agile environment, I'm invited to the early sprint scrums, and I find it interesting (and sometimes entertaining) to follow the development of new features, fixes, etc. But I find it counter-productive to start writing and to "produce" for the sake of producing (i.e., demonstrating my Agile spirit) at that early stage. Whenever I've held my nose and forced myself to kick out some vapor, invariably I've had to trash it or do major re-work during a later sprint (close to end of dev, start of verification), when the new shape of the product is firm.
Yes, I know a few people will chime in, right about now, with the rules from Agile god-hood, and how their dev-group's new features are always perfectly self-contained and beatifically modular, and not only can be, but are tested to doneness in perfect tandem with the dev sprints, such that a finishing test/verification sprint is an unnecessary redundancy, just as a production-integration phase is entirely unheard-of in their world.
But I suspect more organizations are like us than like the ascended ones.
We exist on a lower plain of Agile wannabe-ness, where testing occurs in stages of greater and greater scope, until the new feature fits into the overall product and doesn't break anything (and also doesn't break or irritate any of the new features being developed by other groups, who might be developing only for a later release), and has been stressed for lengthy periods without failure. Oh, and we deal with people leaving and with people being glommed for other projects, leaving resource and knowledge shortages. And we deal with upcoming release-scope changes as a new partner or big Beta customer is brought on board with differing/additional needs or a different take on the feature(s) that must be shoe-horned into the release.
So do you normally find it valuable to do any writing - as opposed to planning and research - in the early sprints leading to a release? Or does it reliably make more sense for you to hold off until the Jell-o begins to set a bit, before trying to nail it to the wall?
For bonus points, is anyone being successfully Agile, where the Product Manager does NOT attend a significant number of scrums (any...)?
For further bonus points, is anyone being successfully Agile where your Scrum Masters are just the engineering team leaders and managers, and NOT people whose primary duty is leading/driving sprints and scrums? In other words, is a purpose-built Scrum Master necessary for Agile success, or can it be just anybody with the discipline and clout to keep meetings on track and moving briskly, and maybe they read (part of) a book about Agile?
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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Doc-To-Help 2014 v1 now available. SharePoint 2013 support, NetHelp enhancements, and more. Read all about it.
