Kanban for Science, Part 1 of Many

I’ve been making vague promises to write about project management techniques I learned in the Agile software development world that I think would translate well to science. This post is my attempt to start delivering on those promises.

Kanban is a process improvement technique that originated in Japanese manufacturing. You may think that makes it an unlikely candidate for use in scientific research, but I think there are some aspects of it that actually fit research projects quite well.

“True” Kanban is done at the task level. You model how tasks get worked on and completed in your process. Yes, you have a process, even if you don’t think you do- it is just “how things are done around here.” I’ve never worked anywhere, from lab to software development, that does not have a process. The process is just not always documented or understood. Part of the promise of Kanban is that it surfaces your process and makes it easier to see where it is suboptimal. Finding and alleviating bottlenecks, for instance, can really help your group be both happier and more productive.

In the software development world, a task might be a new feature. First it goes to an analysis/design step where someone figures out what, exactly, the feature entails. Then it goes to a development step in which someone writes code to implement the feature. Next, it heads to testing, and finally it gets deployed to the end user. If you’d like to know more about how kanban techniques might be used in a software development project, Pawel Brodzinski’s blog is a great place to start and Kanban, by David J. Anderson will provide even more detail.

In a lab environment, a task might be something like “produce protein for use in assays,” and your process steps might include cloning, expression, and purification. That assumes that you are simply producing more of a protein that you have produced before. There’s a reason for that: this sort of task maps most cleanly to a production metaphor. You could also model more “research-y” tasks, but I’ll talk about those later.

It is also fine to have a very generic process, in which tasks are either “to do,” “in progress,” or “done.” I tend to extend this to include more categories such as: Backlog, Prioritized, In Progress, In Review, and Done.

One key feature of kanban is that you limit the work in progress- i.e., you define how many tasks can be in any given phase at one time. New tasks are only pulled in when there is “room.”  The beauty of this is that most people do not cope well with having a large number of competing tasks. I’ve worked with people who will essentially shutdown when this happens- they try to advance all tasks at once, and end up completing none of them. In general, it is better to finish a task and then move to the next one. I could gush on and on about the beauty and power of limiting the work in progress, but that probably belongs in a future post.

A wonderful side effect of limiting work in progress is that you quite naturally build slack into your system, and slack is what people use to improve processes and investigate new ideas. But that’s also a pretty big topic on its own, so I’ll just mention the idea and make another vague promise to come back and talk more about it later.

There are a lot of other interesting aspects of kanban, but for this post, I’ll just stick with the idea of modeling your process and defining limits on your work in progress. If you apply either one of those alone, you are likely to notice some improvements. The wonderful thing about kanban is that it is by definition about continuous improvement, so it is absolutely OK to start with the most basic of implementations and then try to improve from there.

The very first thing to do if you’re considering applying kanban techniques to your work is to determine whether you want to model your process at the level of tasks or projects. My general rule is that modeling at the task level is a good fit if you have something like a production line (e.g., the protein production example above) or if you tend to have a lot of different low level tasks- one classic example of this is the maintenance of software that is already in use. In that case, there are some new features and some bugs and they all have to be prioritized against each other. On the other hand, if you are doing a lot of exploratory work modeling your process at the project level probably makes more sense. You are no longer doing true kanban in this case, but you can still make good use of some of its ideas.

Most recently, I used a task level kanban as a personal to do list, and a project level kanban-like board for my group.

For the project level board to really work, though, you need to learn how to break your projects down into well-defined chunks. One way to do this for a research project is to think about the decision points in an overall project, and model the work until each decision point as a project on your board. Another way to do this is to fall back on the old “what are the figures in your paper?” trick, and model the work required to produce each figure in a potential paper as a project. There is no right or wrong way to do this- there is only finding the way that works best for you and your group.

If you can make each chunk of work be about the same size, you’ll get more benefits from the kanban techniques- but that is quite hard to do, so I recommend not worrying about that at first.

Once you have your process modeled and project chunks defined, make a card for each project, and put the cards in the appropriate phase of your process. You can use a physical board- a cork board or a magnetic white board works well. Or you can use a software tool. I’ve used and liked KanbanFlow in the past, but there are a lot of other options, and a simple Excel spreadsheet with a column for each phase of your process will get you started.

You can do a lot of fancy things with the cards- noting what’s blocking progress, noting who’s working on it, etc. I’d start by just putting the cards on the board and watching them flow through your process. If you think you have a personnel utilization issue, you can also include people on the cards and notice who has a lot of cards and who doesn’t, but don’t draw any conclusions from that at first. A person being assigned to a lot of cards can be a good thing or a bad thing. Watching how the cards flow and noting where there are bottlenecks will help you determine which it is.

Once you have your board set up, decide how often you’re going to update it. If you’re doing a task level board, daily updates are likely to be needed. If you’re doing a project level board, a weekly update might be sufficient. In general, it works best if the entire team comes together to “run the board” and make the updates. I’ll talk more about that in a later post, too. (Another vague promise!)

Regardless of how often you update the board, watch what happens to the cards and notice what that is telling you about how work gets done on your team. You’ll probably get some ideas for improvement fairly quickly.

Once you have your board set up and have watched your tasks or projects flow through your process for a bit, you can start limiting work in progress (WIP). You’ll have to think about the type of work being done in your group and decide how many cards your group can handle in each phase at a time. One method for setting an initial WIP limit is to decide how many projects or tasks each person in you group can handle, and set the limit based on that. It is not uncommon to find that your work in progress is well above the theoretical limit you just derived. Don’t worry about that- just decide if you think the limit is correct or needs to be higher, and then aim to get your WIP down to that limit by attrition. Simply don’t start new tasks/projects as old ones finish until you are down to below your WIP limit.

I have seen pronounced improvements in team member productivity from introducing WIP limits. In our culture that idealizes being busy, it can be hard for someone to come to you and admit that they are feeling overworked or unable to focus. They might not even be able to describe for themselves why they are struggling. Limiting WIP is a judgement free way to ease these pressures, and give your team room to really shine.

I keep a personal task-level kanban board, too, and have found that limiting my WIP really helps me get things done- even unpleasant things I might be tempted to procrastinate on. If I have the discipline to stick to my WIP limit (three is a good number for me), I can force myself to finish that unpleasant task by promising that I’ll drag in something more fun next.

That covers the basics of how I think kanban techniques can help research groups get more productive. Ask me questions or tell me which more advanced topics you’d like me to cover next.