Kanban and Limiting the Scope of Work
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.
Related Posts
Writing User-Centered Documentation, or, My Best Days as a Technical Writer
How to Get Programmers to Change User Interfaces
Lying in a Hammock, or, Having a Single Goal without a Purpose
Virtual Meetings: A Lofty Yet Impractical and Unwanted Ideal? or Exactly What We Need?
Using JIRA to Track Writing Assignments
I had to smile when I saw this post pop up in my tweet stream. Early in my career I was a technical writer. I’ve since evolved into being a Product Owner in agile software development. As such, I have solid experience in using both Scrum and Kanban. Personally, I believe strongly in the Lean/Kanban concepts of Limiting Work in Progress and Visualizing Work to manage capacity in teams. I even blog about using Personal Kanban to manage our family life!
But just limiting WIP is not going to make your over-allocation problem go away. The fundamental purpose of a Kanban flow system is to communicate to those involved (and outside – like management!) how much work is in the system and where the bottlenecks in the system are. By setting your WIP to a level that you can actually maintain healthily, the phases before you will start backing up, as they can’t pass you any more work until you have completed a task. This will set off some alarm bells.
By making these blockages in the system visible, you create opportunities for conversation with the development team and your managers about how best to address the capacity problem. Maybe it’s to add more writers, or to second a junior dev to Documentation as part of onboarding, or to identify projects that only need basic help versus those that could benefit from more, and prioritizing tasks accordingly.
There’s quite a bit more to implementing Kanban (especially if you’re working inside a larger team) but the core of it really is ensuring that these conversations happen so that the right kind of policies can be put in place to manage the amount of work going into the work stream.
Maritza, thanks for your insights on Kanban and for expanding my understanding here. I like your point about the conversations that Kanban enables when bottlenecks occur. We haven’t implemented it in a way that would surface these bottlenecks. Mediocre or uncompleted help isn’t something that becomes a blaring red siren of alarm. But I want to pursue this methodology more to see if we can implement it in a way that would help surface these concerns.
Tom, I believe you will find there is a Kanban plugin for JIRA, so you can get the benefits simply by extending the toolset you are already using.
Thanks, Rick. I’ll check it out.
The Greenhopper extension for Jira have some really nifty Scrum/Kanban featurs, especially since the last update.
If you want to read more about Kanban, there’s a few free minibooks out there well worth reading:
* Kanban and Scrum, by Henrik Kniberg & Mattias Skarin
* Lean from the trenches, by Henrik Kniberg
* Priming Kanban, by Jesper Boeg
Thanks for the tips on more reading about Kanban. I actually have the Greenhopper extension installed already! I will look more closely for the Kanban features. Thanks again.
Simple – Consistent poor quality writing and delayed article submissions (if there is genuine work overload) will automatically result in lesser work
Thanks, Raj. This points to the downward cycle that mediocre help creates.
Hi,
Unleash is an integrated solution for managing projects, collaborative Gantt scheduling, real-time reporting, bug tracking / QA, document management etc. The tool is fast, easy and builds on principles of team empowerment, increased communication, transparency, and collaboration.
http://www.unleashpm.com/
Thanks & Regards
http://www.unleashpm.com
Tom,
Limiting your work in progress can definitely improve your productivity, because it reduces the number of context switches you have to perform, and studies have shown that, especially for knowledge workers who have to be in a state of flow to be really productive, context switches are enormously costly.
Of course, that only works if certain conditions are met. First, your work has to be broken down into fairly small chunks. If you are not working in topics, I don’t think you can usefully apply Kanban to writing.
Second, it only works if the practice of Kanban across the enterprise works, because Kanban works by forcing your to address the causes of work becoming blocked, rather than working around it by switching to an unblocked task. With limited work in progress, you can’t pull an unblocked task off the to-do list until you have cleared a task off the in-progress list. If all in-progress tasks are blocked, you have to unblock them, and that forces you to address the factors that hinder flow in your organization.
But when it comes to pubs, there is a catch. No one else in the entire enterprise has a genuine hard dependency on pubs. Someone can, in the end, decide to hold up a release to fix docs quality (it must have happened somewhere sometime) but up to that point, if it occurs, no one is genuinely stuck waiting for docs to do anything. And if no one else’s tasks ever get stuck waiting for docs, no one else has a motive to change their process to get docs’ tasks unstuck. At that point, you are relying on goodwill rather than the natural action of the Kanban system.
While I suspect Kanban is a better system for many development projects, given this uncomfortable reality, I suspect that docs will usually be more productive in a development environment based on Scrum — provided, of course, that finished docs are part of the requirements for finishing a sprint. And for that to work, you really do need to be working in topics.
Mark, it’s cool to know that you have knowledge of Kanban. You never cease to amaze me. I agree that docs don’t hold up projects, so the Kanban system won’t really work there. I like including documentation as part of sprint completion requirements instead.
I also like the point you make in the first paragraph:
I am finding this absolutely true. I work much better if I immerse myself in one project rather than a handful. Also, I really enjoy complete immersion in a project, to the point that I acquire SME-level knowledge. It makes my job so much more satisfying.
I owe everything I know about agile to my good friend Norbert Winklareth, who was Director of Engineering at OmniMark Technologies during my time there, and is now a management consultant and agile coach. Besides fitting pubs into the agile software development process at OmniMark, Norbert also lent me a number of very good books on the subject which really changed my outlook on the tech pubs process. Two of these in particular are worth mentioning and recommending: Donald Reinertsen’s Managing the Design Factory and Tom and Mary Poppendieck’s Lean Software Development.
What I learned from these is the many benefits that come from working in small batches. Today, the argument for working in topics is largely framed in terms of the ability to do reuse. I think this argument greatly short-changes topic-based writing. Working in topics allows you to realize all the benefits of a lean/agile development process. While reuse alone can be a huge productivity win for some organizations, for many organizations, the benefits of a lean/agile process will greatly outweigh the benefits of reuse. But naturally you won’t get those benefits simply by switching to topics — you have to actually implement a lean process.
Too many writers look on agile as a development process to be accommodated, rather than as an opportunity to improve the quality and productivity in their own processes. That is a great pity. A lean/agile topic-based process can improve pubs quality and productivity enormously.
We found it to be quite useful to plan our projects using a project management tool – Open Workbench. This works particularly well for translations, as we can estimate translation requirements pretty accurately and then factor in reviews and publishing to extrapolate due dates. This way, if anything crops up along the way, we make sure to let people know that we can only take it on at the expense of other projects. We find that WIP tracking is more useful within the team to share the workload and avoid doubling-up. I’d say it would be neigh on impossible to limit my tasklist to 3 or 4 tasks at a time.