yellowcloudIf you want to get things done, focus is the key. Single piece flow (focusing on only one task at a time) might be too extreme, but limiting your work to your capacity is mandatory. No matter whether we’re talking about a team, an organization or about your personal productivity.
Kanban For Personal Productivity
If there are multiple things to be done (and hey, when is this not the case?) it always helps me to put it all up to a Kanban board. For my personal stuff I don’t use a physical whiteboard, but an electronic version (LeanKit Kanban or Agile Zen). By using one of those tools, I get a good overview about what’s going on and I can track my progress on all my goals.
Finding Your Capacity
One big advantage of a Kanban board is that it makes bottlenecks visible. If cards pile up in one of the columns of your board, you know that you’re trying to do more than you’re capable of. If you run into such a situation you have to do two things:
- Stop working on anything else and focus solely on moving the stalled stories out of the bottleneck
- Put a work in progress limit (WIP limit) in place for that column to avoid that bottleneck in the future
It doesn’t help to start new stuff if you already know it will ultimately get stuck in a bottleneck. Starting more and more new tasks without finishing old ones will only lead to thrashing – a situation where your time is completely consumed by task switching instead of getting anything done.
To avoid work getting stuck in a bottleneck, it’s important to limit the work you’re doing to the capacity of the bottleneck. That means you should prevent yourself from starting more stuff than you’ll be able to push through without getting overwhelmed.
A Work In Progress (WIP) Limit Helps You Focus
If you set your WIP limit to two or three for tasks being “in progress”, it helps you focus on exactly those tasks. And you have an explicit motivation for getting those tasks done as you should only start new stuff if there is an empty space on your Kanban board for another “in progress” task.
Agile Web Operations 
I don’t know much about Kanban, Matthias, but I think an added advantage of limiting the number of cards in one column is completely mental. It’s not just the task switching, it’s the mental overload of too many things to think about.
Sometimes when I can’t focus on a big task I realize it’s because there are so many little tasks running around. I can try to ignore them but it’s actually too hard. Better to eliminate a bunch of those little tasks by completing, canceling, or delegating.
LikeLike
Yes, Mark, you’re right. By limiting the stuff you work on in parallel you not only avoid task switching but the mental overload, too.
It helps me to ignore those little task you talk about if I can put them anywhere I know I don’t forget about them – either a backlog of a Kanban board or any other place where it is out of sight but I can be sure it will be there when I’ve time to address it.
LikeLike
OK, i understand the concept of WIP but what when i can’t finish my ongoing tasks cos I have too wait for another guys from another department to finish his part of the task? Should I sit and wait do nothing or better take a new task from backlog?
LikeLike
Max, you bring up a very important point. It’s always problematic if you can only try to optimize one step in the whole value creation process.
Better than waiting or taking on more tasks (breaking your WIP limit) would be to try to help the other department to get their stuff done faster. Either by talking with them directly or by trying to get attention to the Kanban idea for the whole process.
If all that is not possible, you still can break your WIP once in a while, but you should be careful with that. Or maybe your WIP needs to be bigger because of the broken process?
LikeLike
A couple of questions:
1) Does the WIP need to be the same for all workflow states?
My guess is that no since people in each workflow state (ie: different teams… developers, testers) may vary in number or expertise to accomplish their tasks. So their throughput may be different among each other. Am I right?
2) Does the WIP need to be applied to stories for all workflow states? Or may we set the WIP to stories in some cases and to tasks in others? (by task I mean the smallest work unit possible… a story is made up of tasks… a number of tasks form a story)
Asking because in a project I’m working on, we managed the WIP for the ‘Development Pipeline’ at a task level, because we considered that it would be better to limit the amount of work developers could do in terms of tasks, being the tasks of roughly the same size by following Kanban’s ‘do not estimate’ suggestion (because estimate is a waste) but rather ‘break stories into smaller pieces of same size’. Stories, on the hand, may vary in size.
On the other hand, for the ‘Testing pipeline’, we set the WIP at a story-level, since testers talk about stories.. they test stories and not loose tasks.
Is it OK to do it like this? Or should we set the WIP always to stories? Does it alter the metrics (Lead Time, Cycle Time) in any way?
LikeLike
Kevin, let my try to help you here:
1) The WIP limit is naturally different for all workflow states. You’re absolutely right on that one
2) If you prefer to track Tasks in the development stage, that’s totally fine. Just divide your development column on your Kanban board into multiple sub-columns for the workflow stages of your tasks. That way your main Kanban board works on story level and your development stage works on task level. You can now even introduce a WIP for the stories in development _and_ a WIP for every stage of your tasks (if you want to).
Hope this helps,
Matthias
LikeLike
We started to use Kanban a couple of weeks ago, and wanted to ask a question so as to hear from you which will be the best option for this scenario:
We have a story which analysis has been completed, so we moved it from ‘Analysis Pipeline’ to next state ‘Development Buffer’.
Then the Product Owner realized that some definitions were missed, so.. should the story be moved back to ‘Analysis Pipeline’?
We have a property which is ‘Analysis Completed On’ (that we use for metrics.. to calculate the time stories spend ‘In Analysis’), that would be reset if we do that.
So is it Ok to move it back to ‘Analysis Pipeline’? Or should we not move it and complete those pending definitions leaving the story where it is, in ‘Development Buffer’ state?
LikeLike
Hi Richard, you definitely should move back the story to the Analysis state. To keeps things simple, just reset the “Analysis Completed On” date. It will then reflect the fact that analysis took longer as expected.
If you want, you can ask such questions over at Scrum What? to get helpful answers about Kanban, Agile, or Lean Software Development.
LikeLike
Matthias, quick one:
I know that one of the key principles of Kanban is not to start something new until I finish what I am currently working on.
Now, my question is: how strict that rule should be?
My question is because I am working on a team in a Kanban-driven way, and the team works tasks for 2 different projects, splitting their time evenly between the 2 projects. They try to balance their by splitting the days as a whole, thus avoiding context-switching.
So for instance: they spend Monday and Tuesday for one project (and don’t work on that project again until following week), Wednesday and Thursday for the other.
Now, imagine we have a story for one of the projects that we know it might take longer than 50% of the time allocated to that project in the week (thus, it will have to wait until next week for completion, altering our development cycle time which is normally of 2-3 days at most), and we have another task for the other project to work on too.
Since we don’t want to leave either of the tasks for each project idle for 2-3 days, can a developer work on those two tasks on parallel, thus doing context-switching? Or should we “tie” ourselves tightly to the rule of “not start something new until you finish what you are working on right now” ?
Thanks.
LikeLike
Kevin,
it’s definitely not mandatory to stick to only one story at a time. Kanban only asks you to define a Work In Progress Limit (WIP limit), which fits the capacity of your team. If your team is fine working on two stories in parallel just define your WIP limit to be two and give it a try. The important thing is that you do not bust your (self defined) WIP limit. Before staring more stories than your WIP limit defines, you should all help to together to try to finish what’s currently in progress.
Of course, it’s always good to avoid task switching. But forcing your team to only work at one thing at a time might not be optimal. I guess the sweet spot for most people is to have two things going on in parallel. That way, if you have to wait on one thing, you can go on with the second one.
Hope this helps!
LikeLike
Hi Matthias,
just a small question to you.If WIP is reached and there is one resource in the team who is a not fully occupied but can progress some priority task which is the backlog…what should be done? I also assume that resource cannothelp other team mates as he/she is tester what could be the possible solution in such a case?
LikeLike
Hi Nipun, he should definitely not start on a new task but work on something, which is improving the process or learn something new. Such a situation is the point in Kanban where improvement takes place.
LikeLike
Hi Matthias,
Thanks for your reply but i have one more question for you….when there are priorities for each task in the backlog queue then such a resource would be wasting his/her time by being non productive….where the resource could actually be productive….due to the kanban WIP limit the resource cannot progress the task’s…… but how if limiting the task’s in WIP per resource this would be beneficial..
What do you suggest in this scenerio?
LikeLike