HeraTech

February 25, 2010

Spinning Plates

Filed under: Uncategorized — heratech @ 8:43 am
Tags:

I’ve been neglecting my Agile blog, and for that I apologize.

For someone who is technically unemployed, I’ve been keeping pretty darn busy so far this year. So busy in fact that I feel like I have several plates spinning at once.

  • Contract Job #1
  • Contract Job #2
  • Interviewing
  • Personal Journal
  • Reenactment projects
  • Agile Journal

Spinning plates

I’ve been working three days a week at my former/current employer (otherwise known as the folks who laid me off last June, then called me back part-time in July because they missed me). They recently bumped me up to four days a week, so it almost feels like I’m working full-time again. Except for that monthly check I write to cover my COBRA benefits that is. I’m grateful to be working as much as I am, when so many of my fellow TWs are unemployed.

Since October I’ve also been working a short-term contract with a TW friend of mine. They needed some help converting a Word document into FrameMaker and he was too busy with other projects to give it the TLC it deserved. I’m starting to think of this as the Short Term Contract that Will Never End (but not in a bad way). The initial contract was for 40-80 hours. I passed the 80 hour mark back in January, but they’re still bringing me in one day a week and sending me paychecks. I shan’t complain.

The hiring situation is pretty dire here in New England, so since I’ve been blessed with income, I have to admit that I haven’t really been looking too hard for full-time work. My friend Stephen expressed it well when I asked if he was going to follow-up on a job lead that I’d sent him? “I’ve got a job, so I feel a bit guilty looking for another one. I figure I’ll let someone who is out of work take that one.” But back around Christmas a friend forwarded me a job opportunity, which resulted in two rounds of interviews. And the requisite running around finding a suitable winter job interviewing outfit (the three interview outfits in my closet are all summer weight), reading through the company’s Web page, researching the company on Google and LinkedIn, futzing with my resume and writing samples, etc. While they didn’t make me an offer, I appreciated the opportunity to meet with them and learn about another one of the companies in my area.

My personal blog is where I post random things, vent about work, and write rather lengthy tales of my weekend adventures. When I took a short trip to visit my parents back in January the trip resulted in 8 pages (4,700 words) of entries. Time spend writing in my personal blog does cut into the time that I can spare to write in my Agile blog.

The last weekend of January and first weekend of February I was at reenactment events. Our group only formed last spring, so we’re still recruiting new members. I had quickly thrown together a recruiting flier last fall, but it didn’t look as professional as I’d like. I downloaded a proper template and reworked the design. I’m not fond of marketing jargon, but I do enjoy playing with fonts and design. So this was one of those little projects that was fun. Since we reenact 16th century Bavarian mercenaries, I wanted to give it an “old-fashioned” feel. I downloaded several different gothic fonts and experimented until I found one that gave the feel I was looking without sacrificing readability (gothic fonts can be horrible to decipher!).

Since I’m a writer, and one of the more computer savvy folks in our group, I was also volunteered to be the Web master for our group. We threw together a couple of pages last fall, but mostly the group uses our Web page as a place to host our discussion forum. Since I was going to be handing out recruiting fliers that included our Web site, I felt obligated to go in and put up a little bit of actual content and clean up some of what was already there. I’d include a link, but it’s not yet to the point where it’s anything to brag about. My side project for the next couple of months is still “building the Web site.” Which will require research, writing, learning more CSS, and time spent experimenting in my sandbox Web site to get the look I want.  I’m a new reenactor, so writing the content is slow going.  And my Web skills for anything other than Help are rusty as well.

The write-up in my personal blog for that first weekend event (a one day event) ran to 8 pages (4,700 words). The write-up for the second weekend event (a three-day trip to Chicago for ReenactorFest) ran to 12 pages (6,900 words). Again, I was devoting my after work writing time to my personal blog and not this one. I haven’t stopped writing (I can’t!) I’ve just been posting my output elsewhere.

Let’s see if I can get the Agile Blog plate spinning again. It shouldn’t be too hard. I gave up that time-thief FaceBook for Lent. And I have Scrum Club tonight. I’m sure I’ll want to write about that when I get home.

Advertisements

February 24, 2010

Agile Tenet #12 – Reflect on Improvement

Filed under: Uncategorized — heratech @ 10:25 pm
Tags: , ,

Number twelveTwelfth in a series of posts examining the Twelve Principles of Agile Software and how each of these tenets can (or can’t) be applied or adapted to technical writing.

*****

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

At my first technical writing job, at the end of every release cycle, we held a post-mortem. Each department would discuss what worked and what didn’t in the last release cycle, and management would meet and discuss what we reported. But during the next release cycle it seemed like we’d do the exact same things, follow the same process, and compile a very familiar list during the release port-mortem meeting. It seemed like no matter how many times we listed things we’d like to see change, we always maintained the status quo.

Some find it easier to list their complaints than to work towards making changes. I suspect that many of my coworkers were too set in their ways and too comfortable with the way things worked to make any major changes. And I suspect that even those who wanted to change found their old habits were just too hard to unlearn.  I know that I find that habits are hard to break, especially when I don’t have real  motivation to do so. This is why I believe that the most important part of this tenet is the second half –  “then tunes and adjusts its behavior accordingly.” The reflection is absolutely useless unless you actually act on it.

Several years ago I came across the concept of kaisen which is a Japanese word for continuous, incremental improvement. Small changes over a long time eventually add up to big changes. It is something that I’ve tried to apply to my life, because if you’re not improving, you’re either standing still or falling behind. This is one of the reasons why I belong to several different STC special interest groups (SIGs) and a couple of technical writing mailing lists. If I’m not keeping up with the industry, I’m falling behind.

Agile tenet #12 puts kaisen to work. The team regularly checks in with itself and examines their own processes. At my company we have a retrospective at the end of every Sprint. We list things that are working (and that we should keep) and things that aren’t working (that we want to change).

One of the benefits of Agile is that you can experiment with changes. A Sprint is a relatively short period of time, typically 30 days. You can try out a change, see if it works, and if it doesn’t, you can easily abandon it. For example, our team has shifted the time for our morning Scrum meetings around a bit. They’re still in the morning, but the times have shifted around between 9:00 and 10:00 a bit depending on the needs of the team (and the season, we’re in New England after all).

I keep reading articles about how important it is to risk failure in order to succeed. So often we are paralyzed with fear, afraid of doing the wrong thing, not sure what the “right” this is, so we do nothing.  But the short time span of a single Sprint lets makes it easier to risk experimentation.  You can try something new for a month, and if it doesn’t work, you can try something different.  Short term commitment is one of the benefits of Agile. And it can free up the creativity of the team, let them take risks (OK, maybe small risks, but risks nonetheless) and work on developing new team habits.

And there may also be an accidental genius to the three or four-week sprint. Convention wisdom holds that if you want to make or break a habit, you need to practice the desired behavior for three weeks. So if the team is trying to break in a new work habit, the length of a Sprint should be long enough to start building the new habit.

And at the end of the Sprint, you can reflect on your changes, decide if they’re an improvement or not, adjust accordingly, and start the cycle all over again.

February 9, 2010

Collaboration – Writing is a Team Sport

Filed under: Uncategorized — heratech @ 10:00 pm
Tags: , ,

Collaborating over a laptopSeveral friends and I started a historical reenactment group last year. Since we are a new group, when we had our first encampment, I wrote up a recruitment flier to hand out to potential new members. I included a list of minimum kit: clothing, shoes, and personal items. I also listed the sort of people we were looking for: those who love history and are willing to work with the general public (especially children). Then I sent the draft out to a couple of our founding members for comments. And Alena wrote back that while I’d listed what potential members would do for the Guild, I’d forgotten to list what the Guild could do for potential members. D’oh! I quickly added a “Benefits of Membership” section to the flier. This wasn’t the first time that Alena had made suggestions that improved my writing.

The popular image of a writer has them hunched over a typewriter in some lonely garret, toiling over their manuscript without any human contact. But that image of the lone writer is a myth. Writers work with other people all the time. If you’ve ever read the Acknowledgements section of a book, the author almost always thanks an entire team of people who helped make their work possible. Chief among the people thanked is often their editor.

At my first technical writing job I was lucky enough to work with a fantastic editor, Paul Dixon. I was fresh out of my TW certificate program, and the only editor I’d worked with until that point was Judy Tarutz, who had volunteered her time to perform an editing pass on the students’ major projects. Working with Paul was a great learning experience. He covered my drafts in blue, green, or purple ink (he avoided red) writing comments, questions, and suggestions in the margins. Answering his questions forced me to reexamine choices or assumptions I’d made, revise poorly written sentences, and delve deeper into the product to expand my understanding. My second drafts were always improved by his edits. The seven years that we worked together helped shape me into the technical writer that I am today.

Some of the writers on our team resisted being edited. Some didn’t want to give up their love affair with the passive voice. And I think that others confused criticism of their draft with criticism of them as a person. It takes a strong sense of self to accept criticism of your work without taking it personally. I find that adopting the attitude that all feedback is for the good of the customer and documentation helps make criticism easier to accept. You need to step back from your writing and humbly accept the feedback that others are offering you.

Are you open to collaboration? Do you collaborate with your subject matter experts on what should be included in the product documentation? Do you work closely with an editor during developmental edits? Do you read test cases to get ideas for customer workflows? Do you tag team with other writers on your team? Do you work with your sales or marketing or training departments to coordinate the public facing documents in your company?

And if you don’t, why not?

My company recently hired a course developer/trainer. I recommended a former coworker of mine that I knew had recently been laid off. I was delighted when we hired him, since I had always tried to work with the training department when we worked together. I’m really looking forward to being able to collaborate with Herb as the work he’s doing interviewing our SMEs will also help me to fill in the holes in my documentation set. We’ll both be working on standardizing the terminology that we use to discuss the product, components, and processes. And when he starts building course modules, I’ll be one of his beta readers. I’m excited that I will no longer be the only person writing content for customers. Having a partner in crime gives us the potential to harness the synergy of collaboration.

Writing is a team sport. Who are your collaboration partners?

Create a free website or blog at WordPress.com.