December 24, 2009

Agile Tenet #5 – Motivated Individuals

Filed under: Uncategorized — heratech @ 9:43 am
Tags: ,

Five employees Fifth 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.


Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The part of this tenet that really resonates with me is trust them to get the job done. Abby Fichtner recently posted a link to Scott Berkun’s open letter to micromanagers, and I can’t stop thinking about it. I think that Scott’s opening lines are absolutely brilliant:

Owners of thoroughbreds never stop their horses during a race, every ten seconds, to remind the horse and jockey how to run, where the finish line is, or that it’d be a good idea to finish first. Why? It would slow them down. Only an idiot would do this.

I once worked for a micromanager who wanted me to track a dozen different milestones for every single topic that I wrote, and send her a daily report on my progress. After working for several years for managers who wanted a simple weekly “my project status is green/yellow/red.” status update, I found this new system to be highly demotivating. I felt like my new manager didn’t trust me to do my job, and the constant status updates had a definite negative impact on my productivity.

I’ve usually been lucky enough to work for managers who checked in on me every so often to ask “Is there anything I can do to help? Need anything? No? OK then, carry on.” I am a trained professional, perfectly capable of planning and executing my work by myself. I understand my manager needs to report to upper management, and as long as they let me know what they need from me, I’m happy to provide it. But I don’t come to work to write status reports, I come to write user documentation.

The other, more difficult part of this tenet is Give them the environment and support they need… The physical environment is relatively easy to provide: powerful computers, comfortable chairs, a variety of caffeine sources in the break room, etc. What is harder to quantify is the cultural environment of an office and team dynamics. Over time I’ve come to recognize that there are three types of employees that can severely negatively impact a team:

  • Incompetent employees who create problems for their coworkers
  • Lazy employees who cause more work for their coworkers
  • Toxic employees who cause morale problems for their coworkers

When I say incompetent workers, I’m not talking about people who are lacking in skills. Skills can be learned. I’m talking about people who present themselves as being experienced, senior-level employees, but they’re fooling either themselves or their employers, because they are incapable of working at the level that they claim.

I once had a project updating documentation that included examples of SQL for querying and modifying the database. I knew enough about recent database schema changes to know that the examples would no longer work, but didn’t know enough SQL to be able to correct them myself. I asked the product manager for help. Over the next several weeks he put me off, sent me the existing examples that I had told him were wrong, sent me old examples that worked against the old schema, and generally did not answer my questions. It finally became clear to me that while I didn’t know very much SQL, he knew even less. And wasn’t about to admit it. Finally his incompetence became so obvious that the company had to replace him with someone else. And I was able to get more accomplished in two weeks with the new product manager than I had been able to accomplish in several months working with the old PM.

I read a quotation that has stuck with me “Meetings move at the pace of the slowest person in the room.” I think that you can also say the same thing about teams. Incompetent employees slow down the team because their coworkers have to spent time cleaning up the problem worker’s messes and solving the problems they create rather than doing their own work.

The best example of the lazy employee can be found in the comic strip Dilbert: Wally walks around drinking coffee all day, but never seems to do any work. I suspect that we all have at least one Wally in our offices. I’ve worked with several over the years. Team members notice when someone shows up late every day, takes an hour and a half for lunch, then disappears for 45 minutes every afternoon to go pick up coffee at Dunkin Donuts. (And we also notice when managers continue to tolerate this behavior.)

If you’re a slacker, there is nowhere to hide in an Agile environment. You have to stand up every day and tell the team what work you accomplished the day before.

The third type of employee that can negatively impact a team is the toxic employee. And these are the hardest to deal with, as being toxic is less a matter of behavior and more a function of personality. A toxic employee may be a pessimist, constantly complaining about things. They may be combative, constantly arguing with people. They may spread malicious gossip. And sometimes the most brilliant people in an organization can be the most toxic, because of their arrogance.

I once worked with a writer who made enemies faster than anyone I’ve ever met before. She had usability training, and came into the company with lots of good ideas for how to improve our product, but she had no idea how to present her ideas effectively. It wasn’t so much what she said that caused her problems, but that she presented her ideas as criticisms, and often in a very insulting manner. For example, she invited herself to the UI team meeting and proceeded to give a presentation about what was wrong with their design. She wasn’t a member of that team, and hadn’t told the team leader that she would be attending, or that she wanted to provide the team with input. She just showed up, took over the meeting, and effectively told the team that they weren’t doing their jobs correctly. She was the sort of person that sends you running to the self-help section of the bookstore searching for books about how to deal with toxic coworkers. (I found strategies that saved my sanity in the book The Sociopath Next Door by Martha Stout.)

I know this is a deeply heretical statement (especially when so many people are out of work through no fault of their own), but some people need to be fired. It is the only thing that will make any change in their behavior. Poor workers need to be taught that their behavior is not acceptable. Managers need to coach problem employees. Give them a short probationary period to correct the problem, but if there isn’t drastic improvement, fire them. Some people cannot hear the message that they need to change until it costs them their job.

Sometimes firing someone is the best thing for both the team and the problem employee. The bad team member will get the wakeup call that they must make changes in order to remain employable. And the team will be more productive without the problem employee dragging them down.

Build teams of motivated individuals. Then give them the environment and support they need, and trust them to get the job done.

December 4, 2009

Agile Doc Reviews – The Documentation Sprint

Review discussion When I was working in a Waterfall development environment, the main documentation effort came at the end of the release cycle.  Sometimes the writers didn’t even start to receive team meeting invitations until the coding effort was well underway.  And by the time I needed documentation reviews, the product managers were often busy working on the next release.  On more than one occasion I had a PM give me a review comment about how a feature worked, and I had to show them that I was writing against the current code, while they were thinking about their design for the next release.

In an Agile environment, reviews for new features should be happening within the same Sprint as the development and testing.  But from what I’ve heard, that’s not always how it ends up working in practice.  There are Agile shops where the documentation happens a Sprint behind the development.  Which is still much quicker than in a Waterfall shop.

But what about major reviews?  Sprint reviews only cover the features being developed during a single Sprint.  At some point, the entire document or Help system needs to be reviewed for accuracy. For example, we’ve recently rewritten our installers.  So the entire Installation Guide has been rewritten and needs to be reviewed as a whole.  But we’ll also need to check the User Guide to make sure that we’re not referencing path names or files that no longer exist.

At some point in the cycle we need to plan time to concentrate on documentation reviews. I found my answer to the question of how to make this work before I had even really started as an Agile Technical Writer.  Last October, during my second week at my new job, I attended the DocTrain East conference in Boston.  [Unfortunately the company that put on the conference is a victim of the recent economic downturn and has closed their doors.]  One of the keynote speakers was Adam Hyde speaking on the topic “Read, Write, Remix: The FLOSS Manuals Story.”  This is what I wrote in my diary about his talk:

The other interesting idea that I got from his talk was that of a “documentation sprint.” Sometimes they gather 4 or 5 writers in one place (usually a nice hotel) and they’ll spend four days cranking out a manual. Since “sprint” is another Agile term, I wonder if I can talk the development team into doing one or two documentation sprints a year to help me crank out even more doc?

I took the idea right back to the office where I shared it with our VP of Engineering. The company had promised customers a new guide.  I’d been there less than a month and was still drinking from the fire hose, but hadn’t yet reached the point where the product made sense yet.  I wasn’t going to be able to deliver by the deadline by myself.  My VP loved the idea of a documentation sprint. In fact, within less than 24 hours of me mentioning the idea, he’s scheduled a meeting, we’d hashed out a general plan, and picked which week we were going to kick this off.  

During our planning discussion we’d joked about locking everyone in a conference room, ordering pizza and not letting them leave.  I said I’d dig out my official Hall Pass from my teaching days.  We ended up getting IT to set up computers in one of the conference rooms, and several of us sat and worked together during the week-long documentation Sprint. I mostly organized, formatted, and edited, which is not now I prefer to work. But since I hadn’t had time to learn the product,  I had to content myself with role-playing (rather convincingly, if I say so myself) a novice user who didn’t know anything about the product.

Our first doc sprint was a rousing success.  We went from blank page to released manual much quicker than I would have ever imagined possible.  One of the reasons why I think it was so successful was because management really got behind the idea.  Management made it clear to the developers that for a week, they were to concentrate on the doc.  And documentation reviews always succeed or fail based on management support.  If your managers don’t make it clear that reviewing the documentation is important, then reviewers don’t make it a priority.

As I like to remind people, we ship two things to the customers: software and documentation. Code needs to be tested, and documentation needs to be reviewed.

I anticipate that our next documentation sprint will be shortly before our next major release.  Scrum has enabled our developers to make some major changes to the product, and I’ve been making some major changes to the documentation set.  I want to make sure that the docs represent the current state of the product.

The FLOSS Manuals site has a book all about book sprints.

Anne Gentle blogs about doc sprints and other Agile techniques.

November 28, 2009

Lean Software Development – Eliminating Waste

Filed under: Uncategorized — heratech @ 1:20 pm
Tags: , , , , ,

Waste barrelI’m still digesting last week’s Nashua Scrum Club meeting. As a technical writer, one of my roles in the organization is to be a user advocate, so I’m pondering the concept that “everything not adding value to the Customer is considered waste.”

I’ve been fan of the concept of kaizen or continuous, incremental improvement, for a couple of years now. Now I can add to that muda, the Japanese term for an activity that is wasteful and doesn’t add value or is unproductive. I wish I’d been exposed to lean principles last spring when I was talking to my manager about how I wanted to handle documentation bugs.

When I was hired last October there was a pretty big backlog of documentation bugs because 1) the company had been without a technical writer for six months before I was hired and 2) the Support manager had recently had the members of the Support organization read through the entire doc set and enter bugs and enhancement requests.

Since I’m a lone writer, I would prefer that when someone finds a simple typo (misspelled word, missing punctuation) that they simply e-mail me so that I can correct it. This would lead to a very simple workflow:

1. Employee sends an e-mail to the technical writer.
2. Technical writer reads e-mail.
3. Technical writer opens document files and fixes typo.

This workflow can lead to a simple typo being fixed within a few minutes of it being found. As a fan of efficiency, this is my preferred method of dealing with typos. If someone e-mails me a problem that takes more than five minutes to fix, it makes sense to create a documentation issue to track the work on that issue (and to make sure that it doesn’t fall between the cracks and get lost in my inbox).

However, my manager wanted to track ALL documentation issues, no matter how small, in our issue tracking system. This leads to a workflow like the following:

1. Employee enters an issue. Note that not all of our employees have permissions to create issues in our system, so the employee may need to find someone else to enter the issue for them.
2. The issue has to be triaged by one or more managers, assigned a priority and a target release, and assigned to the technical writer.
3. When the writer receives the automated e-mail that the issue has been assigned to them, they may have to go to the issue tracking system to view the issue.
4. Writer opens the document file and fixes the typo.
5. Writer has to go back into the issue tracking system and change the issue status to “fixed” and then assign it to the QA manager. Because I don’t generate PDFs on a daily basis, this may not happen until days or weeks after I’ve actually fixed the typo.
6. QA manager assigns the issue to a QA tester to verify that the issue has been fixed. Sometimes this doesn’t happen until we are nearing a patch release, as the testers are testing code, not checking that typos have been corrected.
7. QA tester checks the documentation and closes the issue.

This was the workflow that we used at one of my previous jobs, where I was a member of a large doc group and the writer responsible for any particular document might change at the end of a release. But since I’m the only writer at my current job, and typos aren’t something that I need other members of the team to assist me in correcting, it doesn’t make sense to me to have so many people involved in verifying whether or not a word was spelled correctly or a period was added at the end of a sentence. Instead of a process that takes two people and five minutes, my manager wanted a process that involved at least seven people and could possibly take days or weeks to complete.

This just seems wasteful to me and not very Agile.

How do other lone writers, who don’t have peer reviewers or editors, handle editorial tasks? Especially in an Agile environment?

Create a free website or blog at WordPress.com.