Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
My development team is very new to kanban. We have already seen the benefits of the simply visualizing our process.
However, as of late I have noticed developers picking up multiple cards at the same time.
In your experience, does this reduce efficiency?
We are not at the stage to determine this by flow metrics.
Thanks for your help
There is no such thing as "kanban efficiency". Only developers efficiency.
Kanban WIP limits were implemented to avoid waste stemming from multitasking or waiting for others.
However there can be multiple reasons for developers to start multitasking anyways:
Several stories and/or tasks depend on each other. In this case it's logical to have them all assigned to one guy who implements them in one burst. To avoid this issue, the user stories should be created in such a way that they are self-contained, independent items.
There are gaps in development. The developer might be waiting for code to compile, an artifact to be deployed, a product owner to provide feedback, etc. In such a case the story can't be worked on anymore at that time, so it's acceptable to have one story in stock to switch between the two to fill the gaps. This is fine as long as there is a reasonable limit on the number of concurrent tasks (usually two).
Some people multitask by nature. Although these people are naturally rare, I personally worked with a few people that felt highly comfortable with multitasking. If they got stuck on one story they just switch between them without falling out of context, allowing for the solution to the first problem to come up from their subconsciousness while they performed a simpler task. Provide such a guy with an interruption-free working environment.
Oh, one more thing, you may want to check this video. https://www.youtube.com/watch?v=W92wG-HW8gg
All the body of knowledge in Kanban about multi-tasking, context-switching and WIP Limits - all of them encourage reducing multi-tasking and focusing on finishing what's already been started before taking up something new ("Stop Starting! Start Finishing!").
Think of your team as a highway with a certain capacity. If there are too few cars on it (same as some people on the team not having any/ enough work), you have low flow-efficiency. On the other end of the continuum, think of the same highway jammed with cars - crawling at 5 MPH (each team member having so many cards that they take too long to finish any one of them - and overall, the total cards take longer than they would if they'd been taken up one at a time). So, there is an optimal loading (different for different contexts) at which you will see maximum flow efficiency - maximum flow. Your experimentation with WIP Limits for your team will hep you get there.
All of this is backed by a lot of research on how multi-tasking makes people less efficient and productivity drop significantly. A lot of attention has been given to this in recent months - there is real evidence to suggest that the human brain works sub-optimally when multi-tasking and context-switching.
Here are just a few recent articles on this topic that will you might find useful -
https://www.wrike.com/blog/high-cost-of-multitasking-for-productivity/
HTH
Yes it reduces efficiency due to context switching. You may want to set a personal WIP limit for each developer on the team to be somewhere between 1-3 to start.
Personally I always start having conversations with Kanban team members about personal WIP when they consistently go over 2 items.
There are some studies out there that show every time an individual context switches (between two tasks or cards) it can take up to 45 minutes for the mind to re-tool to the new problem space. That's your efficiency hit.
You should also take this as an opportunity to explore WHY they have so many cards in progress in parallel. Are the cards poorly defined? Are they blocked and not figuring out how to get unblocked? Etc...
Having too many open ends is one of the biggest issues you want to tackle by using methods like Kanban - the ideal you should be working towards is 1 team member - 1 story. If you need some more flexibility, you can agree on a work in progress limit, means you limit the number of stories a single member can work on at the same time (3 is often chosen as a number, but can be more or less depending on your situation). If anybody exceeds this number, they will have to prioritize on the most important ones and put the others back to the backlog.
It really does depend on a lot of factors.
For example, a developer who is working on three items at the same time that touch on completely different parts of the code base may find that they lose efficiency due to task switching.
Another example might be a developer is working on an item which requires some slow, hands-off builds to take place. During the time the builds are taking place they will have little to do. In this situation you can imagine that working on at least two items would be more efficient.
This is why Kanban takes an experimental approach. We set the work in progress limit and then see what kind of flow rate we get. Then we tweak the limits until we maximise efficiency.
My recommendation would be to start with a low work in progress limit, measure the flow and then slowly increase the limit while constantly monitoring the impact of the change.
