bookmark_borderRetrospectives

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.

bookmark_borderPortishead

After a fairly epic night out on Friday (why do I drink vodka shots when I don’t really like vodka…?), I was a little fuzzy round the edges on Saturday. I was also completely knackered having spent most of my week facilitating meetings, which is far more tiring than both it sounds and that I expected.

Frankly the thought of driving through to Edinburgh to stand in a crowd for a few hours wouldn’t have been my choice except for one reason. It was to hear Portishead, remember them? Two albums (three if you count the live one) and then.. nothing. Those two albums are part of my staple choice, my backup when I get bored and want something comfortable to listen to, music that I tend to have on in the background when I’m at home.

So when I heard (via a Twitter from Paul) that they were touring again I snapped up a ticket within the hour. The anticipation of seeing Portishead live, hearing THAT voice live started and I remember thinking that I needed not to let myself get too carried away, that it might not live up to the expectation I was setting in my head.

I was wrong. They were amazing.

It was one of those gigs that will forever change the way I listen to their music, it was one of those gigs that had moments when the entire place was silenced and in genuine awe of what they were hearing and watching, it was one of those gigs that you talk about with reverence in years to come.

It’s also one of those gigs that I’m struggling to capture with words. The way it veered from a ferocious assault to a genuinely heartfelt, lump in the throat moment, outlined their ability to deliver something much more than their album tracks. The way the atmosphere shifted through the gig, and how such a slight woman can hold a room of thousands in her hand and she rips emotions from within, delivering them with a snarl or a smile.

I’m wary that every gig is a good one, and that I take few risks when choosing which concerts I go to see, but I really wasn’t sure what to expect last night. I’ve held off writing this post to try and distant myself a little but I think I’ll stand by the Twitter message I frantically typed out, with slightly shaking hands, as I tumbled out of the venue. It may not be eloquent but it encapsulates my emotions at the time, and my feelings about the gig that still linger.

Pretty fuckin awesome.

bookmark_borderRecently Read

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.

bookmark_borderAre you pondering what I'm pondering?

Sshhhhh.

I’m thinking.

I’m thinking about what to write.

I’m thinking that I’m not sure where the tub of Polyfilla is, I’m hoping it didn’t get thrown out.

I’m thinking that I shouldn’t really be writing this post as my entire week is chock full of meetings and I need to grab every single available moment to ping off some emails and keep up to date with what’s going on outside of the meeting rooms which are currently almost a semi-permanent home.

I’m thinking that finding a better way to do things AFTER you are committed to a particular way of working is a little daft…

I’m thinking that having all 103GB of my music here at work is actually a bad thing as I spend WAY too much time flicking through tracks to find something that suits my mood.

I’m thinking that I really REALLY enjoyed the Pixar book I finished reading yesterday (it was a Christmas present) and that I should post up my thoughts/review but I don’t currently have the time.

I’m thinking that I should stop thinking and get something done!

What are you thinking?

bookmark_borderHarissa Paste

Picture the scene, if you will, of a dashing and debonair young man, slim of body with flowing locks of blonde hair framing his sculptured face as he lounges gracefully on a chaise lounge. Soft music plays in the background, whilst the delicate fragrances of dinner waft from the kitchen. A tranquil scene I’m sure you’ll agree.

Now picture the exact opposite, a slovenly baw-faced guy slouching in front of the TV, his belt undone, his thinning hair needing cut, his face unshaven.

That pretty much sums me up at the moment, but then it’s been a busy weekend.

Friday night found me dashing into Glasgow to catch Elbow at the ABC. Doors opened at 6pm the ticket said, something I only realised at 6.04pm when I lifted my ticket to put it in my jacket pocket for later. Of course, having jumped in the car and raced into Glasgow, I arrive at the venue to find a growing queue standing outside and received confirmation from the bouncers on the door that doors didn’t open until 7pm. And yeah, it didn’t matter what my ticket said, alright?!

Minor glitch over, the gig was pretty damn good. I was largely going on the strength of their last album, having not had much chance to hear their new one, nor having spent much time listening to any of the others. It didn’t matter though, as the band were pretty slick, and BOY can that man sing, what a voice (although I should mention the quality of the sound, it was spot on, you could pick out every instrument and voice). Top gig, and I got to meet Paul as well, bonus!

Saturday and we were up early, with the car filled with a variety of rubbish to be taken to the dump, then a quick bit of shopping and a few other chores before heading back home. Then, alas, it was off to work for a few hours before hooking up with my parents for dinner.

And today saw some DIY, the fitting of a new light in the kitchen and a few other tidy up tasks as we continue to return our house to some sort of order.

Ohh yes, the kitchen… it’s lovely, thanks (see for yourself)

Anyway, harissa chicken is cooking on the oven, some roast vegetables will be going on soon so I’d better get the table set and open a bottle of wine. Hope your weekend is ending as well as ours.

bookmark_borderRecently Read

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.