It is not quite clear whether you have a multi-tasking or context switching challenge or not. Since, as a team, you are supporting 8 different streams of work (6 services and 2 projects), you are already used to (the idea of) doing it. So, mentally, each of your team members is prepared to work in that fashion.
There's been a lot of research that shows that context switching definitely creates a problem. See this article by Ruth Mantell - Multitasking: More is Less (https://www.wsj.com/articles/SB10001424052702303544604576436572369558128?shareToken=stfcb09c464775476b8fff5b8b5aa0962d) or this one - Multitasking: Switching Costs (https://www.apa.org/research/action/multitask). However, what exactly is multitasking and if you are really context switching is open to question based on your specific situation.
From what you have said, your team members pick a task - and implied that they complete that task before picking up the next one. I'd argue that as long as they are completing the work they have already started, and not juggle between 2 or more open tasks simultaneously, you are doing fine. You can easily "implement" this using your Kanban board with WIP limits (Work-in-progress) - one of the key principles of Kanban. To learn more about Kanban's principles of improving flow while minimizing multitasking, you can look at our Kanban guide here.
Next, let's look at your policies you've decided on for your work.
You said -
Recently we've started an experiment that everyone on the team (six
devs) pull the top item off the backlog regardless of what it is.
What was the reasoning or thought process behind this? Clearly, your team has committed to supporting those 8 streams of work - and you are trying to provide equal capacity to each. If all services have the same priority, then perhaps that might work well.
However, are their different priorities for each of them? Kanban refers to this as "Class of Service". Do you think that instead of giving equal priority to each, there is some differentiation needed in order for you to meet your SLAs to your customers? If so, you might consider organizing your Kanban board differently, perhaps by class-of-service (a separate swim lane on the Kanban board for say, urgent or Expedited items) or some other way - that is a discussion your team needs to have amongst yourselves, and maybe with your customer(s).
Just to share our own example, we use 2 Kanban boards - an "upstream" Kanban board for our product roadmap/ backlog grooming, and a "downstream" one where our Dev team works on both roadmap work (similar to your projects) and also on a mix of other work that includes bug-fixes, customer implementation related work and so on. Our boards and workflows look as shown below -
Our Dev team's board has multiple lanes to track the different services they provide -
Being a product company, we have established - over years of experimenting - that a 4-6 week cadence for making product releases works well for us. We work around this cadence for prioritizing and grouping work in different streams. Our Prod Management team works to identify and prioritize themes, epics and user stories on the roadmap board to keep the Dev team fed with the right work at the right time. Overall, the process works well, and we have been able to maintain a fairly happy set of customers who give us high marks for the support and responsiveness we demonstrate to them, besides of course the product itself :)
Overall, my recommendation would be to have a discussion within your team, and with your customers/ stakeholders on -
Are they finishing work in progress before taking up new ones? If yes, that's great (else, re-emphasize the "Stop Starting! Start Finishing!" mantra with them.)
Do they feel confused or unproductive because of having to switch between different projects and services? If no, then great. If yes, then you've to think of how to perhaps reorganize your team into sub-teams that handle smaller groups of services that are less diverse, helping them work on similar work-items at a stretch.
Are you meeting your commitments to your customers? Does everyone have a clear - and common - picture of what those commitments are? If the answer to either one of them is No, you've got to ensure you have clarity there in order to best decide how to reorganize your work policies so that your team is clear and comfortable with what work they pull next after finishing up what they were already working on.
Hopefully, our Kanban guide as also our blog will provide you with additional reading on how to manage your teams work.
