Your question strongly implies management metrics tied to individual utilization rather than flow or cycle time. The 100% utilization fallacy is antithetical to Kanban, and to agile systems in general.
Furthermore, Kanban systems aren't intrinsically concerned with how much time individuals allocate to a given task. Instead, they focus on the cycle time of tasks and processes to increase flow.
Below, I address the Kanban, agile, and cultural perspectives that underlie your question. These perspectives also provide some guidance for treating Kanban as an organizational process that can address and improve these three dimensions, and thereby improve the overall effectiveness of delivery within the framework.
The Kanban Perspective
Is it OK in Kanban that a developer may be involved in another developer's work (helps, consults) for a significant amount of time (a half day)?
Kanban is not prescriptive about the structure of working agreements. So, the short answer is that it's okay to do this if it:
- fits within the team's working agreement, and
- doing so doesn't violate any work-in-progress limits.
It may even be advantageous to do so, because having more resources working on a given work item reduces work-in-progress (WIP) for the team, e.g. you don't have somebody starting yet another task before something else is completed. It can also reduce cycle time for collaborative tasks, and lead time to dependent tasks.
In short, Kanban allows you to work any way you like within the framework's requirements to visualize work and limit work-in-progress.
The Agile Perspective
Agile frameworks value collaboration. Parceling out work in single-task units and assigning them to individuals is generally an agile anti-pattern for a host of reasons. While Kanban grew out of the Toyota Production Method, and assembly-line work is often task-based, the overall goal is continuous flow of work rather than individual utilization.
Most successful Scrum and Kanban teams will collaborate heavily on tasks, self-organize the workflow to optimize flow and limit work-in-progress, and generally swarm as a team over WIP that is not actively flowing. This is exactly what you want.
If Developer X is building a widget (call it Task N) that Developer Y needs to start some other task (call it Task M), Kanban generally requires that dependent task N be completed before M is started. Therefore, it's in everyone's best interest that Developer Y help Developer X so that the output of N can be pulled into M.
There are always edge cases and caveats. For example, if Developer Y is primarily allocated to a work stream that has free WIP slots and has other work to do that is not dependent on Task N, then that should take priority. Otherwise, Developer Y would have to choose between:
- Helping out on Task N to improve flow.
- Waiting idly for Task N to be completed.
- Doing busy-work to create the illusion of productivity.
The whole point of agile systems like Kanban (and Lean in general) is to eliminate waste. Reducing the cycle time of WIP through the system eliminates waste and bottlenecks, and is therefore usually the right thing to do.
The Cultural Perspective
Your core question strongly implies that everyone on the "team" (and I'm using that word loosely) should be working in a dedicated silo, tossing completed work items over the wall to one another. This is generally symptomatic of one or more of the following:
- Management that measures resource utilization rather than outcomes,
- Command-and-control management that doesn't benefit from the agile principles of empirical control processes.
- A cultural bias against collaboration and collective ownership of the work product.
- A management team that cares more about how things are done, rather than focusing on whether things are done.
- Conflating time on task with effort or efficiency.
Adopting Kanban without clear working agreements within the team, and between the team and the rest of the organization, is a common source for these cultural anti-patterns. The question really shouldn't be whether Kanban allows people to collaborate, because it does. A better question is "Why doesn't the organization value collaboration and shared responsibility?" Until you haul those underlying assumptions out into the light, examine them, and adapt them into a more effective working agreement, you aren't really doing Kanban properly as a continuous-improvement process.