Very interesting - and somewhat more common than you might expect - situation!
Some questions first -
Are they all just developers - or do you have other roles such as designers, testers, etc.? That affects the design of the workflow. If each person can do all the work on a story or task themselves, then you can have a simple workflow such as Backlog - Committed/ Ready - Doing - Done, but if there are specialized skills, then you would probably want a more elaborate workflow - Design - Test Case - Dev - Automation - validate, etc.
Can they work interchangeably on any of the projects or even tasks within a project? If they can work interchangeably, you can focus on ensuring that whatever tasks are picked up are finished first, before taking up new tasks (Kanban is, after all, about "Stop Starting! Start Finishing!").
The answers to both of the above points impact how you plan your WIP Limits.
For the purposes of visualizing the status of each project clearly, as well as the allocation of developers to each project, it would make sense to have individual swim lanes for each project. However, depending on how much cross-project task allocation you might realistically have, where managing overall WIP becomes most important, you might have a single lane board where all your work gets done. (You could consider different colored stickies for each project if necessary).
Having said all that, the way I would define your WIP Limits would be -
- 2 cards per developer in the "In-Progress" stages if there's no cross-task or cross-project allocation. That way, if a card becomes blocked for some reason, the developer can always pick up another card without breaking WIP Limit.
- 1.5 cards per developer in the "In-Progress" stages of a developer could take up another developer's card when it becomes unblocked.
- Depending on the extent of the blocking you experience, a 1.5 to 2 times the average WIP that you observe in the "In-Progress" stages.
When implementing these WIP Limits, you, of course, consider the overall capacity of each team. So a 3-member team could have a WIP Limit of 4-6, a 6 person team would have 8-12 cards, and so on.
Depending on the answers to the initial questions, you could consider using a Lane OR Column level WIP Limits, as well as individual-level WIP Limits to manage the overall loading of your developers.
If you are using a physical board, besides marking WIP Limits on top of each column or the overall lane, you could use tokens for each developer to limit the number of cards they may have at any time.
If you consider an electronic Kanban tool, consider using a tool that supports all 3 types of WIP Limits.
If you need additional guidance on the Kanban Method, you could check out this article. Separately, we also have this guide on how to design Kanban boards that you might find useful.
Hope this helps.
Disclaimer: I am a co-founder at Digité, where we build Lean/ Agile tools for software and business teams. We have worked closely with the Kanban community in designing our Kanban tool. I personally am a Kanban coach/ trainer and have worked with numerous organizations in helping them implement Kanban.