Kanban and Limiting the Scope of Work

by Tom Johnson on Dec 18, 2011
categories: technical-writing

In Scrum and the Single Writer, Kathee Kuvinka mentions Kanban as a technique implemented in her agile-based company to keep the workload under control. Kathee writes,

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.