Last week I spent most of my time facilitate our retrospectives, that is I spent a lot of time chairing meetings, encouraging and monitoring debate, and far too much time manipulating Post-It notes. Let me explain.

Within the development group, we base our working practices on Agile development and part of that suggests that at the end of each release cycle you should hold a retrospective session to pinpoint things that went well, things that didn’t go so well and to assign actions which will help improve things next time. It’s all about continuous improvement and we do get a lot of benefit from them.

Don’t be put off by the name, it’s essentially a debrief session that is focused on a particular area, and the process is quite simple although ours has changed a few times and the sessions we held last week were, again, something new to try and improve the retrospective process (we actually hold retrospectives of the retrospective to make sure that the retrospective is improving as well… ).

Our development group is broken into teams, and each team is asked to consider their own working processes within the overall adoption of the Extreme Programming methodology (the branch of Agile development we follow).

And then it’s Post-It note time!

Each team member is given a pad of Post-Its, and we spend 10-15 minutes jotting down things that went well, one item per Post-It. Once the time is up they Post-Its are stuck up on a wall or whiteboard, and grouped into common themes. Then we do the same for the things that didn’t go so well (ok ok, “what went wrong”) and again they are stuck on a wall and grouped.

The common groupings in each category give you things to continue doing (what went well) and things that need improved (what went not so well). Then comes the fun bit!

Each team is given control of their own working processes, and are encouraged to discuss and decide on actions to improve the process where it’s been identified as being weak.

We then gather each team together for a reporting session at the end of the week, during which I teased out the common threads in each category, the items that everyone identified. That final session was interesting, and suggests that, despite having been split into small teams (8 people per team, including 1 tester and 1 technical writer) everyone identified some similar issues, and everyone agreed that certain things were working well.

One of the common “what went well” topics was agreement that having a tester and a technical writer embedded in the development team was of benefit, something I thought but hadn’t ever received feedback on until now. That was a nice moment.

Call it a debrief, call it a retrospective, but an honest appraisal is hugely beneficial. It can be hard, and at times the discussions were heated, but everyone was honest and upfront and we should see the benefits over the coming weeks of this release.

Now, does anyone know what I can do with a few thousand Post-Its??

UK readers, Skill Matters are running a session on Agile Retrospectives next week.

Another week has zoomed past, and I’m only now catching up! I’ve been helping out with our development group retrospectives… but more on that later. For now, here are a few things that caught my eye this past week.

Gatekeeper vs. team member
Whilst not directly talking about technical writing, there are some good points in this post, with several mirrors between some of our [sic] processes and that of the self-publishing author:

…some authors, trusting no one but themselves, will put out what they have to say, untouched by any other person. Sometimes this works. Usually it doesn’t. Others will reject the criticism of experts but accept the flattery of a subsidy publisher. Others will embrace the traditional publishing process and accept the input of those who have more publishing experience than they. Others fall along the full spectrum in between.

Is single source always the best option?
Single source, rightly, gets a lot of press and for a lot of companies would be of benefit. However it can be hard to convince others of those, here’s an example:

I know a single source of content will save me a lot of work. But for other people in the company it won’t. It will mean more work for them, not to mention a very steep learning curve, an investment in software and a strong training committment. It will save me lots of time and effort—in the long run—but it’s going to double the work effort of ten other people. Where is the benefit?

The last business case I pulled together this was the sticking point as well. Understanding the pain points, and how much they cost the company is key and the benefits need to be realised over a longer time period than you’d think.

Are you part of the industry conversation?
Anne Gentle (via Twitter) pointed out that Sun now have a formal blogging policy in place for their employees. It’s a great step and shows that they understand the role that blogging can play:

… By speaking directly to the world, without benefit of management approval, we are accepting higher risks in the interest of higher rewards. … The real goal isn’t to get everyone at Sun blogging, it’s to become part of the industry conversation.

Confluence Wiki adds page ordering
I’ve talked about Wikis before, and largely I think the core value comes through long-scale collaboration and, as such, haven’t really considered moving our documentation set to a wiki. There are very good cases for wiki-fying your documentation set of course, but for me there are one too many limitations. This news from Confluence is starting to change that as summed up by Sarah:

When you’re writing a documentation set, the sequence of the pages and chapters is very meaningful. It’s nice… well, many would argue that it’s essential to be able to define a logical page order rather than being stuck with an alphabetical order. Up to now in Confluence, we’ve worked around the problem by manually adding chapter numbers and page numbers, like “1. Introduction”, “2. Installation Guide”, “2.1 System Requirements”, and so on. Now take a look at point 2 in the Confluence 2.8 Release Notes. We can just drag and drop the pages and chapters where we want them. They stay there :) and the new order is reflected in the PDF outputs and hierarchical page-tree views

Thinking like a user
I spend a fair amount of time reminding developers that they have a different mental model from (some of) our user base and that the design may be improved by taking the point of view of the target user. However I should confess that I fall into the very same trap myself:

the problem with being able to think like a user is that familiarity breeds … well, familiarity .. we’re using (at least I hope we are) the applications that we document daily … building a store of information about the application [and] we can easily lose sight of what the new user, who comes to the application tabula rasa, may experience.

Yup. Guilty!

Word 2003 Tip: Edit in Print Preview mode
I didn’t know this one either. You truly do learn something new everyday.

Ahhh, the end of another week (well it will be in a few hours, just a few last diagrams to be rebranded…), which means it’s time for a quick roundup.

Pilcrow & Capitulum
A nice little post for the font freaks (guilty!) discussing the evolution of the that little symbol that is often used to mark the end of a paragraph.

It’s tempting to recognize the symbol as a “P for paragraph,” though the resemblance is incidental: in its original form, the mark was an open C crossed by a vertical line or two, a scribal abbreviation for capitulum, the Latin word for “chapter.”

Open Applications – A Model for Technical Documentation?
Ferdinand Soethe takes a look at the Open Source movement and finds several parallels and arguments for basing a technical documentation effort on the same principles. It’s not all a perfect match but this confirms some of my own suspicions.

Talking with Technical Editors on the topic of Single Source Publishing (SSP), one sometimes gets the impression of talking about Utopia. (Nearly) everyone knows it, nearly everyone could well use it in their work, but hardly anyone actually uses it.

The necessity to prepare contents for different target media can neither be really met with classic text processing or DTP systems nor with Web design tools. This was why the XML language family born in the 90’s found huge acceptance in the area of Technical Documentation.

Rethinking Community Documentation
An old but still valid and fascinating article exploring the changing landscape of technical information:

The way we educate ourselves to use and program computers is shifting along many of the same historic lines as journalism, scientific publication, and other information-rich fields.

As an industry much has changed in the two years since Andy wrote this article but it’s still worth a read, particularly if you are looking at launching your own technical community initiative.

Three Ways to Get Developers to Keep You up to Speed
A simple reminder of how to get things done, the kind of advice that sometimes seems very obvious until you read it and realise you aren’t doing it! I’m tempted to print out the three “rules” and pin them to the wall.

Get support from those whose voices everyone takes seriously. Chances are, you were hired because someone thought documentation is important. You may find yourself in an environment where you have to prove your importance, and many times that is a battle fought for a matter of inches rather than miles.

As ever, I’m keen to hear about any other technical writing/communications focussed blogs, in any area. If you write about your job, regardless of your industry, do let me know.

I’m getting royally fedup with a lot of what I read that is written in the name of usability. Maybe it’s just a personal loathing of the overly academic, or perhaps I lean towards simplicity a little too heavily but SHEESH, some of the better known experts can’t half prattle on…

I’m a member of the usability team at work, largely because I made a lot of noise about it when I joined the company, but also because as a technical communicator who is passionate about the entire experience of using a product, I realise that the interface is THE most important part of communication between user and product.

I’ll let that one sink in, shall I?

Despite our own protestations, we all know that while good documentation is crucial to a product, it’s the user interface that carries the bulk of the load of communicating the capabilities of the application. With that in mind it makes sense to be as involved as possible with the design of the interface for, as I read somewhere many moons ago, we [technical communicators] are “the interface to the interface”. So, if nothing else, getting involved in usability and screen (UI) design for your application should make the job of documenting the software a lot easier.

Now, I’ll happily admit I’m still very much a novice in this area, but I’ve picked up enough knowledge over the years to be dangerous. I’m very aware that my advice tends towards what I would consider common sense, but generally speaking I base my UI design comments, and generally usability thoughts, on the following processes:

• Simple task analysis - picking out the main usage of the application should be pretty straightforward, but sometimes narrowing that down into distinct tasks can be trickier, so I tend to mentally “step back” everytime I approach a new screen and ask myself what it is I would WANT to be able to achieve given where I am in the application. Often you will find that the flow of the UI isn’t quite right.
• Narrow your view - the next step is to pick out each control to make sure the label, text or icon make sense. It’s very easy to get caught up in the overall task and presume too much.
• Quick, write something! - this step can be done mentally, with pen and paper, or just start typing. I often find that it’s only when trying to “tell the story” of how to use an application that all the pieces finally fall into place… and then you realise that one is missing.

As I said, I’m no expert but my approach seems to give reasonable results. Yes with formal analysis, metrics and so on, you can always improve things but sometimes perhaps good enough is good enough?

I sometimes wonder if I’m actually doing more damage than good so I’m quite careful that my opinion isn’t the only one (ok ok, isn’t the LOUDEST one), and I try and keep up with things - Boxes and Arrows & Jakob Neilsen for example - and I’m convinced that there is a big enough overlap between the two professions that one day I’ll be hiring a “usability writer”. No… a “technical usabilitist”…