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.
[…] I dislike rigorous adherence to specific project management methodologies. As much as I love Kanban, I doubt it is the right approach in every situation. It is not fashionable to admit it now, but […]
[…] if there are several projects using the same people to express and purify proteins. I’ve written before about how to create a Kanban board, so I won’t belabor this point. For the purposes of this post, I just want to point out that […]
Hi Melanie – I am a PI in the biological sciences and recently became interested in applying kanban methods to managing my research program. Your post (and the entire site) is full of interesting and helpful ideas. The challenge I am finding is trying to hybridize project- and task-centered perspectives and incorporating due dates. To use the example of a protein prep you used above, how would one use kanban to schedule starting the culture, inducing bugs, purifying the protein, run gels of fractions, etc. sequentially without losing how the purification itself fits into the larger plan? I have seen people use kanbans as a calendar (e.g. one lane per weekday), but that seems to run counter to the idea of using them to model workflow. Yet planning as a workflow doesn’t give me the feedback I need to ensure I don’t have too many things slotted for a given day. I’d be interested to learn your thoughts about this. Thanks for the blog – it’s tailored to a pretty specific niche audience, but I have learned a lot already! Best, Steve
Thanks for the kind words about my site. I’m glad you find it useful. That is nice to hear.
The idea of kanban is that you don’t schedule so much as allow tasks to flow. The downstream steps in the process pull in work when the upstream steps complete. If that means that they have a little bit of downtime- called slack in kanban-land- that is seen as a good thing. People tend to use slack to improve their processes, so having some slack in the system is a good thing.
Of course, this doesn’t entirely work if your tasks have hard dependencies- such as needing to start a cell culture between X and Y hours or days before transducing, or needing to book time on a shared instrument. Remember, kanban came out of factory work and factory parts don’t die if they aren’t used on time the way that cells do!
Still, I think that even with some hard dependencies, there are multiple ways you could modify the ideas in kanban to still help you. It is hard to say what would be the best thing to do without knowing more about your research, but here are some suggestions:
1. Start with thinking about what aspects of kanban you think will be most beneficial in your work. To me, the most important aspects are limiting work in progress and visualizing the workflow. But maybe some other aspect is what you think will help you- and if so, that will change how you decide to implement the ideas.
2. Assuming you want the visualization and limiting work in progress aspect, one thing you can consider is pulling your kanban-like board up from the strictly task level to a higher level in which each step in your workflow actually encompasses a group of tasks. This is probably no longer a true kanban board, but so what? If it helps you, it is good. You might find after awhile that you see a way to break work into smaller chunks and head back towards a true task-level kanban, or you might not.
For instance, if you want a “express protein” step in your workflow, have that encompass the necessary dependencies of preparing the cells, etc. Then it is up to the person doing that step to make sure the schedule works out.
3. I have never used ONLY a kanban board to manage both my group’s work and my own work. In fact, right now without even having a group I have a kanban board (with several categories of backlog, because I find that useful) and I also still write a daily to do list- this is an old school to do list on paper, which I write the night before at the latest. In fact, I will sometimes start a list for a couple of days ahead if there are things I know I want to do on that day. You could do something similar with calendaring software if you prefer an electronic format.
In previous work when I had a group of people whose work I was coordinating, I had a program level kanban-like board with cards for projects. We were working to get good at breaking our work into 4-6 week chunks, but weren’t there yet. Still, the board was useful to us. Then I also had a personal kanban for my own work, which I recalibrated at least once per week. And I also still had my daily to do lists.
I tell you all of that not because I think that is necessarily the system that will work for you, but to illustrate how you can take the ideas that seem useful from kanban and apply them to your situation. There are other ways you could do that, too. I suspect you could even figure out a way to get a true task level kanban system working, but if that way is not apparent to you, there is no harm (in my opinion- kanban purists may disagree!) in starting with a level that does make sense to you, and then iteratively improving from there.
4. This one will really horrify kanban purists, but if you are having trouble seeing the dependencies and how they cause your timelines to flow, I find that make a plan in MS Project or something similar helps me to see them. So, sometimes I’ll make a “plan” just to map out my dependencies and think about rough time estimates for how long various steps take, even if I’m not going to use that plan for ultimately managing the work.
Does that help at all? If not, feel free to comment again with more questions, or if you’d rather keep the questions confidential, send me an email. I can’t guarantee super fast turnaround (unless you pay me!) but I will try to help.
Thanks for your thoughtful feedback, Melanie. I think I just need to do the experiment to see what works for me. I just finished a book entitled “A Factory of One” by Daniel Markovitz that dealt with application of Lean methodologies to personal productivity. These concepts are new to me and I thought the book was excellent. Of relevance here, he advocated a project-level kanban that mapped to specific tasks, kind of your option #3, above. In this scenario, the kanban functions to track “big picture” progress and limit work in progress, while scheduled tasks are maintained in lists or on a calendar. I’ll implement something like this as see how it goes.
[…] that article, and then writing my response to a recent comment with an excellent question about kanban made me start thinking about my approach to project management methods. I’ve used a wide […]
[…] Work in Progress (WIP) limit is one of my favorite ideas from kanban. The idea is that each stage of your process has some natural WIP limit. If you go over that, […]
[…] have written before about kanban and other methods for mapping projects. I have successfully used a kanban board to help someone who […]
[…] so I had to learn some new ones. Sometimes these were entirely new methods: I first learned about Kanban when I was in the midst of levelling up to deal with running a bunch of interdependent projects. […]