Kanban is a lean, or just-in-time methodology which is often used in manufacturing for inventory control and, like many good methodologies (including Scrum), originated in Japan. The philosophy is that you should only take on as much work as you have the capacity to perform. As translated into Scrum-Ban, each team member maintains a Work in Progress (WIP) board where sticky notes are placed in columns to represent scheduled tasks (Sprint commitments), tasks that not planned but necessary, work in progress, completed tasks, and impeded tasks.

We are committed to work on no more than three tasks at a time. The WIP board gives visibility to our progress and status. When a WIP sticky is moved to another column, a task-in-waiting sticky takes its place. (See Scrum and the Single Writer.)

I hadn’t heard of Kanban before, but it seems to get at a problem I’ve been experiencing lately: over-allocated workloads. I think it’s pretty common for technical writers to end up with more work than is possible to do given the time allotment. We’re all busy, right? But I think there’s more to it than this. How much work should you take on as a technical writer?

In a company where there are just a few technical writers for hundreds of developers and other IT workers, the amount of help material needed can require technical writers to bounce from project to project, producing mediocre help materials or to constantly work overtime.

Consequences of mediocre help materials may be any of the following:

• The help consists only of text — no illustrations, quick reference guides, videos, or other training.
• The help doesn’t get translated.
• The help isn’t context-sensitive within the application.
• The help isn’t comprehensive (some tasks are simply not addressed).
• The help isn’t in sync with existing bugs and other problems in the application.
• The help hasn’t been written based on any research from users.
• The help doesn’t evolve based on user feedback after the application’s release.

In situations where the workload exceeds the technical writer’s capacity, help quality suffers. Help begins to fulfill the common stigma of useless, and the more useless it becomes, the less value the company places on help material.

Exactly what should a technical writer do in this situation? Do you continue producing mediocre help documentation for your seven+ projects, or do you say no to the incoming workload and focus your energy on creating outstanding help for just a couple of projects?

I’m not that familiar with the Kanban methodology as it applies to agile, but as I understand it, one Kanban strategy is to limit the amount of work each team member focuses on.  Allan Kelly explains a bit more behind the originator’s approach:

David’s innovation was to explicitly limit the work in progress. This had been done by other Agile teams before but in Kanban there is a well-known limit on the number of work items which may be worked on at one time. The limit is usually quite low, in the teams I have worked with the limit is approximately the same as the number of developers on the team or slightly less.

… Many Agile teams use a white board to track work during an iteration. Typically this is divided in to three sections: “To do”, “In progress” and “Done.” When a physically limit to work in progress is imposed it becomes useful to split this down further. Work in progress could be: in development, in test, in analysis or in other states. Each of these may have its own limit. (See 10 Things to Know About Kanban Software Development)

I like the idea of limiting the number of work items that you focus on. JIRA is a software bug tracking tool we use that has a similar feature. JIRA allows you to track items you’re working on. You can assign story points to each item, giving it a weight of difficulty. You then break up the JIRA items into sprints, limiting each sprint to a set number of story points. This prevents you from over-allocating too much work for each sprint.

I don’t know if Kanban provides the solution to over-allocation. I do know that producing mediocre help material is not very satisfying. As a professional, I want to create the best help possible for products I work on. If I can’t, if I have to split my time among seven different projects, barely keeping up with some, receiving information about functionality weeks after release, and not being in the loop of known issues, plans, and other team momentum, or simply not having the time to work on the projects, then I think the company needs a wake-up call to hire more technical writers.

The only way they’ll get that wake-up call is when a technical writer learns to say no to the increasing workload. Of course, your manager might not like this, and having developers create the help instead is not ideal either. Another possibility is that applications might not receive help material at all, which would be unfortunate.

I’m curious to learn what you have done to address over-allocation.

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

The work keeps piling up -- who can do it all?

Sebastian asks,

I have been searching the web for information about how to divide workload among writers as the the workload–and the department itself!–grow. I am thrilled to find your blog! I am a new writer in a Health Information Systems doc group. We write for 120 products, maintain 600+ documents (several output formats). Do you know of any effective strategies/tools/medications?

What kind of documents do you produce?

We produce online help, how-to guides, quick reference guides, manager’s guides (procedural content), introductory guides (conceptual content), release notes, configuration guides, known product issues, tutorials….

Do you do translation too?

Translation/localization of deliverables seems to be evolving here. There is an international department who have a couple of writers . . . What happens might be translation but is not certifiable localization.

Any other factors that caused the increased workload?

I think what broke our system was an acquisition that increased department size by about 50%. Our lead writers had been coordinating work across product families, but the definitions of product families have gotten a little too fluid, and the workload has gotten so huge that we can only do part of what’s needed, so there’s now a backlog and it’s growing, and we’ in the midst of this move to AuthorIt, which adds work in itself…. We’d like to know what really big teams do to keep everything coordinated.

Our 50% increase did include some writers, and I know that part of the chaos comes from trying to train people on new products at the same time they’re trying to meet deadlines. But I think if I could condense the problem to a single category, it would be about coordination and communication–knowing what’s going on across that broad range of products, having the workload allocated so that the deadlines are distributed reasonably, that sort of thing.

Did the 50% size growth include an addition of new writers?

I guess I envision that other groups have tools of some kind that automate this kind of tracking, or they have some information-exchange routine, or a set of job assignments that somehow pull all the information together and keep the workload balanced.

I’m using an online project management system for tracking how hours are spent, spreadsheets for trying to balance workload (don’t even ask–corporate decisions prevent us from using a single tool for both types of tracking), lead writers for keeping up on product family information, and all kinds of meetings–methods that worked when there were 12 of us but that don’t seem to work now that there are 18.

Dear Sebastian,

Thanks for writing. I’ll share my thoughts and others can build on them in the comments if they have anything to add.

Get Professional AuthorIt Training. About AuthorIt, one thing I recommend is that you get someone to come in a provide training on it. It can take months before you feel comfortable with a robust product like AuthorIt. When I was in Florida, a colleague at another company was moving to AuthorIt (from RoboHelp). She hired Char James-Tanny (helpstuff.com) to come out and provide 3 days of training. It worked pretty well. I would recommend that training for your company too, unless you already have AuthorIt gurus.

Set Up AuthorIt Templates. I also recommend seting up AuthorIt templates and styles for the entire team to use, or even pay the trainer to come in and set them up. This can reduce the learning curve.

Insert Writers Early On in Software Development. As far as distributing the workload, inserting the writers into the software development process early is always best. That way they can stay in the loop through the entire process and be better aware of changes and other information that affect documentation. It’s the last minute emergency documentation needs that stress writers out. Or being expected to write documentation without complete information and access to the product and SMEs.

Deliver Only What Users Want. You can also survey your users to ensure you’re actually delivering the help content they want. If they only want online help and a short quick reference guide, you might do away with the long printed manual. (See this post for more info.) Of course, if you set up the AuthorIt templates and styles right, single sourcing to print shouldn’t be too arduous.

Provide a Style Guide. Having a simple style guide helps avoid the guesswork of technical writing. When writers know what style is expected, they don’t have to spend time making stylistic decisions. (But don’t go overboard with a 200 page style guide. Keep it short and sweet.)

Lighten the Editorial Process. If you have a tedious editorial process, I’d recommend getting rid of it. At one company I worked, we had an editor that required multiple submissions, requiring at least 3 weeks total for reviews and edits. It slowed the process up a bit (although granted, the quality increased). Short peer edits are more practical in my opinion.

Have the Manager Meet with Each Team Member Weekly. A good manager can help allocate resources well, and make sure each writer has an appropriate amount of work — but only if the manager is in tune with each of his or her team members. One time I had a manager who met with each of us for 30 min. to an hour a week. The outward purpose was to get a report on how we were coming along with our projects. But it transformed into much more than this, as we wandered into tangents and talked about other things. I found this one hour with my manager each week to be the best thing a manager has ever, ever, ever done. Honestly, it built rapport. It let the manager know exactly what the workload was for each of us. It allowed us to communicate any problems we were having, either with access or with reluctant SMEs. No tracking software can replace face-to-face communication.

Market Your Department. If you need more resources, you should let upper management know. If they don’t want to pay for more tech writing resources, then push back on the deliverables, the timeline, or the scope. How are you marketing your dept. to your organization? Consider getting together the key senior leaders for a dog and pony show about the benefits of good documentation.

Publish in a Place You Can Update On-the-Fly. Are you publishing your help on a server separate from the application? When you have control to continue modifying the help once the product is launched, it removes a lot of the burden of a deadline. In my situation, I give the developers a link to the help. The link points to a Flare file that I have hosted on a SharePoint site. It works well because I don’t have to stay up the entire night before a release creating video tutorials. In fact, by release time, I just have to have the basic help content out there. I can continue adding to it after the release date.

Another Perspective: Take Your Time

I don’t know quite how to say this, but good documentation takes time. Rather than always trying to do everything faster, better, with fewer resources in less time and with double the quality, etc., consider that a slower, more labor-of-love-type approach isn’t necessarily a bad thing.

I’m not recommending that you join the Slow Movement, but there’s something to be said for taking your time with a project you’re heart is in.

One of my favorite movies is Brother Sun, Sister Moon. It’s by Franco Zeffirelli and from the hippy-era, and definitely dated and corny, but it gets me every time. Here’s the song I like most.

And a round version.

The key line is this:

If you want your dream to be, take your time go slowly. Do few things but do them well — heart-felt work is holy.

I’m engaged in a lot of activities, and sometimes I see my life getting stretched thinner and thinner. In addition to being a father of 3 young girls, a husband of a voracious blogger, young men’s president in my branch, I also post regularly on my blog, publish a podcast, coordinate a social news site, and occasionally I teach courses on WordPress and do freelance web copy/design. I also love to play basketball, go on Saturday outings with my family, and read nonfiction tech content. This past week, I said to myself, Tom, focus on what you really want, and simplify your life, because you’re not doing any of these activities particularly well.

I think the same can be said for documentation. Focus on what really matters — the application that’s going out to 20,000 users, or the one designed for the highest-paying customers, or the application that generates the most calls to the support center. Give that your highest priority by doing it first. Then work on the less important tasks. (It’s the Stephen Covey big-rocks-small-rocks principle.)

The other stuff will get written eventually. The world won’t stop. This is the one comfort to being a tech writer: while your work is valuable and incredibly important, no one is going to delay the product launch if you aren’t ready.