“Waterfall is dead, long live Agile,” many voices cry, heralding a transition in the software industry from heavyweight engineering efforts to an almost sports-like scrimmage. Waterfall didn’tkeep up, they complain. Projects turned into congested pipelines and out of desperation to reclaim fluidity, the entire cycle broke down into an environment of iterative re-development that gave birth to Agile. Increasingly, developers collaborate in short sprints to rapidly address evolving concerns rather than as construction crews working from blueprints. What does this new era mean for technical writing as part of software development? More specifically, what is expected of an Agile Technical Writer?
Category: Screencasting
Hello again readers! Last time we “met,” I had the pleasure of walking you through a quick primer on the Kirkpatrick model and how to best use it to assess the effectiveness of a given training program or set of training materials. My main argument was – whatever you do – make sure to focus on metrics that allow you to show measurable positive impacts that can be easily translated into $ savings. The bottom line is… well, that’s what your manager will be looking at, the bottom line. What’s the return on this documentation investment? At the end of the day, how many dollars does it put back in our pocket?
In technical writing (as well as other areas of life), having a smartphone on me has saved my butt on more than one occasion, and not just for looking up directions to a client site or doing some quick on-the-spot research on some byzantine technical topic that I need to understand.
I recently completed a first round of reviews for a new product demo screencast that we are creating for one of our clients. One of the comments we received was that although they had requested for the demo to be silent, the reviewers felt that adding some background music would be a major improvement.