I was wondering when a small development team would use kanban when they have multiple simultaneous IT projects.
Is there a reason why someone would rather go with kanban instead of Scrum when managing multiple projects?
My guess is that they will have a separate work board per project and define on a different board which tasks they will complete in this given timespan.
The key phrases to remember with Kanban are 'visualise the backlog' and 'limit work in progress'. For this reason I think Kanban is best managed using a single board. Otherwise people find it hard to visualise the total amount of work that needs to be done or that is currently in progress. Multiple boards also make it harder to set hard limits on the total number of tasks that the team can have in progress at any given time because you'll need to count up the total across several boards to keep track.
To manage multiple projects (or even themes within a single project) I use swimlanes to visually split the work out but keep it on the same board e.g:
----------------------------------------------
| | To do | In progress | Done |
|-----------|-------------|-------------|------|
| Urgent | T-69 | | T-6 |
|-----------|-------------|-------------|------|
| Project 1 | T-103 T-204 | | T1 |
|-----------|-------------|-------------|------|
| Project 2 | T-30 | T-97 | T-12 |
|-----------|-------------|-------------|------|
| Project 3 | T-465 T-500 | T-34 | |
----------------------------------------------
That way you can set per column limits for total workload rather than per project, and you can get an instant visual representation of the total number of tasks in each status.
This can, of course, become quite unwieldy, especially if you're using a physical board. I use JIRA Agile to manage the process, using Quick Filters pretty heavily to quickly switch between views of the work.
Our team personally use different coloured cards to ally each user story to a particular project.
Each Project is treated as an Epic with it's own requirements documentation and a it's own timeline.
From personal experience I can tell that teams starting with Kanban on multi-project environment has a way faster and higher success rate. Firstly, because Kanban is visual, secondly then Kanban has a very flexible structure that can be mapped out on the eletronic or physical whiteboard, separating Kanban Board into areas that represent individual projects.
Second important aspect is that Kanban systems usually employ swimlanes, which can be used as project tracks and boundary markers. WIP limits can play a nice limiter role cutting across all the projects.
My opinion does not mean that scrum is not good in this case, mature IT teams can leverage a lot of value by using scrum methodically, but that is costly and takes time as well as strong culture.
An example of Kanban system used for multiple projects:
Image credits: https://teamhood.com/kanban
Kanban and Scrum is not comparable but think about this: Scrum is for one project in an iterative fashion. You have more than one project, possibly in a continuous fashion, so you are better of with Kanban. Nevertheless, have every second week a retrospective to see how you are doing and what you can do better.
